Berat Özdemir <Berat_Oezdemir@xxxxxxxxxxxxx> writes: > - cloned the remote repository. > - checked f1 out > - checked develop out OK, so at this point, you have "f1", which is a copy of the origin's "f1", and you have "develop", which is a copy of the origin's "develop". And you have "develop" checked out in your working tree. > - run git merge f1. Merge was successful. OK. "develop" has one extra commit (i.e. merge of "f1" into it) relative to the origin's. You made sure automated merge goes well. > - Did not pushed OK. > - run git reset --hard origin/develop -> to undo the f1 merge into develop OK. Now your "develop" is the same as origin's again. > - run git pull origin f1 This is "Please fetch f1 from origin, and merge it into the branch that is currently checked out in my working tree. It may conflict, or it may not. If merged cleanly, create a new commit and advance the branch that is currently checked out". > What did you expect to happen? (Expected behavior) > I expected that "git pull origin f1" will just update the f1 > branch (fetching and merging with origin/f1). In my case I > expected nothing to happen since neither local f1 nor origin/f1 > did changed while testing. Just develop changed locally, but it > was resetted. The expectation is flawed. What is the closest to what you describe above is "git fetch" (which would update origin/f1 together with other remote-tracking branches under origin/). If you wanted to update your "f1", one procedure you can use is $ git checkout f1 $ git pull origin f1 "git pull" (and most of the commands that create a new commit based on what you did, e.g. "git rebase", "git cherry-pick", "git commit", "git merge") works on the branch that is currently checked out. If you want to do something to "f1", you would check out that branch first. > What happened instead? (Actual behavior) > "git pull origin f1" created a new commit, which was the > previously resetted merge into the develop branch. This is expected (see the explanation for "run git pull origin f1" above).
