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 (
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
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
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.