On the other hand, if everyone on a given development team is working from one branch most of the time (say master) then the log can get quite noisy with all of the “merge branch blah” commits from your day to day “git pull origin master” workflow. This can be quite helpful to be able to, at a glance, tell when and where a parallel branch has been folded back into the master branch. Git does this in order to track the point at which two diverging repositories have come back together into a common ancestor. When you merge, Git creates the extra commit on top of the stack that we talked about earlier. Merge is perfectly fine for managing your code. Technically speaking you can fully use git without ever using rebase. When and why should we use Rebase instead of Merge? As far as git is concerned these are new commits…įirst, rewinding head to replay your work on top of it.įast-forwarded master to fde4b2d5cda60905fcf5973bc17cd051ec2c336d. If we had two local commits prior to the rebase then we would end up with two brand spanking new commits after a successful rebase - both with new IDs. To say it another way - the original local (red colored) commit is GONE and, as illustrated below, is replaced with a new commit with an entirely different ID (green colored). Now we get to the fundamental difference between a merge and a rebase: a rebase ALWAYS gets rid of all your original commits and creates brand new one’s that get placed on top. After correcting the conflict(s) you would type “git rebase -continue” as directed by the conflict message. If conflicts are found while attempting to play back your changes it throws you into an unnamed branch and gives you a chance to merge everything together. After it unwinds all your hard work it then stuffs the new commits from the remote branch onto the stack and then plays your changes back on top of them - literally creating a new “base” for which to put your local commits on top of. Given the previous scenario, when we do a pull –rebase (which calls fetch and then rebase instead of merge) it actually un-commits all of your local commits that are not already in origin:master (or whatever branch you are rebasing off of). In the case there were no merge problems it is just an empty commit. This commit will contain the result of any merge conflicts that you had to resolve. Note the green “merge commit” placed at the top of my hypothetical commit stack. The change that lived on origin but not on my local repository is now merged in. Git-pull executes a fetch and then a merge all in one command. Realizing that I am not up to date with origin:master I execute the command “git pull origin master”. Not knowing that another developer has pushed new changes up to origin:master, I attempt a push myself and am promptly rejected. During this time another developer commits changes to his local branch instance and pushes them up to origin:master (blue). So now the work day has begun and I commit some changes to my local branch instance (red). In other words we see that our local branch, “master”, and the remote branch that it is tracking, “origin:master”, are both perfectly in sync. So each black bar represents all of the commits that each instance has in common. This could be hosted on or just a $200 linux box sitting under someone’s desk. In this situation this is where all code ends up prior to deployment. A very typical scenario is where you would have one instance of a given repository living on some remote server somewhere acting as the home of your authoritative “master” branch instance. So first let’s talk about how Git handles a standard merge.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |