我只是在学习 Git。我脑子里的粥。我不太明白如何以团队的形式使用主题/短期分支，同时又不让项目和存储库变得混乱。
你能告诉我这张图是否正确吗？服务器上有 2 个分支：master、develop。所有与开发一起工作。假设一些员工需要创建一个菜单。
- 创建一个新分支：
git checkout -b feature-menu - 将其推送到服务器：
git push -u origin feature-menu - 工作，做出承诺，拉动他人并推动他们的改变
- 别人
git checkout -b feature-menu origin/feature-menu做某事，也统治某事 - 工作完成后，员工合并分支：
git checkout develop; git merge feature-menu;解决冲突 - 建立
git pull和git push发展分支机构 - 在本地和远程删除一个分支
git branch -D feature-menu; git push origin :feature-menu; - 准备好
添加。问题：employee1合并删除了不需要的分支（第7点）后，同样在这个分支工作的employee2拉取后本地还会有吗？不可能做到在分支工作并从服务器中删除后，它不再出现在任何地方的员工面前。还是不需要？
添加。问题2：如果员工单独在一个分支机构工作。是习惯推送到服务器还是本地合并推送已经开发了？
该图看起来合理。唯一的问题是没有必要立即将新创建的分支推送到服务器，您可以稍后再做。这样的帖子还是删了吧
git branch -d feature-menu。-D在任何情况下都会删除该分支，但-d前提是该分支被冻结。是的，本地分支不会在任何地方消失。但他可以做到
git pull --prune——然后它就会被删除。如果员工不拉 --prune，那么她将继续与他同住。但这是他自己的事。
你不能推。这是他自己的事。但如果他突然生病或他的电脑决定去维修，那可能会非常不愉快。因此，如果这些是他们自己的小实验，那么他们通常不会推。如果这是解决特定问题的代码（在 jira 或类似的东西中），那么最好推送。
我将对 KoVadim 的出色回答做一些补充。
从技术上讲，这是可能的，主要是就这种工作格式达成一致，以免出现意外。尽管如此，如果两者同时提交给分支，那么一个提交，
git push另一个git pull --rebase解决冲突（如果有的话）。git pull更糟的是，因为 将出现合并提交，在这种情况下它不携带任何信息，而只会阻塞历史记录。最好先更新 develop 分支，然后再合并一些东西进去，否则有两次或更多次解决冲突的风险。
通常，分支合并是一项负责任的任务。通常，只有负责代码审查和这些非常稳定的分支中代码状态的团队负责人才有权合并到稳定的分支中。如果您有测试人员，请同意他们何时测试更改 - 在合并之前或之后。如果你使用 GitHub、GitLab、Bitbucket，考虑使用 pull/merge requests（拉取请求、合并请求）。这对您的项目和团队来说不一定是好的和有用的，但值得考虑。
关于使用分支，我建议阅读这个问题的答案：How to send a release to git? . 请务必阅读所有内容，而不仅仅是已接受的内容。有不同的观点，这将有助于形成更完整的画面。