4

I'm working in a team which is growing and making use of git. We are generally working in our own branches.

I pulled some changes from another workers repository. His changes eventually were added to and merged into a master branch with a squash commit.

When I tried to fetch from master and merge I got a load of conflicts. I am thinking this is because of the squash merge and the fact that it will confuse the merge tracking. Is there an easy way out of this?

Secondly. If developers are working on a number of branches and possibly needing each others changes before they go into master is there a way to handle this while continuing with the squash commits on master.

Rebase is mentioned a lot. But I don't see how this will work with more than one root branch?

Jeremy French
  • 11,707
  • 6
  • 46
  • 71

2 Answers2

3

Yes, squashing plays havoc with repeated merging. The best advice is don't squash - specifically, don't squash things that are public. Rewrite your own commits before you share them with others, but once they're shared, they should remain as they are, with regular merge commits.

You can still get reasonable log output by using git log --first-parent to condense the log of a merged branch down to just the merge commit, while keeping the actual history intact.

Amber
  • 507,862
  • 82
  • 626
  • 550
2

I would add that squashing only causes havoc when the branches are public, if a dev works locally on a branch with messy commit such as "oh bummer broke this again" followed by "it works!" followed by "darn it's broken again" followed by "ok fixed it now" it's easy to squash these (before they are pushed to a remote repo or shared) into one commit with a nice message about what has changed in the code.

once pushed to a remote repo this will look identical to a single normal commit created without squash, as if the developer was programming with angels making sure everything he did was perfect, and the dev is then free to use git locally for incremental changes, which I find usefull for figuring out what I most recently broke in the code.

my take on things: squash is a great tool for a local workflow, ie one dev. once a commit is shared it should never be squashed.

Fire Crow
  • 7,499
  • 4
  • 36
  • 35
  • [This post](https://www.braintreepayments.com/braintrust/our-git-workflow?) provides a way to fix the merge-conflicts while squashing: merge _back_ the squashed commit into the other branch. If you don't want to merge the entire branch back though you'd have to create an intermediate branch... – Tobias Kienzler Aug 16 '12 at 09:13