3

I'm merging changes from my fork into our team's master repo on GitLab.

Weird thing is, along with my commits, the merge is saying other files changed, files I haven't been working on. AND the changes it shows are already present in the upstream master I'm merging into. What?

Here's my workflow: (Step 9 is where I encounter trouble.)

  1. from local master rebase from upstream master
  2. from local master create feature branch
  3. checkout feature branch.
  4. do a ton of work on my feature branch, frequently committing and pushing to my fork's feature branch.
  5. Create merge request and merge fork's feature branch into upstream master.
  6. Checkout local master and rebase from upstream master
  7. checkout local feature branch and rebase (if nec.) from local master (to bring in any changes my teammates might have done in other files).
  8. do more work locally, frequently committing and pushing to my fork's feature branch.
  9. Create a merge request from fork feature branch into upstream master, which shows changes to other files, changes already present in the upstream master.

Going line by line, comparing the 'changes' with what is in the upstream master for these other files, I can see that those changes are already there in the upstream master.

Why in the world does git do this? It's really unnerving like I'm doing something wrong, and I'm nervous to just merge these changes by default every time I encounter this weirdness bc these other files are my teammates work - I'm not 100% sure my fork's feature truly has the latest and greatest code.

What am I doing wrong?

Thank you!

208_man
  • 1,440
  • 3
  • 28
  • 59

1 Answers1

4

For what I see, it's the rebasing of master in your fork branch (aka step 7) who causes the mess.
By rebasing, you kind of lay down all the merges and it change commit hashs, creating sort of new commits.

You can either :

  • git merge instead of rebase in step 7

  • git rebase --preserve-merges

To fully understand the implications, I suggest to read the very well documented answer to that question : What exactly does git's "rebase --preserve-merges" do (and why?)

Cannabear
  • 76
  • 1
  • 8