Git merge - squash or not squash?
I am currently working on implementing guides for using git in a fairly complex development environment, and while I think I have the basics set up very well, there is one question, in particular, I would like to get some data if all possible. This is not so much a technical question as the one that is most appropriate.
Basically, I'm leaning towards a system that closely mirrors the overall structure of the git stream ( http://nvie.com/posts/a-successful-git-branching-model/ ), with some exceptions to adapt it to our development environment. Shortly speaking:
- The project will have at least a "developed" and "master" branch
- "master" will contain the last finished production code
- 'develop' will contain the last merged code
- Everything else will be either under "Feature / Ticket {Number}" or "hotfix / ticket {number}"
- Feature branches will run from 'develop', patch branches from 'master'
- The number in the branch name will always match the ticket number in our own change / error system.
- Features can be tested individually, but also in combination, by creating the appropriate branch or merging it into the "development" first
So far, this has helped us optimize our development and prevent conflicts between projects. One detail that has generated some debate here; do we have to merge the property / ticket branches back to their respective origin with the "-squash" option? I'm a bit of a fan of this and what I love about it:
- The development git log remains clean and readable, all commits will simply include the name of the original branch (which tells us if it was a fix or a feature and a ticket number)
- Even after cleaning up the original feature or patch branch, the merge cannot cause a mess after that
These reasons may not turn out to be good enough, and perhaps there are good reasons not to use "-squash" in this scenario. Any thoughts?
source to share
[S] can we merge the property / ticket branches back to their respective origin with the option
--squash
?
It all depends on how thin you want your repo history to be. Keep in mind that version control via commit messages is a form of code documentation. Twisting willy-nilly is certainly not a good practice. This may be fine for a patching branch, but rarely for a substantial feature branch.
As an analogue, imagine if you ask me a favor for 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 series summary on the back. That should tell you enough about the plot.
So, be sure to crush your commits when you want to get rid of intermediate steps that are too granular or not autonomous enough, but not to the point that they hide the evolution of your repository.
source to share