git pull –rebase upstream & git push origin rejects non-fast-forward?

I’ve implemented classic OSS maintainer/contributor git workflow for a company project on github, however one edge case produces some weird results that I’m not sure how to get around.

Lets say there is a typical project that I forked and added upstream remote to keep it up to date.

  • In git, how does one roll back specific commits in a branch but not roll them back in the parent branch even after merging?
  • remove all binary files recursively from git repo and commit history
  • In gitolite, how to reject pushes containing incorrect author info
  • Remove remote branch and push local
  • Having two different GIT repo's in one directory for the same project
  • Can I mark a GIT remote as read only?
  • git clone<project>.git
    git remote add upstream<company>/<project>.git

    For the purposes of this example this fork is behind by a few commits.

    git reset --hard HEAD~5 && git push --force

    I work on this fork and push some commits, before pushing my last commit and creating a pull request I update my fork’s clone to make sure there are no conflicts.

    touch foo && git add foo && git commit -m foo && git push
    touch bar && git add bar && git commit -m bar
    git pull --rebase upstream master
     * branch            master     -> FETCH_HEAD
    First, rewinding head to replay your work on top of it...
    Applying: foo
    Applying: bar

    Now, when I try to push to my fork I get rejected.

    git push
     ! [rejected]        master -> master (non-fast-forward)
    error: failed to push some refs to '<project>.git'
    To prevent you from losing history, non-fast-forward updates were rejected
    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
    'Note about fast-forwards' section of 'git push --help' for details.

    What should I do next? All I want is for the pull request to contain foo and bar commits, however…

    When I pull, pull request contains duplicate foo commits as well as extra merge one.

    git pull
    Merge made by the 'recursive' strategy.
    git push

    On github pull request looks like this.

    Showing 4 unique commits by 1 author.
    kozhevnikov  foo    4 minutes ago
    kozhevnikov  foo    4 minutes ago
    kozhevnikov  bar    2 minutes ago
    kozhevnikov  Merge branch 'master' of<project>    just now

    When I git pull --rebase instead of pull, at best it’ll include other people’s commits into my pull request (those from reset), and at worst it gives me merge conflicts.

    When I git push --force without any pull or --rebase it works perfectly, however I’m very uneasy in saying to everyone use the force or making it part of standard workflow as I can imagine few people or a small subteam collaborating on a single fork and stepping on each other’s toes with forced push.

    Any ideas? What am I missing?

  • Run `git commit` from another directory
  • How to tell git to use the correct identity (name and email) for a given project?
  • Can't locate git-cvsimport?
  • Multiple simultaneous version control systems?
  • In Git, Is it possible to make a tracked file static, as in any changes to the file are ignored?
  • Git and Dos - how to exit a command
  • One Solution collect form web for “git pull –rebase upstream & git push origin rejects non-fast-forward?”

    When you

    git pull --rebase upstream master

    you are rewriting your own history, since you are rebasing your master branch on the updated upstream repository. When you push your rebased repo to your fork git complains. You need to push with –force

    git push --force origin master
    Git Baby is a git and github fan, let's start git clone.