| He is on master and probably just pulled/fetched the latest revisions. He has some work on a local feature branch. * The first command switches over to that feature branch. * The second command rebases off of master, which basically rewinds the changes on his branch and applies them to the latest version from master - think of this like getting latest and merging in your pending changes. * The third command switches back to master. * The fourth command merges the feature branch into master - this should be what is called a "fast-forward merge" and not require a separate merge commit since you rebased your branch. The rebase is really used to make it a cleaner merge back into master (and a cleaner history in general), not to squash commits in this case (though you also would use rebase to squash, that's another topic). What I pointed out is that (for me at least) the rebase from master is not usually "clean" - meaning there are merge conflicts that I have to resolve - so chaining together shell commands like this doesn't really help when the second command is going to need intervention from me before I can run the third. Hope that helps (and I hope my analysis is right or I'll look silly!) |