113

I'm working on a project and I submitted my first pull request and while I'm waiting I want to continue on working on my project building up from what I worked on the merge that's still pending on. Right now I have :

*master
user_story_1

user_story_1 has an open pull request.

Now I'm trying to create a new branch user_story_2 where I can continue the work I left of at user_story_1. How can I do this in Git without getting into any conflict or affecting my pending merge?

alextercete
  • 4,871
  • 3
  • 22
  • 36
Miguel Angel Quintana
  • 1,371
  • 2
  • 9
  • 12

3 Answers3

110

I'm assuming you want to start the new user_story_2 branch on top of the work you've done in user_story_1. Here's the workflow I use in this sort of scenario:

  1. Open Pull Request for user_story_1:

      * (user_story_1)
  *
 /
* (master)
*
*

  2. Create new branch user_story_2 based on user_story_1:

    $ git checkout -b user_story_2 user_story_1
      * (user_story_1, user_story_2)
  *
 /
* (master)
*
*

  3. Work on the new branch:

      * (user_story_2)
  *      
  * (user_story_1)
  *
 /
* (master)
*
*

  4. Pull Request gets merged:

      * (user_story_2)
  *      
* | (master)
|\|
| * (user_story_1)
| *
|/
*
*
*

  5. Delete old branch:

      * (user_story_2)
  *      
* | (master)
|\|
| *
| *
|/
*
*
*

  6. Rebase new branch onto master:

      * (user_story_2)
  *      
 /
* (master)
|\
| *
| *
|/
*
*
*
alextercete
  • 4,871
  • 3
  • 22
  • 36
  • 12
    What happens if the first branch is rejected? – Narayon Dec 21 '16 at 10:46
  • 4
    I'd usually rebase `user_story_2` onto `master`: `git rebase --onto master user_story_1 user_story_2` -- might result in conflicts if the two branches aren't completely independent. – alextercete Dec 22 '16 at 16:36
  • I will give this a try – anquegi Jul 26 '18 at 15:01
  • 1
    For step 6, using interactive rebasing makes things easier. Try `git rebase -i master`, and it should show you a list of commits on `user_story_2` including the earlier commits from `user_story_1`. Remove the `pick` lines for commits from `user_story_1`, and complete the rebase. – Athyuttam Eleti Feb 25 '19 at 18:00
  • What if we need to update, add some commit in `user_story_1`? I guess after that we checkout to `user_story_2` and rebase with `user_story_1` ? – truongnm Jun 19 '19 at 09:32
  • That's right (assuming `user_story_1` hasn't been merged to `master` yet). – alextercete Jun 25 '19 at 08:07
  • What if I wanted to do the reverse i.e. user_story_1 would depend on user_story_2? Let me explain: I forked a project and created a PR from my develop branch to theirs. They requested a few changes and I made it, but then wanted more changes outside the scope of the PR that I made, specifically to refactor some of their core classes so that my PR fits better in the project. So now I have to make a new PR2 which creates a few generic classes and then make a new commit to my PR1 to incorporate those new generic classes. How would I go about doing these? – Saifur Rahman Mohsin Oct 28 '19 at 19:55
  • You could rebase the PR1 branch onto their `master` once PR2 is merged. Now, this is where it gets a bit tricky: rebasing is essentially simulating a workflow where the next piece of work is only started once the previous one is finished. For this to work well, ideally your commits would apply on top of the new base as if you were doing the work from scratch. Because PR2 introduces new classes, your original commits would have to be adjusted to use them (through interactive rebasing). This can be more work than it's worth, so adding another commit after the rebase might be a valid compromise. – alextercete Oct 30 '19 at 08:21
  • @alextercete: "(assuming `user_story_1` hasn't been merged to `master` yet)". What if it has? I mean, `user_story_1` had some commits added after we forked `user_story_2`. Then `user_story_1` was merged to master. Now how to handle `user_story_2`? – shaneb May 28 '20 at 13:42
  • 1
    @shaneb Because `user_story_1` has been merged (and probably deleted), you'll need to rebase `user_story_2` onto `master`. It's the same principle: `master` now contains all commits that were in `user_story_1` (plus the merge commit), so it's effectively the same as if you had rebased onto `user_story_1` after yet another commit was added to it. Branches in Git are only a reference (think pointer) to a commit, so when you rebase onto a branch, you're only reapplying commits onto a new base commit (the one which the base branch references). – alextercete Jun 07 '20 at 16:39
  • Is it necessary to delete `user_story_1`? Or can be there with its merge point, and you still rebase `user_story_2` into `master`? – BCJuan Feb 11 '21 at 15:49
  • if they ask some changes on the PR user_story_1, what's the next thing to do. – Jovylle Jul 28 '22 at 17:31
  • @Jovylle Assuming that you're the only one working on `user_story_2`, I'd rebase it onto the latest `user_story_1` commits. However, if `user_story_2` already has a PR open for it, then I'd be more careful. This is because you shouldn't rebase "public" commits. The best thing to do in this scenario is to wait for `user_story_1` to be merged to `master`, then merge `master` into `user_story_2`. Although this is fairly complicated, it isn't a scenario which you should face very often (if you do, you probably need to review your team practices). – alextercete Aug 03 '22 at 20:51
32

My preferred workflow for this:

  1. On branch master, git checkout -b user_story_1.
  2. Make changes to user_story_1.
  3. Open PR for user_story_1.
  4. On branch user_story_1, git checkout -b user_story_2.
  5. Make changes to user_story_2.
  6. Once user_story_1 gets merged into master, switch to user_story_2 and do git rebase -i master.
  7. This should show you a list of commits on user_story_2 that you want to include in the rebase. Delete the top few commits that came from user_story_1.
  8. The rebase should complete cleanly unless master was updated with other changes. Now you have user_story_2 rebased on master and only having its commits.
Athyuttam Eleti
  • 589
  • 5
  • 9
7

Create a new branch from master for each of your stories/features.

Before merging each branch back, either merge master into that branch or rebase your branch onto master. The latter has my preference, but in the end the outcome is the same.

You are going to get conflicts, there is no way around that. However, you want to solve conflicts in your branch; not in master. This way, you can test your branch after resolving the conflicts before merging it into master.

Stephan Bijzitter
  • 4,425
  • 5
  • 24
  • 44
  • 2
    as long as you create a new branch from your old branch, and rebase **after** you've synced up master (see accepted answer), there should be no conflicts. – Michael Kang Jul 04 '18 at 19:27
  • In the accepted answer, the second branch (assuming it has changes - otherwise, why make it?) it could definitely have conflicts after the first branch has been merged into master. – Stephan Bijzitter Jul 05 '18 at 20:00
  • It could, but if you’re the only one working on it, it shouldn’t – Michael Kang Jul 05 '18 at 20:01