I would like to know if it's better to delete your branch after merging to master or if we should continue to work on the same separate branch during all the project.
i.e If we are 3 members in the group, each of us create his own branch and works on it during the duration of the project. We all commit in the master branch and pull before we start working on something else. In that way, we know who's working on which branch and we don't get confuse.
Thanks.
So there are tons of literature about how to manage your branches but really I think it comes down to how you want to manage things within your own project. That being said, here is a link for branch workflow from Atlassian that could give a decent opinion:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
Now, all that long article being said, if it makes sense for you all to commit straight to master, I don't think there is anything wrong with that. I personally commit to master for a couple small projects I work on but generally, this is the flow I follow:
- Create the master branch for the project
- Decide on a feature you want to work on, we'll call it
Widget X. - Create a feature branch for that, call it
feature-widget-x. - All the developers working on this feature should make their own branches based on what they are working on. For example, if I was working on error handling, I would branch off of
feature-widget-xand make a branch calledmichael-error-handling. - Merge everything into the feature branch and branch off from there as needed to complete the feature.
- When the feature is done, merge the feature branch back into the master branch.
- Tag and archive the feature branch so you can roll back if needed at any point.
- Clean up local developer branches.
- Create a new feature branch from master for
Widget Y. - Start the whole process again.
I want to note that this is strictly how I do things and has been successful for me in companies where it has been implemented. It may or may not be the best solution for your group of three members though but that is for you to decide. If you do go with this plan, it has the benefit of being able to roll back to a feature as needed and the only branches that persist are the feature branches and the master branch. Much easier than looking through commit logs on a single branch to figure out when you should roll back to if a commit breaks something.
Hopefully this helps. Here are a couple more links below for extra reading:
https://git-scm.com/docs/git-archive
The correct answer to your question is: it depends what you want to do. There is no problem with continue working on the branch that you merged with master. You can also simply delete it if you don't need it ! However, in the setting you describe, I totally agree with the fact that if you work on different parts of the project, then it may be safe to create different branches and keep the master branch as clean and updated as possible for the group.
来源：https://stackoverflow.com/questions/55615750/should-we-remove-a-remote-git-branch-after-merging-to-master