5

I have a github repository which follows the following branching strategy :-

  1. Has a long living master branch
  2. feature branches are cut off from master whenever a new feature has to be worked upon. Eg. feature/A, feature/B
  3. Story, defect or task branches are cut off from individual feature branches which they are part of.
  4. Multiple features can be in development parallely.
  5. Story, defect, task branches are merged to respective feature branches as and when the work for these are complete.
  6. After completion of each feature, the work done on that feature has to be merged to master branch

Now, assuming feature/A and feature/B are being worked upon simultaneously and the team working on feature/A finishes the feature first and raises a simple Pull Request to merge changes to master branch.

After the work on feature/B is finished, we would like to rebase it on top of master to get the latest changes from master (which contains feature/A work) before raising a pull request to merge changes from feature/B branch to master.

What is the proper way to do rebase in this case?

Here are 2 approaches I have tried out -

Approach 1 :-

  1. Create a new brach from feature/B branch on local working copy, eg. - task/rebase
  2. Run git rebase master
  3. Resolve conflicts and continue rebase iteratively until it completes.
  4. Push task/rebase branch to remote repository.
  5. Raise a PR from task/rebase to master.

Questions on this approach 1 -

  1. Shall the PR be raised from task/rebase to feature/B? In this case, it anyway does not allow to merge the changes.
  2. If following this approach, how to get the changes in feature/B branch after step 5?

Approach 2 :-

  1. Checkout feature/B branch on local working copy.
  2. Run git rebase master
  3. Resolve conflicts and continue rebase iteratively until it completes.
  4. Pull from remote feature/B branch as the local copy has diverged and does not allow a push before a pull. Resolve some conflicts again.
  5. Push changes to remote repository and raise PR from feature/B branch to master branch.

Questions on this approach 2 -

  1. Is it the proper way to do rebase? I see repeated commits when PR in step 5 is raised.
Improve this question

1 Answer 1

Reset to default
2

Git allows you to rewrite history (rebase) and force that onto the remote (assuming the required permissions) with git push -f.

The other way to combine divergent history is to merge. For example, you could first merge master into feature/B to resolve conflicts instead of doing a rebase. Or you could merge directly into master.

If you have multiple people working on feature/B, rebasing is generally not the best approach, unless all work has stopped and everyone is ready to close the branch. Otherwise, it can create race conditions where someone pushes changes after you start the rebase, but before you force-push, losing their work.

If you insist on rebasing, Approach 1 will give you no avantage. Approach 2 is almost the correct way to do it. The only problem is step 4 is undoing all the benefit of the rebase. Instead of merging feature/B with origin/feature/B, you need to do git push --force to update the remote with the new commit history.

As Approach 2, step 4 implies, merging may still be the best approach in your situation.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

@TTT. I hadn't even noticed step 4 somehow. I'll update my answer to be more clear.
@TTT. I've updated
@TTT. I think OP is trying to rebase instead of merging because they don't know how git works, so I tried working that into the answer. The merge likely comes from the fact that feature/A was rebased first.
@TTT. I have no problem whatsoever with you dictating the answer as long as it's correct :)
Thank you very much both of you. I understand the concept and scenario better now.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.