CODEWITHSUNDEEP
gitgithubversion-controlgit-pullpull-request
GoT
GoT

Reputation: 550

Pushing a commit to a branch of a forked repository

I am getting a strange error when updating a forked repository. I already created a dev-branch in the forked repo(for my development work).

  1. I have cloned a forked repo

     git clone https://github.com/twbs/bootstrap

  2. Check the current branch

          git branch

      *master
      dev-branch

  3. Change to dev-branch

    git checkout dev-branch

  4. make changes and commited them to dev-branch

     git commit

  5. Add remote url 

     git remote add parent [email protected]:twbs/bootstrap

  6. when i do a git push now, i am getting error hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart

  7. So, I did 

        git fetch parent
    git merge parent/master
   A new commit screen is opened with commit message "Merge remote-tracking branch 'bootstrap/master' into dev-branch"

  8. Still i get the same error, when I do git push

  9. Now, I did 

        git pull
    A new commit screen is opened with commit message "Merge branch 'dev-branch' of https://github.com/username/bootsrap into dev-branch
    1. Now, git push worked.

I don't know what has happened. Did i make a mistake somewhere ? Can someone point out to me the right steps to update and push from a different branch of forked repository ?

Upvotes: 1

Views: 436

Answers (1)

Andrew C
Andrew C

Reputation: 14903

What version of git are you using? Older versions of Git used to default to "attempt to push all local branches to the remote", which is what it appears yours tried to do.

Newer versions of Git default to only attempting to push the currently checked out branch to a branch of the same name upstream (which I also dislike). I personally recommend git config --global push.default tracking (or upstream in newer versions), which attempts to push your current branch to its upstream.

In your case, you had two branches, and it tried to push them both. Both were rejected because both were behind.

So no mistake on your part really, although if you prefer a linear history you might want to consider rebase instead of merge.

Upvotes: 1

Related Questions