61

Currently, I used to create a new branch each time I have to add a new feature to my application.

When my feature is finished and functional, I merge it with the master branch.

But later, when I need to update this feature (like an improvement) is it better to create a new branch or do I need to rebase the previous with the master, do the update then merge again?

For example, I have branch called modeling-member in a Ruby on Rails application. Later, I need to add some attributes to the member model (which was created in this branch). What should I do? Rebase this branch with the master, update the model and merge it again or simply create a new branch?

gaetanm
  • 763
  • 1
  • 5
  • 8
  • 2
    If your project gets very large then reusing old branches will be very time consuming for git to switch and/or update. Compared to the few seconds it takes to create a new branch. – Reactgular May 25 '15 at 16:55

3 Answers3

52

Create a new branch, because:

  • A brand new branch is less likely to have merge conflicts when you're done and want to merge it into master. Few things are more error-prone than fixing merge conflicts.

  • The feature may have gone through several changes and updates since its original implementation, making the original branch totally obsolete. The only way to bring it up to date is to merge master into the feature branch...and at that point you're just branching off master in a needlessly complicated way.

  • If only for simplicity's sake, it's usually a good idea to have the same workflow for updates, bug fixes and new features. That applies to branching, code reviews, bug tracker usage, and pretty much everything else. The difference between updating an existing feature, adding a new feature and fixing a bug is often subjective anyway.

Ixrec
  • 27,621
  • 15
  • 80
  • 87
16

Use a new branch.

For naming, you could consider using an internal format that this_work is an extension or change to that_work

For example you could name the second branch

modeling-member--attributes

with the -- signalling that the name name on the left is the original branch

We tackle a somewhat similar problem as we use Jira ticket numbers for branch names. Sometimes there is an additional bit of work for the same ticket. Sometimes a database change could not be rolled back. In those cases we use, for example, original branch SEND-123 and second branch to be SEND-123a

Michael Durrant
  • 13,101
  • 5
  • 34
  • 60
0

If you want to save only commits from a merge on the master and you are using github, you could use "Fork" to every new feature and do a pull request and accept pull request after you get every new feature done.

I don't recommend working on old branches, since you can get conflicts when you merge it to the head of master and of course it's not needed to do it...

Gort the Robot
  • 14,733
  • 4
  • 51
  • 60