dud*_*ein 7 git remote-branch feature-branch git-flow git-branch
我正在按照这里描述的工作流程进行操作,因为我发现很多参考文献指出这个页面是一个很好的工作流程.正如文章中提到的,"功能"分支在开发人员之间共享,但不会转到中央存储库.
假设开发人员"A"启动了一个新的功能分支git checkout -b newfeature develop.现在让我们说开发人员"B"也需要处理这个功能.这是我的问题.
我做了什么:
git branch remoteA/newfeature现在,第3步无效.我收到一条消息:
remote:错误:默认情况下,更新非裸存储库中的当前分支被拒绝,因为它会使索引和工作树与您推送的内容不一致,并且需要'git reset --hard'来匹配工作树对HEAD.
remote:错误:您可以在远程存储库中将'receive.denyCurrentBranch'配置变量设置为'ignore'或'warn'以允许推入其当前分支; 但是,除非您安排更新其工作树以匹配您以其他方式推送的内容,否则不建议这样做.
remote:error:要压制此消息并仍然保持默认行为,请将receive.denyCurrentBranch'配置变量设置为'refuse'.
我已经设定了sharedRepository = true,但没有帮助.
我有两个问题:
共享功能分支的最简单方法是将它们简单地推送到中央存储库,这样任何人都可以从中获取.这样,您只需使用已有的主存储库基础结构,就可以轻松共享代码.
一旦不再需要遥控器上的功能分支,您只需删除它即可
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左右)中引入了裸存储库的概念 - 这是一个没有签出状态但只包含通常进入的数据库的存储库.git.
这种变化背后的原因是,无论何时你推动你的同事存储库(目前正在处理某些事情) - 你正在操纵他的鼻子下面的存储库.所以他检查了版本功能A-1 ..开始工作..然后你将featureA-2推到他的回购上当他想要承诺他遇到了麻烦,因为他所在的分支已提前一个他没有看到的提交发展.
因为这是非常具有破坏性的 - 大多数人已经采用了本地git存储库(你积极开展工作的那些)的概念应该是私有的,而你有一个公共git-repo(fork),你接收和共享更改.这样你在工作期间永远不会被其他任何人打断(无论如何这是分散模型背后的整个想法)并且只能包含你想要的变化.(没人能把东西推到你现在的工作上).
你可以推送到非裸仓库.你不能做的是推送一个非裸仓库,它有你要推出的分支机构.原因应该是有道理的.更改其他人可能正在处理的文件将是不正确的.
通常,您需要推送到主服务器或其他一些常见的共享分支.为了避免这种冲突,远程非裸存储库的所有者应该在本地分支或至少一些其他分支上工作.然后你可以推送到共享分支.
要使用您的示例:
git branch remoteA/newfeature
git checkout -b work-newfeaturegit rebase newfeature