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.
git branch --merged
to find branches that can be safely deleted.)