Is it good practice to switch back to an old branch to develop a new feature or to create a new branch?

Question

I have an old branch (old-branch) which I last used approximately four months ago that I used to develop a feature for a specific project. It was never merged back into master because the feature never played out according to plan and was abandoned.

Since then, the project has come a very long way and the codebase now looks very different.

Note: I have only been using git / version control for a few months now so am still learning about it. Also, I am the only person using this repository and nobody else will ever use it, so all changes are - and will continue to be - my own.

I now need to develop a feature for this project, and I checked out old-branch, but the problem was that it (naturally) reverted the original codebase (with new features) back to how it was all those months ago.

Also, when I switched back to master, I noticed hundreds of untracked files (from the old branch).

My question is this: should I create a new branch (development/feature) or use old-branch? If I should use old-branch, how should I handle the vast differences in the codebase and subsequent untracked files when I switch back to master?

Is it good practice to create and use new feature-specific branches as and when I need them?

I would think that as a project evolves, and as new features arise, it would make more sense to branch the project off (in order to create a working copy of master as it is at that moment in time) so that the changes can be made, and to then merge new-branch back into master once the change is complete. However, being a relative newcomer to git / version control, perhaps this is not the correct way to do things. I don't know.

I was under the impression that you should have a dedicated development/features branch which you use to further develop new features, and then which you merge back into master once they are complete, but perhaps I am wrong.

Answer 1

If old-feature has nothing to do with new-feature then create a new branch.

Even if the new feature needs some code from the old feature, I would still create a new branch off the current code, and selectively checkout out files from old-branch into your new branch:

$ git checkout -b new-feature master
$ git checkout old-feature -- path/to/file/you/want

Git, from the command line or using a GUI, allows you to revert changes to individual lines of a file, so you can get extremely granular in what you bring over to your new branch.

Answer 2

A four month old branch will be a nightmare to merge. If the feature is abandoned, delete the branch ( unless your boss is a hoarder and wants to keep it). Do not touch that old branch.

Create a new branch, do your work, merge it or don’t merge it, then delete the branch.