8/2/2023 0 Comments Gitx devIf 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 |