![]() And that's awful, and everyone will give you evil eyes and shun you. ![]() If you rebase commits that are already public, developers will have their history re-written for them when they pull. The commits are entirely rewritten, with a new SHA and everything. This is different from the existing answers as I'm not using -allow-unrelated-histories on the pull, but on the merge. Note that E & F became E' & F' after rebasing. I ran into a similar problem where I brought in a branch from a second remote and wanted to merge with a branch from the first remote. One warning - never rebase any commits that have already been pushed. Note how everything is in a single line, you're ready to push, and the history doesn't look like a friendship bracelet. This will replay your changes on master (E, F) on top of origin/master (D) without a yucky merge commit. Or a shortcut, git pull -r, but personally I prefer to see the changes before I rebase. ![]() Since your local repository does not have D, a git merge origin/master will simply yield:īecause hey, as far as your local repository is concerned, master already has everything in origin/master. So you're at this state, where D is only on the remote and not present locally: origin/master Without a git fetch, your local repository is unaware of any potential changes on the remote repository and origin/master will not have moved. Running git merge origin/master without the git fetch is pointless. Git pull is simply a shortcut for the above steps. So now you've integrated your changes on master (E, F) with the new commits on origin/master (D). Now you run git merge, giving you this: A-B-C-E-F Now you can see D, and origin/master is updated to match the remote repository that it's tracking. Note that you will not see D in your local repository until you run git fetch. Git fetch and git merge origin/master will fetch & integrate remote changes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |