GitHub Community
Branch Practices #23601
-
|
Hi! First submission here. We recently moved to GitHub Enterprise from StarTeam Enterprise. Big paradigm shift. We brought our branch practices and I’m not sure GitHub works the best with our branching policy, or at the very least, we’re doing something wrong with our merges. So we create a branch for the next release which serves as our dev branch, call it 2.1.1. We make changes in the 2.1.1 branch, build from there (2.1.1.1.1, 2.1.1.1.2… - had to go one level deeper because tags and labels are wholly different beasts which can’t be duplicated in branches not to be confused with views, lol) and test on the dev test system. Could be several iterations of changes on there until we’re ready to push it forward to QA. Once ready, we merge up to QA (master) and build a 2.1.1.1 build. Next iteration gets build on the 2.1.1 branch and tested in dev (2.1.1.2.1, 2.1.1.2.2…) until we’re ready to move to QA then we merge again. The issue arises with the merges. GitHub doesn’t seem to like merging multiple times to the master from the same branch. It seems to get confused with previous merges. My strategy is pretty standard Brad Appleton merging practice, but I’m wondering if this is contraindicated in the GitHub world. Hope I was clear in my explanation, any direction would be greatly appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
|
stonkers:
What exactly is the problem you’re seeing? Generally merging from the same branch repeatedly isn’t a problem, unless you’re not using merge commits. If you do anything else (rebase, squash) Git will see new commits all the time. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like the “conflicts” get worse with each merge to master as if when you merge the first time, it flags that file again that didn’t even get changed the second time. Does this make sense? I’m SCM, developers doing the merge. They’re wanting to start creating a branch for every dev iteration so they don’t have to merge multiple times to the master. This sounds crazy unruly to me. |
Beta Was this translation helpful? Give feedback.
-
|
It sounds like they do choose squash when they merge, is that the issue? I’m not even sure what squashing is. Sorry, I probably should take a class in this tool or something… |
Beta Was this translation helpful? Give feedback.
-
|
stonkers:
That’s actually good practice, because it allows many people to work on many things in parallel without getting in each other’s way, and later merge their work. That’s basically what Git was made for. See Git - Branching Workflows for the general idea. One thing to keep in mind coming from other workflows is that branches are cheap in Git. A branch is basically just a pointer to a commit that can get updated. Branch names holds no meaning to Git at all, you can use whatever works for your workflow. And personally I find names that hint at the purpose a lot more helpful than version numbers, except maybe if the branch is used to maintain a stable release series for that version.
stonkers:
Yes, definitely. Squashing discards all the original commits and creates a new one that contains the sum of changes. After that Git won’t be able to connect the new commit to the original ones, creating chaos. In my own projects I completely prohibit squash merges. |
Beta Was this translation helpful? Give feedback.
-
|
airtower-luna:
Thanks so much! Maybe this will make what we’re doing work better. The team is way too small to worry about stepping on each other… |
Beta Was this translation helpful? Give feedback.
That’s actually good practice, because it allows many people to work on many things in parallel without getting in each other’s way, and later merge their work. That’s basically what Git was made for. See Git - Branching Workflows for the general idea.
One thing to keep in mind coming from other workflows is that branches are cheap in Git. A branch is basically just a pointer to a commit that can get updated. Branch names holds no meaning to Git at all, you can use whatever works for your workflow. And personally I find…