3 ms·

I would normally rebase the feature branch onto master if I need fixes from master and no one else is working on it. Usually this is the case - one developer wo

I would normally rebase the feature branch onto master if I need fixes from master and no one else is working on it. Usually this is the case - one developer works on each feature in a feature branch until it becomes a Pull / merge request and gets commented on and eventually merged. I will sometimes make a fix in a feature branch that should go onto master before the feature is ready, and cherry pick it to a new bugfix branch. Once it's merged, if you rebase the feature onto master git will normally sort it all out, or you can use rebase -i to skip the cherry picked commit manually.

jillesvangurp 8y ago
Rebasing is great for branches you haven't pushed that nobody else is working on. For that case, definitely rebase before you push. If that is not the case and you have previously pushed your branch somewhere remote already, rebasing would end up rewriting history and things get a bit more tricky. You can still get away with this if it is just you. Now here comes the crux: if you have a branch that you've been working on for several days, you really should be pushing it regularly to remote so that you don't lose your work. Also you should be creating lots of small commits and create a giant commit that touches everything. So if you then go and rebase, you are potentially rewriting history for someone. If that is at all going to be an issue, the better solution is to create a new branch and push that (or for Github folk, create a new pull request). Many bigger projects will be configured to flat out reject rebased histories overwriting existing ones. Most of the public projects only allow you to create pull requests that have to be accepted by someone with commit rights on the main repo. And many of those people prefer clean rebased histories when they are merging so that they can do a so-called fast forward merge where the history stays nice and linear. If you have a branch with lots of back and forward merges, that is likely not going to go down well. It makes reviewing a lot harder and you may be better off creating a new branch and then rebasing the old one on top. Typically you'll have a bit of work re-solving all the conflicts you resolved earlier. This is a good argument against long lived branches. Cherry-picking is sometimes useful but it potentially creates issues for the subsequent merge (fast forward or not). The nice thing with the pull request model is that it is not the problem of whomever cherry-picked but only that of whomever created the branch. If there is a conflict, it would be theirs to sort out before they can get their PR merged. If you are cherry-picking small fixes, this is usually not a big issue and a perfectly valid way of solving a small issue without landing a lot of work in progress.
- sornaensis 8y ago
  Rebasing is perfectly fine for shared branches, all you have to do is pull —rebase and push —force-with-lease when changing branch history. I do this at work for all the feature projects I work on with my team. You mostly run into problems when people get confused about what is happening when they see the branch history has changed. Git histories are wonderful and immutable so messing around with commits is quite easy if you know how to move branches around to undo changes if you mess up.
  - jamietanna 8y ago
    I found recently (https://www.jvt.me/posts/2018/09/18/safely-force-git-push/ https://www.jvt.me/posts/2018/09/18/safely-force-git-push/) that `--force-with-lease` can actually be dangerous, you need to specify the ref, too
  - jillesvangurp 8y ago
    Git histories are only immutable if you don't rewrite them with --force. That's why it's called --force. It means you messed up and need to rewrite history. Nice to have the option but probably not great to make it a habit to mess up your history. It's a feature that gets turned off server side in bigger projects and on OSS projects you don't get to push your changes at all and instead you need to work to get people to pull your changes. I'd argue that's a great way to isolate yourself from people misbehaving on their own branches since it is entirely their problem to get their branch in a a shape where it is straight forward to pull (as in fast forward merge). Rebasing can be a valid tool to get there. Force push is not thing generally in such projects except maybe on your own private fork.

jillesvangurp 8y ago

Rebasing is great for branches you haven't pushed that nobody else is working on. For that case, definitely rebase before you push. If that is not the case and you have previously pushed your branch somewhere remote already, rebasing would end up rewriting history and things get a bit more tricky. You can still get away with this if it is just you. Now here comes the crux: if you have a branch that you've been working on for several days, you really should be pushing it regularly to remote so that you don't lose your work. Also you should be creating lots of small commits and create a giant commit that touches everything. So if you then go and rebase, you are potentially rewriting history for someone. If that is at all going to be an issue, the better solution is to create a new branch and push that (or for Github folk, create a new pull request). Many bigger projects will be configured to flat out reject rebased histories overwriting existing ones. Most of the public projects only allow you to create pull requests that have to be accepted by someone with commit rights on the main repo. And many of those people prefer clean rebased histories when they are merging so that they can do a so-called fast forward merge where the history stays nice and linear. If you have a branch with lots of back and forward merges, that is likely not going to go down well. It makes reviewing a lot harder and you may be better off creating a new branch and then rebasing the old one on top. Typically you'll have a bit of work re-solving all the conflicts you resolved earlier. This is a good argument against long lived branches. Cherry-picking is sometimes useful but it potentially creates issues for the subsequent merge (fast forward or not). The nice thing with the pull request model is that it is not the problem of whomever cherry-picked but only that of whomever created the branch. If there is a conflict, it would be theirs to sort out before they can get their PR merged. If you are cherry-picking small fixes, this is usually not a big issue and a perfectly valid way of solving a small issue without landing a lot of work in progress.

sornaensis 8y ago
Rebasing is perfectly fine for shared branches, all you have to do is pull —rebase and push —force-with-lease when changing branch history. I do this at work for all the feature projects I work on with my team. You mostly run into problems when people get confused about what is happening when they see the branch history has changed. Git histories are wonderful and immutable so messing around with commits is quite easy if you know how to move branches around to undo changes if you mess up.
- jamietanna 8y ago
  I found recently (https://www.jvt.me/posts/2018/09/18/safely-force-git-push/ https://www.jvt.me/posts/2018/09/18/safely-force-git-push/) that `--force-with-lease` can actually be dangerous, you need to specify the ref, too
- jillesvangurp 8y ago
  Git histories are only immutable if you don't rewrite them with --force. That's why it's called --force. It means you messed up and need to rewrite history. Nice to have the option but probably not great to make it a habit to mess up your history. It's a feature that gets turned off server side in bigger projects and on OSS projects you don't get to push your changes at all and instead you need to work to get people to pull your changes. I'd argue that's a great way to isolate yourself from people misbehaving on their own branches since it is entirely their problem to get their branch in a a shape where it is straight forward to pull (as in fast forward merge). Rebasing can be a valid tool to get there. Force push is not thing generally in such projects except maybe on your own private fork.