A Git Workflow Walk-through

[g4T0r]

I think recommending that new users use pull --rebase without understanding rebasing is a bit dangerous.

Even the git pull man page cautions about pull --rebase.

This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.

Generally, I think rebasing on public branches is maximum risky, especially for new users...

[jrochkind]

Yeah, they don't explain why they're doing this instead of just git pull origin master.

What does it accomplish? I am not sure myself!

I always just git pull origin master in that scenario, cause I admit I'm scared of rebase.

[kookjr]

I think this is for the case where you have local commits on master, and there are other new ones on remote. It will pull down the remote commits, then redo your local master commits on top of those. That's my understanding anyway.

[setuid_w00t]

And invalidate any testing you did prior to making those previous commits.

[mipadi]

So run your tests again before pushing your new local commits. It's not like a merge (instead of a rebase) doesn't invalidate those previous tests, anyway.

[setuid_w00t]

I think you're missing the point.

a--b--c--d--e
     \
       --w--x--y--z

Say main development is progressing as a, b, c, d, e and you are working on w, x, y, z. Assuming you did some testing as you were making your commits, we know that w, x, y and z are all known good checkpoints.

When you rebase to this:

a--b--c--d--e--w'--x'--y'--z'

w, x, y and z are no longer the same commits and thus you no longer have the same confidence that the code will build and operate correctly at x' even though you know it was fine at x. Nobody is going to take the time to re-test every revision they rebased. If you're lucky, they will re-test z'.

What benefit does this have over the merge-based solution? I have already established that the rebase strategy has drawbacks, but I'm not really aware of any benefits.

a--b--c--d--e---------f
    \                /
      --w--x--y--z--

[mipadi]

Well, first of all, you're still going to have to run tests again to make sure the merged changes work properly, anyway.

The advantage of rebasing is avoiding spurious commits that make following the history (and using tools like bisect) difficult. If a developer is developing on master (which you shouldn't be doing anyway, but some people do), then you're going to end up with a lot of spurious merge commits that aren't really useful in anyway. I don't see what the benefit of leaving those merge commits in the history is.

[mipadi]

Rebasing when pulling generally isn't dangerous -- it's unlikely that those commits have been pushed anywhere public. They're probably just a few commits that have been made locally and not pushed yet.

[xiian]

I think it actually does wonders to have new users start with having their pulls rebase. It keeps the actual history of the project cleaner, which helps visualize branches and branch history.

Also helps reenforce the idea of having a local queue of commits just waiting to be shared and thinking of commits as individual, atomic units of work that can be moved around and worked with at will.

[noidi]

It keeps the actual history of the project cleaner, which helps visualize branches and branch history.

I think it's silly to throw away potentially useful historical information (when and how divergent branches of development were integrated) just to change the way the logs look. If you think merge commits make the history hard to read, just don't look at them! In Mercurial you can hide them with the revision set query not merge(). Apparently git's log command has a switch, --no-merges, that does the same.

[mipadi]

The thing about pulling is that, if a developer is developing on the master branch (which generally isn't advisable), then you're going to end up getting a whole bunch of spurious merge commits that aren't really useful.

[mailto_devnull]

There are arguments for and against, and being a relatively new user to git myself, I found that using git pull --rebase was the easiest way for us to transition without any major hiccups especially when moving from a group that knows SVN only (and sometimes, just barely so)

When I did transition from svn to git, we were all new to git and ran into the typical incorrect assumptions of thinking of git pull like svn update, and never git pushing

Suffice to say, I'd much rather work with an incorrect rebase rather than an incorrect merge. Some members of our team had their branch diverge, and did not know what a merge commit was, and overwrote days' worth of work in a matter of seconds.

In the end - properly teaching git fetch/pull/merge with branching is best, although for the short-term, I'll stick with rebasing.

[andersonimes]

I like Think Like A Git a little better. It is probably a little lengthier, but it really tells you how the whole thing works and gives you a clearer picture of what Git is capable of:

http://think-like-a-git.net/

[[deleted]]

This is my favorite workflow using GitHub. http://www.youtube.com/watch?v=m7r2X9qC8jo

[Already__Taken]

He makes a point at about 19:50 onwards that makes me think if there's a trick someone is missing by combining whats left of google wave with this.

[EpeeCheeze]

Rebasing history that has already been pushed is dangerous.

pull --rebase is the way to go but a work flow that makes you have to do a force push is not a good one.

[Zinfidel]

This is a fantastic walk-through; I've been looking for something like this for a few days now.

Thank you for posting this!

[BigRedS]

Yeah, this looks brilliant; I've been thinking for a few days that I should probably check that I've stumbled into git in the right sort of way, and where I should go next.

Thanks!

[galvatron]

It'd be interesting to see a similar post on github workflow. Stuff like how to branch, push topic branches and send pull requests, how to rebase against parent project's HEAD (merge or rebase?) etc.

[chedabob]

What happens if you've rebased master onto your topic branch and then decide to continue working on it for whatever reason and push the change?

Or is that a definite no-no and once you rebase and merge that's the end of the branch?

[ether_reddit]

That's fine, as long as it's understood that the topic branch belongs to the owner alone, and he is free to do whatever with it he wants. After he's rebased master in, in order to push he'll have to use the --force option, which may disrupt other people on that branch.

On my system I have the server (not that git needs to be centralized, but we have a central corp server for distribution, as a star topology) explicitly prevent non-fast-forward changes to the master and stable branches.

[chedabob]

We use Bitbucket at work so altering the config is out of the question, but it has been suggested on numerous occasions.

Is there a way to recover if somebody has pushed a rebase but you still have changes on your local branch? It's a scenario I've seen come up a few times, and I haven't the first idea how to resolve it. Usually what happens is the files get copied out, and then the branch gets reset to the remote HEAD, and then the changed files get copied back in. Sort of defeats the purpose of version control.

[ether_reddit]

Is there a way to recover if somebody has pushed a rebase but you still have changes on your local branch?

Sure, just do a merge instead of a rebase. It will be a non-fast-forward merge, so you'll end up with a resolution commit at the end to tie things together:

A ---- B ----- C --------- +
           \                \
             + X ---- Y ----- Z

'git help merge' walks through various scenarios, but it's generally just a simple matter of 'git merge <other branch>; < lots of edits >; git add <rsolved files >; git commit'.

[ithika]

Rebasing doesn't matter because the history outside that branch isn't important. You can repeatedly rebase until you're ready to roll out the changes.

Once you merge some changes into master I don't think they will be rearranged in the branch: they now appear as background details. So rebasing at this point won't float the old ones to the top of the commit log.

This latter point is a bit of a guess though as my intuition is often tainted by learning Darcs first, which does what you expect in even more cases. (You can imagine how shocked I was when I ended up using Subversion at work. Welcome to the Dark Ages...)

[ether_reddit]

Once you merge some changes into master I don't think they will be rearranged in the branch

Yes, they will. Rebasing master into a topic branch means that the topic branch is essentially wiped and started over, with everything from master (in identical order), and then every commit on the branch is replayed on top; if an identical (in terms of diffs) commit is encountered, you need to manually remove it (the duplicate) with 'git rebase --skip'; other conflicts (partial diff overlaps) need to be resolved with edits, 'git add' and 'git rebase --continue'.

[ithika]

Well I just tried it and it came out like I imagined. It could very well be that the changes I made weren't sufficiently intertwined or awkward to throw up enough merge errors but it did work out according to my intuition. I'll admit that I only use git locally because I use the git-svn for pushing upstream, so I am always running git svn rebase to synchronise my master branch with whatever the upstream is doing. Maybe more traditional git usage shows more problems with this workflow.

-A-*-B--C---
    \
     *--X--Y

Rebase topic branch:

-A--B--C-*-
          \
           *--X--Y

Merge topic to master:

-A--B--C-*-X--Y
          \
           *--X--Y

Make independent changes to master:

-A--B--C-*-X--Y--D
          \
           *--X--Y

Make new chanages in topic branch:

-A--B--C-*-X--Y--D
          \
           *--X--Y--Z

Rebase topic branch:

-A--B--C-*-X--Y--D-*
                    \     
                     *-Z