CODEWITHSUNDEEP
gitgit-mergegit-workflow
Caper
Caper

Reputation: 186

How to develop a brach when it is merged with other developing branches

Imagine two branches: 124 (mine) and 158, both are under development.

  1. I merge commitA of 158 into 124.

  2. In 158-commitA files are renamed, content changed after rename, now it is 158-commitB.

  3. 158 raised a PR, which was squash-merged to master. After that 158's remote branch was closed.

  4. I wasn't aware of #2 and #3, so did not keep 124 in sync.

  5. I started to open a PR for 124, and found that the files I merged from 158-commitA are now appearing as new files in the PR/merge of 124.

  6. I checked 158's PR, found the changes, modified these on 124 too.

#6 seems like unnecessary work that git should be able to handle automatically. Is there any way I can avoid this manual work?

Upvotes: 0

Views: 117

Answers (1)

IMSoP
IMSoP

Reputation: 97948

A very useful rule to enforce in any git workflow is that you should never rewrite history which you have already shared.

In your example, the early work on branch 158 was shared with branch 124. However, you then used the "squash" merge option, which rewrites history, creating a single commit from multiple. That means git has no way to know that the changes in 124 are related to the new version of 158, so when you merge 124 to master, it's going to try to merge those all over again.

If you had instead performed a straight-forward merge (both when merging to branch 124 and when eventually merging to master), creating a merge commit with the full history of 158 preserved, the PR to merge 124 would simply have skipped over the commits which were shared between the branches.

However, it sounds like you also have a more organisational problem: if a developer picks up changes from an in-progress branch, it is essential that they communicate with the author of that branch. What if a problem was found with 158, and a PR for 124 was opened before 158 was merged? What if the author of 158 had abandoned their initial branch and started again?

If the two developers are communicating properly, it is possible for the author of 158 to safely rewrite the history of their branch (with a rebase, a squash merge, etc) - the author of 124 just needs to know about it, and rewrite their history to match, using git rebase. It's usually easier to avoid that where possible though.

Upvotes: 1

Related Questions