DEV Community

loading...
Cover image for What is your git merge strategy?

What is your git merge strategy?

meanin profile image Paweł Ruciński ・2 min read

Branching

Branching out is a common first step as you work on a new task. git checkout -b 'name of your brand new branch' should be familiar for most of you. This routine keep root branch (master/ develop whatever) clean, until someone finishes her/his work. Then you have to somehow put your changes into the root branch.
img

Merge

The default strategy, for integrating changes into a root branch is merge operation. Of course, if you meet any conflicts, you have to resolve them, but finally, the code base will be integrated.
merge

Squash

There is an option while merging changes, to use --squash. You will end up with one merge commit, put on top of the root branch history. From my perspective, this method is really risky. When a team does not stick to the pull requests/branch naming convention, it can have dramatic consequences. Imagine going back in the repository history through commit named update, align with newer version, test, more tests, etc. This option will simplify history view, but it is only for mature teams.
squash

Mix

While I was doing a research for this article, I found this. A really nice mix of the merge and squash in a single approach. Again, here you will need a mature team, to follow the naming convention, but is a nice consensus.

Question?

Personally, I prefer to use standard merge. I have met teams, which use a --squash option for all of the feature branch merge and I can see the pros of this approach. I miss detailed git history in that scenario after all. What is your default merge strategy?

Images source: git-branching-and-merging

Discussion

pic
Editor guide
Collapse
joshuadiablito profile image
Joshua Anderson

Personally, I use Github for merging pull requests and protect the main branch, that way people can't sneak bits of code in. On personal projects, I follow the same way. It means I have a place in time on the web where I can view the changes, and look back at the code :) I squash by default to keep the main branch tidy.

Collapse
meanin profile image
Paweł Ruciński Author

Do you squash on your commercial work also? How about rolling back in history in case of any mistakes/bugs?

Collapse
joshuadiablito profile image
Joshua Anderson

Yeah, I squash in my commercial work too. Especially there :P mostly there's no need to roll back - and anything can be picked/rolled back when I'm not sure about it as a single commit. How you organise your work - small pieces of functionality, easy to understand, covered with 100% unit test coverage - means the need to roll back is pretty much non existent, and it is very unlikely that you would have a low understanding of why what you have created has caused a bug.

Thread Thread
meanin profile image
Paweł Ruciński Author

If you are working alone, that this is true. In larger teams, when you can get messy repo/feature branch then, in my opinion, is better to have more granular commits :)

Thread Thread
joshuadiablito profile image
Joshua Anderson

I have worked in FE projects with 30+ people contributing to a single repo, it worked fine for us :)

Thread Thread
meanin profile image
Paweł Ruciński Author

Nice, I am a little jealous.

Collapse
jessekphillips profile image
Jesse Phillips

Merge commit, no squash. I work to communicate through my commits, so I would git frustrated loosing all that work to group my work into isolated changes.

Collapse
ozzyogkush profile image
Derek Rosenzweig

Take it on a case-by-case basis but typically I'd rather not auto-squash anything unless it only handles commit messages explicitly prefixed with fixup! or squash!. If a feature has multiple commits, I tend to believe it's because the developer did the work in logical stages that are separate enough to be units of work that could possibly get reverted independently of the rest of the changes in the branch.

Certainly have your developers do any final interactive rebasing and manual squashing/fixing up before merging the pull request though.