[cocoflunchy]

This is a great tool, thanks so much !

I have trouble understanding the rebase workflow: What is the difference between these two sequences?

    git checkout -b bugFix
    git commit -m "fix"
    git checkout master
    git commit -m "master stuff"
    git rebase bugFix
    git checkout bugFix
    git rebase master

and

    git checkout -b bugFix
    git commit -m "fix"
    git checkout master
    git commit -m "master stuff"
    git checkout bugFix
    git rebase master
    git checkout master
    git rebase bugFix

Is it just the order of the commits in the final tree that will be different? Or I am missing something else?

Instinctively I would tend to do the first one, but that was not what lesson 4 expected...

[csense]

Rebase works by discarding commits and replacing them with different commits.

If you rebase, then anyone who has the old commits in their repo will have to use git reset --hard to switch to the new branch. In other words, rebase inconveniences all other users of a branch. So you can use it freely on branches that only you work on, but you should be reluctant to use it on branches used by other people -- especially popular branches like "master".

If you use your first workflow, the app clearly shows that you discard the commit C3 ("master stuff") and replace it with a different commit C3'. This requires everyone on master to reset.

If you use your second workflow, the commit that you're discarding is C2 ("fix") instead. This means that only people who checked out C2 on bugFix need to reset.

[cocoflunchy]

Thanks, that makes sense.

[jedbrown]

In both cases, the second 'git rebase' is just a fast-forward (moving the ref ahead without modifying the graph). Thus we need only distinguish what happens in the first 'git rebase', which is a different choice of which patch gets rewritten. Note that you can shorten

  git checkout bugFix
  git rebase master

to

  git rebase master bugFix