This has to make a real merge commit (so it does, merge made by recursive and all that), giving: E <- alice/master This gives (I'll leave the remotes/ out of the names now): E <- master, alice/master Step one, do a fast forward merge to pick up something (let's say Alice's change): $ git merge alice/master Now Carl can incorporate both of these into his (Carl's) repo with an easy two step process. He can use git fetch (along with git remote add and such) to bring them in: E <- remotes/alice/master Suppose Carl has a repo with four commits: A-B-C-D <- masterĪlice makes a copy and adds commit E: A-B-C-D-E <- masterīob makes a copy of Carl's original and adds commit F: A-B-C-D-F <- masterĪlice and Bob both tell Carl about their great new features or bug fixes, and Carl decides he wants both. This kind of thing "occurs naturally" when two different developers clone a project from some shared repository, and both make (different) changes to some branch and then they decide to merge their changes. Sometimes following only the "first parent" of a merge gives a "reasonably accurate" picture of the "main line", as it were, and git has the -first-parent flag to follow only the first parent of each merge.
At the moment, it's clear that commits C7 and its history were just now married in, but if we delete the branchB label: $ git branch -d branchB This is because the labels-the branch names like branchB-are not permanent. You might wonder, then, how you can tell which commits were "originally" on the branch, before a merge brought in "a bunch of previously-unrelated, but now in the family by marriage" commits. Commit C7 is now "on the branch", as are commits C5 and C4 and any previous history that comes before C4. If we follow M backwards, to see which commits are "on the branch", we will-well, git will, so we should too :-)-follow both parents. The label branchA is changed to point to commit M. The new merge commit, M, has two parents, commits C6 and C7. This changes the "commit graph", and now we have this. This makes a "merge commit"-we could call it commit C8, but let's call it M for merge: $ git checkout branchA Now suppose you go back to branchA and git merge branchB. C6 points back to C3 as its parent, which is how we can follow the history of branchA backwards and C7 points to C5, which in turn points to C4, and so on.) ( C3 and C4 already existed when you started. The name branchA points to commit C6, which is the one you made with "new stuff for A", and the name branchB points to commit C7, which is the one you made with "new stuff for B". $ git commit -a -m "new stuff for A" # new commit is on branchAīut what happens when you start merging different branches? After you've made one commit on each of branchA and branchB above, you might have something like this. It's on only one (or, technically, at most one) branch: $ git checkout branchA When doing straightforward, linear development history, it's clear which branch each commit is on. Most likely the issue you are running into here is the real meaning of "on a branch".
0 kommentar(er)
