When merging with git merge, you only specify the branch you want to merge into the current one, and only your current branch advances.Īnother common situation where this view of branches helps a lot is the following: suppose you’re working on the main branch of a project (called “master”, say) and realise later that what you’ve been doing might have been a bad idea, and you would rather it were on a topic branch. So now A, B, C, D, E, F, G and H are on “stable”, while A, B, D, F and I are on “new-idea”.īranches do have some special properties, of course – the most important of these is that if you’re working on a branch and create a new commit, the branch tip will be advanced to that new commit. If you carry on committing on “new idea” and on “stable”, you get: A-C-E-G-H ("stable") … then you have the following: A-C-E-G ("stable")
If you then merge “new-idea” into “stable” with the following commands: git checkout stable # Change to work on the branch "stable" So the commits A, C and E are on “stable” and A, B, D and F are on “new-idea”. For example, suppose you have two branches, “stable” and “new-idea”, whose tips are at revisions E and F: A-C-E ("stable")
This definition has some perhaps unexpected implications. This means that manipulating them is a very lightweight operation – you just change that value. I would suggest that you think of branches in terms of what defines them: they’re a name for a particular commit and all the commits that are ancestors of it, so each branch is completely defined by the SHA1sum of the commit at the tip. It suggests that branches are quite heavyweight objects.If anything, a branch is a “directed acyclic graph of development” rather than a line.Branches are often described as being a “line of development”, but I think that’s an unfortunate expression since: Branchesīefore I explain the advice about git pull any further it’s worth clarifying what a branch is. Of course, unless you turn off all the safety checks, the effects of a git pull on your working directory are never going to be catastrophic, but you might prefer to do things more slowly so you don’t have to backtrack. The other problem is that by both fetching and merging in one command, your working directory is updated without giving you a chance to examine the changes you’ve just brought into your repository.
#Update your master git pull origin master manual
What seem like obvious bits of syntax for git pull may have rather surprising results, as even a cursory look through the manual page should convince you. Mostly things Just Work, but when they don’t it’s often difficult to work out why. The problem with git pull is that it has all kinds of helpful magic that means you don’t really have to learn about the different types of branch in git. One of the git tips that I find myself frequently passing on to people is:ĭon’t use git pull, use git fetch and then git merge. There is some discussion of this post on the git mailing list, but much of it is tangential to the points I’m trying to make here. This is too long and rambling, but to steal a joke from Mark Twain Blaise Pascal I haven’t had time to make it shorter yet.
0 kommentar(er)
