Some notes on my 'commit local changes and rebase' Git workflow
A month or so ago I wrote about how I don't commit changes in my working repos and in reaction to it several people argued that I ought to change my way. Well, never let it be said that I can't eventually be persuaded to change my ways, so since then I've been cautiously moving to committing my changes and rebasing on pulls in a couple of Git repos. I think I like it, so I'm probably going to make it my standard way of working with Git in the future.
The Git configuration settings I'm using are:
git config pull.rebase true git config rebase.stat true
The first just makes '
git pull' be '
git pull --rebase'. If I
wind up working with multiple branches in repos, I may need to set
this on a per-branch basis or something; so far I just track
origin/master so it works for me. The second preserves the normal
git pull' behavior of showing a summary of updates, which I find
useful for keeping an eye on things.
One drawback of doing things this way is that '
git pull' will now
abort if there are also uncommitted changes in the repo, such as I
might have for a very temporary hack or test. I need to remember
to either commit such changes or do '
git stash' before I pull.
(The other lesson here is that I need to learn how to manipulate rebase commits so I can alter, amend, or drop some of them.)
Since I've already done this once: if I have committed changes in
a repo without this set, and use '
git pull' instead of '
--rebase', one way to abort the resulting unwanted merge is '
reset --hard HEAD'. Some sources suggest '
git reset --merge' or
git merge --abort' instead. But really I should set pull rebasing
to on the moment I commit my own changes to a repo.
(There are a few repos around here that now need this change.)
I haven't had to do a bisection on a
commit-and-rebase repo yet, but I suspect that bisection won't go
well if I actually need my changes in all versions of the repo that
I build and test. If I wind up in this situation I will probably
temporarily switch to uncommitted changes and use of '
probably in a scratch clone of the upstream master repo.
(In general I like cloning repos to keep various bits of fiddling around in them completely separate. Sure, I probably could mix various activities in one repo without having things get messed up, but a different directory hierarchy that I delete afterwards is the ultimate isolation and it's generally cheap.)
Comments on this page:Written on 03 July 2015.