在过去的几个月里，我一直在学习git，因为我一直在使用它;我浏览了Git Pro的书，但没有时间去理解复杂性。
我读了一篇关于拥有他们所谓的“浮动分支”的文章。其中包含生产服务器上所需的配置更改。所以我的工作流程是我在开发服务器上完成编写和测试新功能，然后推送到生产服务器的新分支，检查新分支，然后合并所谓的“浮动分支”配置分支＆amp;然后重建源和＆amp;重启服务器。
如果发生任何意外情况，我可以快速查看最后一个功能分支＆amp;然后重建源和＆amp;重启服务器，减少生产停机时间。
显然这是一个混乱的工作流程，因为生产服务器最终会为每次更新提供一个新的分支。它还会造成混乱的分支层次结构。
另一件让我失望的事情是“浮动分支”配置合并不会在最后一次提交时写入更改。
所以例如： 如果我启动一个新的数据库实例来测试开发服务器上的内容并且然后按照我在合并配置分支时描述的工作流程，它不会过度写入数据库名称，我想是因为这个工作流程创建了复杂的分支层次结构。
这是一个懒惰的问题，但专家的一些简明建议肯定会减轻我的慢性认知超负荷。我是一个团队有很多细节要跟踪。
如果有人能给我一些更好的工作流程的见解。我在网上看到了几十个选项。在stackoverflow上，在生产服务器上使用非裸存储库是错误的形式等。 现在我只想稍微清理一下工作流程，以避免我所描述的那种事情。也许以后我会花几天时间真正进入git内部。在我检查git源本身之前，我怀疑我是否能够全面了解我的方式
答案 0 :(得分：1)
你让它变得更加复杂。 git的分布式特性意味着您可以使用本地存储库中的临时分支来完成所有操作，并使您的中央服务器看起来像更改被附加到一个分支上。我描述了一个适用于为生产和开发维护单独配置的工作流程here。
答案 1 :(得分：0)
您可能希望使用git fetch然后使用git reset --hard origin/master将生产副本恢复到上游的位置，然后重做浮动分支的合并。
git reset --hard origin/master只是重写你的本地分支引用指向origin / master指向的提交。