4 ms·

You could simply merge that into your feature branch, but that would result in one of those nasty merge commits...It’s as if you didn’t start working in the fea

You could simply merge that into your feature branch, but that would result in one of those nasty merge commits...It’s as if you didn’t start working in the feature/login branch before the commits you pulled in were made. Nice, huh? I'm genuinely not sure how I feel about git rebase. Two questions. First, what is so nasty about such a merge commit? People complain about these merges a lot, but is the objection just aesthetic? Why is such a merge bad? Second, from a historical point of view, you did "start working in the feature/login branch before the commits you pulled in were made." So why would you want the history to look otherwise? I completely understand the use of rebase or --amend to fix a typo or a forgotten file commit, but in a case like this, I'm not sure what to think. I'm inclined to prefer the history to show what actually happened, rather than a tidied up version of the past.

samstokes 16y ago
what is so nasty about such a merge commit? From the article: Merge can be used when you want to merge a feature branch back into your development branch. That way, you’ll be able to see when you merged in what in the future because you have that merge commit I called “nasty” before. It isn’t, really. I've come to prefer merges for this case. It reflects reality - you really were developing on a separate history for a while, you're not interweaving bugfixes from master with feature work, etc. And it visually (and logically) groups the commits for the feature, so it's very easy to review or revert the feature as a whole, instead of having to figure out exactly which commits in the big linear history are relevant (or having to religiously tag every time you do anything interesting). The current git visualisation tools (gitk, gitg, gitx) aren't very good at displaying histories with interesting merge structures, but I confidently predict someone will release an awesome dotviz-based history visualiser soon which makes it easy to navigate forests of branches and merges. That said, as the article describes, rebase does handle conflicts (syntactic and semantic) better than merge does. Because it rebases a commit at a time, you have to think about how the upstream change affects each change that you made in the feature branch, which means you're much less likely to resolve the conflict in a way which breaks some subtle assumption you baked into the code two weeks ago. I've sometimes taken the approach of first rebasing my feature branch onto the latest master to resolve any conflicts, and then doing a 'merge --no-ff' to explicitly create a merge commit to get the visual history marker.
- deleted 16y ago
  [deleted]
ulf 16y ago
A merge is totally fine, if you really are merging something. But in the case of feature branches you often have the situation, that you work on a very isolated thing. Simultaneously, someone works on the branch which you branched your feature off. You want to get the current state for some reason. By using a merge you would add complexity that is not necessary at this point, because it would just originate in the fact, that you branched off sometime sooner. It would not really be a merge in "content". I find rebasing in this occasion perfectly suitable, since it removes this layer of complexity that noone needs at this point. You just pretend to have branched off later, which is alright. When you are finished with your feature you use a regular merge to get back in your dev branch, since now you really ARE merging something.
- telemachos 16y ago
  By using a merge you would add complexity that is not necessary at this point, because it would just originate in the fact, that you branched off sometime sooner. It would not really be a merge in "content". I find rebasing in this occasion perfectly suitable, since it removes this layer of complexity that noone needs at this point. What exactly is the complexity you have in mind here? (I'm not trying to be contentious: I honestly don't see it.)
  - 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 ago
      I 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.

samstokes 16y ago

what is so nasty about such a merge commit? From the article: Merge can be used when you want to merge a feature branch back into your development branch. That way, you’ll be able to see when you merged in what in the future because you have that merge commit I called “nasty” before. It isn’t, really. I've come to prefer merges for this case. It reflects reality - you really were developing on a separate history for a while, you're not interweaving bugfixes from master with feature work, etc. And it visually (and logically) groups the commits for the feature, so it's very easy to review or revert the feature as a whole, instead of having to figure out exactly which commits in the big linear history are relevant (or having to religiously tag every time you do anything interesting). The current git visualisation tools (gitk, gitg, gitx) aren't very good at displaying histories with interesting merge structures, but I confidently predict someone will release an awesome dotviz-based history visualiser soon which makes it easy to navigate forests of branches and merges. That said, as the article describes, rebase does handle conflicts (syntactic and semantic) better than merge does. Because it rebases a commit at a time, you have to think about how the upstream change affects each change that you made in the feature branch, which means you're much less likely to resolve the conflict in a way which breaks some subtle assumption you baked into the code two weeks ago. I've sometimes taken the approach of first rebasing my feature branch onto the latest master to resolve any conflicts, and then doing a 'merge --no-ff' to explicitly create a merge commit to get the visual history marker.

deleted 16y ago
[deleted]

ulf 16y ago

A merge is totally fine, if you really are merging something. But in the case of feature branches you often have the situation, that you work on a very isolated thing. Simultaneously, someone works on the branch which you branched your feature off. You want to get the current state for some reason. By using a merge you would add complexity that is not necessary at this point, because it would just originate in the fact, that you branched off sometime sooner. It would not really be a merge in "content". I find rebasing in this occasion perfectly suitable, since it removes this layer of complexity that noone needs at this point. You just pretend to have branched off later, which is alright. When you are finished with your feature you use a regular merge to get back in your dev branch, since now you really ARE merging something.

telemachos 16y ago
By using a merge you would add complexity that is not necessary at this point, because it would just originate in the fact, that you branched off sometime sooner. It would not really be a merge in "content". I find rebasing in this occasion perfectly suitable, since it removes this layer of complexity that noone needs at this point. What exactly is the complexity you have in mind here? (I'm not trying to be contentious: I honestly don't see it.)
- 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 ago
    I 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.