22

I recently got the task to add a certain feature to a project I'm working on. As this feature depends on old code that was cruel to use, I decided to split the task in 2 steps:

  • refactor old code to be more usable
  • create feature using refactored code

I created a branch feat/foo, and after the refactoring was done, I merged it into our master so we could use the changes directly. Now I'm left with the following commit history:

A ---> B ---> C --> E ---> F <master  B: created branch feat/foo
       |            ^                 D: refactoring finished
       D -----------|                 C: changes in master in between
       ^                              E: merge commit
     feat/foo                         F: master is now here

feat/foo still points to D, and my master advanced to be at commit F. What would I do now to continue my work on this task in branch feat/foo? I see two possibilities:

  • either delete feat/foo and checkout -b it again, so I have a new branch that has the same name as my old branch,
  • or somehow "reuse" feat/foo, which I don't know how to do

The first solution somehow feels not quite right to me, it seems "wrong" to delete the branch just to create it again. But I don't know how I could reuse it.

What should I do? Delete and recreate the branch, or if the right answer would be reusing it, how?

Alex
  • 1,175
  • 1
  • 8
  • 25

3 Answers3

17

In many workflows, once a feature branch has been merged back into master it is deleted. GitHub is probably the prime example of this. If you follow this school of thought, you would delete feat/foo and create a new feature branch for your next sprint.

If you really want to keep using the branch, then you will either have to rebase feat/foo on master or merge master into feat/foo. I don't see any advantage to rebasing, which could be messy, so let's consider merging. You merged feat/foo into master at commit E. Therefore master already has all the features from feat/foo, but the reverse is not true, i.e. feat/foo is likely missing several features which have been introduced into master since commit D. To do the merge you would use this command:

git checkout feat/foo
git merge master

You may have to resolve merge conflicts arising from new features in master which are not yet in the feat/foo branch.

Now the feat/foo branch is up to date with master, and you can keep using it if you wish. Personally, I would just leave feat/foo where it is and create an entirely new feature branch. You can keep it around for a few sprints until you are sure that deleting it safe.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • 1
    Thanks, I really did not think of merging master back into feat/foo, but now it seems so obvious. Though I consider to do what you say and leave feat/foo alone and start working on a new branch, as this would probably be cleaner. – Alex Aug 14 '15 at 10:57
  • One question, can we not reset the feat/foo to the current master and start from there ? As pull request is merged the feat/foo branch really serve no major purpose. – Pratham Oct 16 '19 at 08:35
  • 1
    Branches are cheap! – Jersey Dude Dec 22 '21 at 16:30
  • If you are rebasing your branch before merging it into main (which is standard practice where I work), I don't see any harm in reusing the same branch, as you know that main and working branch have the same history. – rocksNwaves Apr 25 '22 at 20:57
  • Maybe I'm missing something but presumably your merge of master back into your branch would occur at the same point you'd have branched a feature (before making your new commits), so don't see why it'd be any more prone to conflicts than creating a new feature branch at that point. – Drazen Bjelovuk Jul 04 '23 at 20:15
9

Since you need to continue working on branch feat/foo, the first thing to do is to checkout it:

git checkout feat/foo

Because you didn't complete the work on the new feature you keep working and committing on the branch until you finish the work and are ready to merge it back into master.

From time to time it's good to pull into the branch the latest changes from the master branch. You do that by running:

git merge master

while you are on the feat/foo branch.

It doesn't make much sense to remove the branch just to re-create it again. git checkout feat/foo followed by git merge master produces the same result.

axiac
  • 68,258
  • 9
  • 99
  • 134
  • when I do `git merge master` I get "merge: master - not something we can merge".. any advice? – Black Sep 20 '21 at 01:56
  • 1
    This message is displayed when the repo does not contain a branch named `master`. Maybe your main branch is named `main`. Or maybe you never checked out the `master` branch (and it exists only on the `origin` repo, not locally). In this case run `git branch --track master origin/master` first, to create the local `master` branch. – axiac Sep 20 '21 at 06:36
2

The question is a little bit of an oversimplification. In your case you have "1 story" with "2 tasks": refactor and feature. You already merged the refactor task and moved onto the feature task. That means we didn't consider the possibility of merge conflicts. You can simply merge/rebase to reuse the branch which is the easiest possible scenario.

Why would you even merge task 1 before moving onto task 2? Why not just do all the tasks to complete the story before you merge? It appears you already have an intuition that short, focused work is easier to manage. For most enterprise level teams, longer lived branches are worse than short lived.

In reality, when choosing to "delete or reuse" branches you should consider the possibility of complex merge conflicts. Long lived branches, poor team communication, refactoring, big teams, poorly coordinated stories...all these increase the possibility of buggy, nightmare level merge conflict resolution.

When choosing to delete or reuse a branch I always go with delete. My recommendation comes with a holistic view that other higher order problems are also being solved (again think big teams, poor communication, refactoring etc). Once a branch is merged there is no significant value add in increasing the lifetime of said branch. However, there can be a significant cost that comes with long lived branches. See also GitFlow.

P.Brian.Mackey
  • 43,228
  • 68
  • 238
  • 348