Reputation: 1290
I finished working on a local branch1
and merged it to master
.
Now I would like to work on another feature for my application and so I will create a second local branch2
, finish to add the feature and merge to master also branch2
. This can go on for as long as I need to implement my application with features and until my application is completed.
Suppose now that after all these implementations I would like to make some improvement or change on the topic that was the job of branch1
, say the static pages about
, help
and contact
.
Is it possible to checkout to and reuse branch1
for these changes or that branch cannot be used anymore and should rather be deleated?
After a while there might be a considerable pileup of old topic branches that I initially may have wanted to keep for these purposes. However these old branches are all outdated, no more a complete reproduction of the master branch as they were when created: is this a prerequisite in order to merge
with success?
Upvotes: 0
Views: 51
Reputation: 142074
You should take a look on gitflow
.
Its a very known workflow for doing such kind of development as you are asking
The full workflow will look like this. In your case you refer to the feature branches (purple ones).
The relevant article is here:
http://nvie.com/posts/a-successful-git-branching-model/
As you can see you keep working on new features all the time and once you done with them you simply merge them back to dev
(in your case can be master)
Upvotes: 1
Reputation: 10005
The branching/merging strategy is yours to decide but you seem to describe a feature-based workflow.
In that case, after you have merged your feature branch branch1
to master, the content/history of this feature is contained in the master
branch thanks to the merge. branch1
becomes useless and even obsolete with time so you can safely remove it so that old feature branches don't accumulate in your repository.
If you then look at the improvements you want to add to the functionality introduced by branch1
, you can see those improvements as a new feature and therefore create a new feature branch from master
to perform those improvements.
How you should organize your workflow is rather subjective and the best strategy often depends on how the project is organized in terms on contributors and how you deploy your changes.
Upvotes: 2
Reputation: 5524
You can use these old branches, but ... you should merge new changes from master before (So you can avoid big merging problems in future). When you need to reincarnate old branch do:
git checkout very-old-branch
git pull ./ master
# do some changes into very-old-branch
git add .
git commit -m 'changes in the very old branch'
# need to merge very old branch with new changes into master again
git checkout master
git pull ./ very-old-branch
git push origin master
But it would be better not to be necromancer and to just create new branch and make changes in it:)
Upvotes: 1