Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!)



There's also an option to squash at merge time, which is commonly used going from a feature branch to an integration branch.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: