For implementing a new feature I created a new branch xyz
from master
.
I now have hundreds of commits done. What's the better strategy for merging xyz
into master
? Should I leave commits as they are or should I squash them in a single commit to represent the final implementation (will I be able to navigate them after that?)?
Should I get used to squash small related commits?
Asked
Active
Viewed 103 times
0

LppEdd
- 20,274
- 11
- 84
- 139
-
3Might be relevant: https://stackoverflow.com/questions/26999930/git-merge-to-squash-or-not-to-squash – Fabian Lauer Sep 27 '18 at 13:33
-
@jo_ I'm not following you, could you elaborate? – LppEdd Sep 27 '18 at 13:58
-
@lppEdd tryied in an answer to have more place – jo_ Sep 27 '18 at 14:06
1 Answers
1
The problem is that it's equivalent to saying if I knew I would have done a, b, c, d but here every thing is mixed together.
So you could try to do these smart steps but they would require you to redo most of the work (having a reference final point).
Create a new branch and report items progressively.
You could try a split like this :
- Refactoring to prepare for xxx
- Adding feature xxx
- Adding test for feature xxx
The idea is if someone must cherry-pick/reuse your code this is easier to understand (of course if you can have more than one feature / sub feature it's better) but make sure that each step builds / tests correctly.

dvaergiller
- 795
- 3
- 11

jo_
- 8,324
- 1
- 18
- 14
-
I was reading this article: https://www.internalpointers.com/post/squash-commits-into-one-git Basically they marge the last X commits in a single commit. Can the same operation be applied to commits in the "middle"? – LppEdd Sep 27 '18 at 14:10
-
-
Using "rebase -i
" you can squash commits in the middle yes (you can also move them around etc) but this will not create smart commits (my opinion). But here I'm proposing to leave your current branch in peace (it works I call it dev-branch after) create a new one (call it clean branch) an report modification by kind of work they represent (prepare / dev / test), doing this by checking out from you dev-branch creating new commit. – jo_ Sep 27 '18 at 14:45 -
Thanks! I'm actually using the interactive rebase, with -f to rewrite history, as I'm the only maintainer of that branch as of now. At least I can mitigate – LppEdd Sep 27 '18 at 14:54
-
@LppEdd ok but do create a new branch to do this (on head of your dev-barnch) so you keep your reference end point meaning once you have reworked all history if it doesn't work you can compare with dev-branch. – jo_ Sep 27 '18 at 15:09