Popular posts

j, Marco Alka, what about 'squashing' do you guys squash stuff or leave it, but if you do then do you do it before you rebase/merge or after?

Hipkiss Squashing is heavily discussed, because by squashing, you lose all of the commit history. Imho, squashing should be done once you are finished developing a feature and want to only push it into one of your main branches (mostly develop or master) as one single commit. That way, that one commit reflects the entire change introduced by the feature.

Marco Alka Hipkiss I agree with marco, squash should only be done if you're sure you're done, since if you squash the merged branch you will not be able to continue a classic workflow.

I for example rebase my feature branches all the time ontop of the development branch. if i squash the commits from this feature branch, find out I missed something, I cannot just rebase again and just push the fixes in the same branch -> because I removed the references -> conflict potential increases.

This is also about taste -> because you can just open a new branch + MR / PR. But I have a strict 1 ticket 1 branch policy so it's overhead. But that's a formal burden defined by myself.

j so can a general rule be suggested; rebase if the master/dev branch is ahead of the feature branch otherwise merge?

Hipkiss in short, yes.

I a least do it like that. A rebase can be more frustrating since you have apply some changes over and over again, but it also pushes the responsibility of 'merge' to the feature branch not to the development / master branch. I do fast forward merges as well, ariya.io/2013/09/fast-forward-git-merge

• every dev is responsible for his feature branch -> update on the 'development' branch happens every dev should rebase his branch.
• pull request is happening -> we merge the rebased branches down.

that's my workflow, it has a clean history.

j Makes sense. Thank you. The way I always wanted to do it was to squash the feature branch then merge the dev into the feature (if there's automated cloud testing) and then merge back to the dev branch for release when everything is green. Which I guess is fine for smaller projects but when you have dozens of branches then I think it makes sense to rebase, rather than just doing a lot of merges.