CODEWITHSUNDEEP
gitmergepull
GP89
GP89

Reputation: 6740

Why is git merging when I do a pull?

I've started using git fairly recently and have been really happy with it, it's definitely a great tool.

But today I've got it in a really weird state, that I can't seem to get out of, though.

I have two remote branches, master and pqueues. I want to be able to pull those branches into the locals branches of the same name, but when I do git pull it pulls and merges master into whichever branch I have checked out. If I do git pull on local pqueues, it does a merge of itself and master. I really don't understand why.

Also If I do git push origin pqueues on pqueues it says Updates were rejected because the tip of your current branch is behind when I know I'm the only person to commit to that remote branch, and my local branch is a few commits ahead of remote.

How can I find out what's actually going on and get it back to a working order?

Upvotes: 2

Views: 1217

Answers (2)

VonC
VonC

Reputation: 1329722

Note: whatever git pull you are using (and git pull --rebase is a good idea to update your current branch on top of what is being pull), git pull will first do a git fetch.

(See "git fetch/git pull from Git Reference)"

And git fetch will fetch the remote branches: if they don't exist in your local repo, will create them.
That is why you see on your first git pull:

* [new branch] pqueues -> pqueues/pqueues 
* [new branch] master -> pqueues/master

But you will that only for the first git pull. All the other ones will fetch and update the existing remote tracking.
See "Git: What is a tracking branch?" and "What is the difference between a remote tracking branch, and a branch on a remote?", to better understand what git fetch updates.

Upvotes: 0

karmakaze
karmakaze

Reputation: 36164

There are two cases where a pull results in a merge. 1. You've made commit(s) on your local branch e.g. 'master' and someone else pushed commit(s) to 'origin/master' since when your local 'master' was last in sync with 'origin/master' 2. You have made no commits to 'master' but someone else has 'rewritten history' by rewinding 'origin/master' to an earlier commit then adding commit(s) to it.

For case (1) if you can perform a "git pull --rebase" which will replay your changes on the new HEAD of origin/master'

Case (2) can be avoided by never rewriting history: if a commit has to be undone, use git revert which will add a new commit that undoes the previous one and the commit and the revert all show in git and can be fast-forwarded by all downstream repos.

Upvotes: 1

Related Questions