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.
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
align with newer version,
more tests, etc. This option will simplify history view, but it is only for mature teams.
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.
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