我正在关注here所描述的工作流程，因为我发现许多引用指向此页面是一个很好的工作流程。正如文章中提到的，“功能”分支在开发人员之间共享，但不会转到中央存储库。
假设开发人员“A”使用git checkout -b newfeature develop启动新功能分支。现在让我们说开发人员“B”也需要处理这个功能。这是我的问题。
我做了什么：
git branch remoteA/newfeature 现在，第3步无效。我收到一条消息：
remote：error：默认情况下，更新非裸机中的当前分支 存储库被拒绝，因为它将生成索引和工作树 与你所推动的不一致，并且需要'git reset --hard' 将工作树与HEAD匹配。
remote：错误：您可以设置'receive.denyCurrentBranch'配置 变量为'ignore'或'warn'在远程存储库中允许 推进现有分支;但是，不建议这样做 除非您安排更新其工作树以匹配您推送的内容 以某种其他方式。
remote：错误：要压制此消息并仍保留默认值 行为，将receive.denyCurrentBranch的配置变量设置为 '拒绝'。
我已经设置了sharedRepository = true，但它没有帮助。
我有两个问题：
答案 0 :(得分：7)
共享功能分支的最简单方法是将它们简单地推送到中央存储库，这样任何人都可以从中获取。这样，您只需使用已有的主存储库基础架构，就可以轻松共享代码。
一旦不再需要遥控器上的功能分支，您只需执行
即可将其删除git push <server> :branch
我建议不要直接在开发者计算机之间共享，因为这样会出现问题，例如用户在不同的网络上（彼此没有连接）。
如果可能，您还可以使用GitHub模型，其中服务器上有一个中央存储库（受祝福的主存储库）。 除了主存储库之外，每个开发人员都拥有该存储库的“分支”，他可以在其中拥有完全的提交权限，并且可以根据自己的喜好推送分支。
在这种情况下，您可以将您的同事叉作为遥控器添加到您的存储库，同时保持对一个集中式服务器的轻松访问（省去了在每台机器上设置SSH密钥等的麻烦）。
可以在此处找到有关GitHub模型的说明： http://www.eqqon.com/index.php/Collaborative_Github_Workflow
更新：评论员指出，这是开始使用集中式功能分支工作流程的一个很好的链接：http://nvie.com/posts/a-successful-git-branching-model/
Update2 ：要扩展您的第二个问题：
您要做的是推送到另一个开发人员的非裸存储库。
Git在一些以前的版本（我认为1.6左右）中引入了裸存储库的概念 - 这是一个存储库，其 no 签出状态但只包含通常进入.git的数据库。
这种变化背后的原因是，每当你向同事的同事仓库（当前正在研究某些事情）推销时 - 你正在操纵仓库。所以他检查了版本功能A-1 ..开始工作..然后你将featureA-2推到他的回购上当他想要承诺他遇到了麻烦，因为他所在的分支已提前一个他没有看到的提交发展。
因为这非常具有破坏性 - 大多数人都采用了本地git存储库（你积极开展工作的那些）的概念应该是私有而你有一个公共git-repo（< em> fork ）您收到并分享更改的位置。这样你在工作期间永远不会被其他任何人打断（无论如何这是分散模型背后的整个想法）并且只能包含你想要的变化。 （没有人可以将某些东西推到你当前的工作上）。
答案 1 :(得分：5)
你可以推送到非裸仓库。你不能做的是推送一个非裸仓库，它有你要推出的分支机构。原因应该是有道理的。更改其他人可能正在处理的文件将是不正确的。
通常，您需要推送到主服务器或其他一些常见的共享分支。为了避免这种冲突，远程非裸存储库的所有者应该在本地分支或至少一些其他分支上工作。然后你可以推送到共享分支。
使用您的示例：
git branch remoteA/newfeature
git checkout -b work-newfeature git rebase newfeature