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:
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:
checkout -b
it again, so I have a new branch that has the same name as my old branch,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?
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.
They're unnecessary. In most cases, branches, especially branches that were related to a pull request that has since been accepted, serve no purpose. They're clutter. They don't add any significant technical overhead, but they make it more difficult for humans to work with lists of branches in the repository.
When you're done with a branch and it has been merged into master, delete it. A new branch can be made off of the most recent commit on the master branch. Also, while it is ok to hang onto branches after you've merged them into the master they will begin to pile up.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With