DEV Community

Cover image for What is your git merge strategy?

What is your git merge strategy?

Paweł Ruciński on January 07, 2019

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 fami...
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

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

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 • Edited

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.