3 ms·
When you merge the dev branch in the feature branch, you create a new commit with 2 ancestors. While this is all done very well in git and allows for perfect in
by ulf 16y ago
When you merge the dev branch in the feature branch, you create a new commit with 2 ancestors. While this is all done very well in git and allows for perfect inspection, it makes it nonetheless harder to follow the history of your feature branch, since now you have two sources for changes. I just find it easier to make the history linear in that case, because it is easier to analyse in retrospect.
- samstokes 16y agoI actually prefer having two ancestors, because you can analyse different kinds of change in isolation. If your branch was to add a new widget to the UI, and there's a regression I'm trying to find in the backend data munging code, it's better if I can trivially ignore all the changes from the new-ui-widget branch, because I know that's very unlikely to have broken the data munging. That's harder to do if you've linearised the history.
- a1k0n 16y agoNot really, because every changeset from the new-ui-widget branch shows up after the point at which the rebase happened, so there is a clear cutoff in the git log between branch changes and master/upstream changes after you've rebased.
- Xurinos 16y agoYou will thank me later: git log --graph