3

I am confused by a git issue we're encountering. We have 10 developers on the project, each with their own branch. Developer branches are merged into two "feature" branches named develop_frontend and develop_backend using pull requests in Bitbucket. The two feature branches are then merged into the develop branch, which is used to deploy the project for QA.

Our problem is that some commits are ending up in the git history twice (with different commit #s).

Developers always pull --rebase from the upstream branch prior to pushing and submitting a pull request. The same workflow is repeated for the feature branches. Where do the dupes come from?

  1. git checkout develop
  2. git pull # pull updates; no local changes made to this branch
  3. git checkout develop_backend
  4. git pull # pull updates; no local changes made to this branch
  5. git pull --rebase -s recursive -X ours origin develop # rebase from upstream branch
  6. git push
  7. # submit pull request
user717847
  • 695
  • 1
  • 6
  • 16
  • How do you know it's the same commit if there are different hashes (which I assume you mean by different commit #s)? Can you show a commit history? – engineerC May 10 '13 at 18:13
  • Could [this scenario](http://stackoverflow.com/a/2597107/877115) apply? – Christopher May 11 '13 at 04:52
  • `git pull --rebase` will always rewrite your history. Rewriting history = creating new, similar commits. If you then merge those, they will appear duplicated. – knittl Oct 19 '22 at 06:52

0 Answers0