[L2Ork-dev] git rebase

[Jonathan Wilkes]

Moving Albert's response to my question about git rebase here on the list:

Albert wrote:
> Thanks!

>> At some point I'd like you to show me how to do this.

> Well, it's not that hard, git rebase A just replays your commits on the currently checked out branch (say, B) on top of A, starting from the point where A and B diverge. The end result is the same as with git merge A (and you'll have to fix pretty much the same conflicts if both branches modify the same file in different ways), only that you now have all the commits of B positioned neatly after the commits of A, instead of being a jumbled mess. The price you pay is that you're rewriting history on B, so you'll have to use git push -f (force push) to get your branch updated on the remote. At which point other people having checked out your B branch and working on it may get angry at you. ;-) But that's expected with the kind of temporary branches you create for doing merge requests, where you usually rebase just once directly before your branch gets merged. If it's a bigger, more permanent branch with many people working on it, however, then it's probably better to use git merge like on the master branch, and you can actually protect a branch to enforce that policy (at least I can do that on Github and Bitbucket, I think that it's possible on Gitlab as well).

> In practice this means that, instead of, say, running git merge master on your feature branch, you'd be running git rebase master instead, and fix any conflicts. At which point your feature branch should neatly merge into the master branch, basically it's just a fast-forward now. So you either directly merge into master yourself (if you're Jonathan and can push to master), or force-push your feature branch (git push -f) to your remote branch, prepare a merge request for it, and wait for Jonathan to come along. If your feature branch has to wait a wee bit longer than expected, and other stuff goes into master in the meantime, then you just redo the rebase and force-push once again, to have the branch and merge request updated accordingly.

> The web interface has an option for this too, I believe. But I strongly prefer to do all this kind of stuff in my local clone where I can quickly and easily create backup branches, test things out and inspect the results, and just redo everything from scratch if things go awry.

>> I got stuck in a weird rebase state that consequently caused me to lose some data in the working directory of a completely different branch.

> Yeah, if you completely mess up and suspect that your branches are in an inconsistent state, then it's often easier to check out a completely fresh clone and just start over. It's been a while that I had to do this, though, so either git, or I, or we both got better. ;-)

The problem I ran into is that an error about a botched rebase on a
throwaway branch followed me around when I checked out a completely
unrelated branch. Since I had already made some changes to files on
the new branch before staging them, apparently the only "right"
solution after that was to copy all my changed files to a directory
outside of the repo, abort the rebase from the other branch, then
paste everything back. Then I'd be doing ad hoc version-control to
avoid losing data in a version-control system, which should never have
to happen.

-Jonathan