(“remotes” are just nicknames for other repositories, synonymous with a URL or the path of a local directory – you can set up extra remotes yourself with “git remote”, but “git clone” by default sets up “origin” for you.) origin, cognac, fruitfly) followed by “/” and then the name of a branch in that remote respository. The names of tracking branches are made up of the name of a “remote” (e.g. ![]() (b) “Remote-tracking branches”: what you see when you type git branch -r, e.g.: $ git branch -r to use an abbreviated example I have here: $ git branch ![]() (a) “Local branches”: what you see when you type git branch, e.g. I’m going to try to convince you that there are really only two types of branches. The terminology for branches gets pretty confusing, unfortunately, since it has changed over the course of git’s development. This is something I seem to end up doing a lot… :) Types of Branches Git pull # Or something that updates "master" from # "dubious-experiment" branch has the commits you were working # clean, you're definitely on "master" and the # Be careful with this next command: make sure "git status" is M-N-O-P-Q ("master" and "dubious-experiment") Then you separate out your work with the following set of commands (where the diagrams show how the state has changed after them): git branch dubious-experiment If the commit graph looks like this: last version from another repository 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |