Menu
I'm currently working on implementing guidelines for git usage in a fairly complex development environment, and while I think I have the basics set up pretty well, there is one question in particular I would like some input on if that's at all possible. This isn't so much a purely technical question, as in that it's more about which of the available options is most appropriate.
Basically, I'm leaning towards a system that closely mirrors the common "git flow" structure (http://nvie.com/posts/a-successful-git-branching-model/), with some exceptions to adapt it to our development environment. In short:
So far, it's really helped us streamline our development and prevent conflicts between projects. The one detail that's spawned some debate here is; should we merge feature/ticket branches back into their respective origins with the '--squash' option? I'm somewhat of a fan of this, and what I like about it:
Maybe these reasons won't turn out to be good enough, and maybe there's good reasons not to use '--squash' in this scenario. Any thoughts?
510
As a general rule, when merging a pull request from a feature branch with a messy commit history, you should squash your commits. There are exceptions, but in most cases, squashing results in a cleaner Git history that's easier for the team to read.
You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren't necessarily important to retain in the Git history.
Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch.
3 Answers. Show activity on this post. In my opinion, and bear in mind, this is just an opinion, and you will likely get different answers, you should NOT squash the commits when merging into master from the develop branch. Doing so would lose a lot of the history of the changes that have been made.
It squashes the commits on main (line 20 and line 14) into one commit and does not have a commit path from main. git merge --squash alters commit history but produces cleaner history. It seems that all development only happens on feature. This strategy is often used when a pull request is merged — merge to main from feature.
Don’t squash: the small commits are useful especially for later tracking down of bugs with git bisect, and anyway you don’t want to change the history much. Just use a merge commit ( git merge --no-ff) to keep the history organized. Tracking down bugs become harder not easier when there are a lot of noisy meaningless intermediate commits.
(a) if you decide to squash before merging, then all of those individual commits from your feature branch will be combined into a single commit. The main commit history, therefore, will only show a single commit for this integration.
This strategy is often used when a pull request is merged — merge to main from feature. Our example is in the opposite direction, although the concept is the same. In a way, it does not matter how many merge commits you have on the feature branch. When they’re merged into the main branch with squash, it shows all feature development as one commit.
[S]hould we merge feature/ticket branches back into their respective origins with the
--squashoption?
It all depends how fine-grained you want the history of your repo to be. Keep in mind that version control, via commit messages, is a form of code documentation. Squashing willy-nilly is certainly not good practice. It may be fine for a hotfix branch, but rarely is for a substantial feature branch.
As an analogy, imagine if you asked me for a lend of my Lost DVD boxset (i.e. you cloned my repo), and I just gave you the box, no DVDs, and told you
Here, just read the summary of the series on the backcover. That should tell you enough about the plot.
So, by all means, squash your commits when you want to get rid of intermediate steps that are needlessly detailed or not self-contained enough, but not to the point that it obscures the evolution of your repository.
(I discuss this matter further in this Twitter thread.)
101
Don’t squash: the small commits are useful especially for later tracking down of bugs with git bisect, and anyway you don’t want to change the history much. Just use a merge commit (git merge --no-ff) to keep the history organized.
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
