如何与多个开发人员共享 git 功能(或主题)分支

发布于 12-21 07:27 字数 963 浏览 6 评论 0原文

我正在遵循此处描述的工作流程,因为我发现了很多指向此页面的引用是一个很好的工作流程。正如文章中提到的,“feature”分支在开发人员之间共享,但不转到中央存储库。

假设开发人员“A”使用 git checkout -b newfeaturedevelop 启动一个新功能分支。现在假设开发人员“B”也需要开发此功能。这是我的问题。

我做了什么:

  1. 开发人员“B”将开发人员 A 的机器添加为远程
  2. 开发人员“B”运行 gitbranchremoteA/newfeature
  3. 开发人员“B”在此分支上工作,提交他的工作并将更改推送回远程A.

现在,第 3 步不起作用。我收到一条消息:

远程:错误:默认情况下,在非裸中更新当前分支 存储库被拒绝,因为它将创建索引和工作树 与您推送的内容不一致,并且需要“git reset --hard” 将工作树与 HEAD 相匹配。

远程:错误:您可以设置“receive.denyCurrentBranch”配置 在远程存储库中将变量设置为“忽略”或“警告”以允许 推入当前分支;但是,不建议这样做 除非您安排更新其工作树以匹配您推送的内容 以其他方式。

远程:错误:抑制此消息并仍保留默认值 行为,将 receive.denyCurrentBranch' 配置变量设置为 “拒绝”。

我已经设置了 sharedRepository = true,但没有帮助。

我有两个问题:

  1. 在开发人员之间共享功能分支的正确方法是什么?
  2. 如何将开发人员 B 的存储库中的更改推回到开发人员 A 的原始存储库中?

I'm following the the workflow described here, as I found many references pointing to this page as a good workflow. As mentioned in the article, "feature" branches are shared between developers, but do not go to the central repository.

Let's say a developer "A" starts a new feature branch with git checkout -b newfeature develop. Now let's say that developer "B" needs also to work on this feature. This is my problem.

What I did:

  1. developer "B" adds developer A's machine as a remote
  2. developer "B" runs git branch remoteA/newfeature
  3. developer "B" works on this branch, commit his work and pushes the changes back to remoteA.

Step 3 is not working, right now. I get a message:

remote: error: By default, updating the current branch in a non-bare
repository is denied, because it will make the index and work tree
inconsistent with what you pushed, and will require 'git reset --hard'
to match the work tree to HEAD.

remote: error: You can set 'receive.denyCurrentBranch' configuration
variable to 'ignore' or 'warn' in the remote repository to allow
pushing into its current branch; however, this is not recommended
unless you arranged to update its work tree to match what you pushed
in some other way.

remote: error: To squelch this message and still keep the default
behaviour, set receive.denyCurrentBranch' configuration variable to
'refuse'.

I have already set sharedRepository = true, but it did not help.

I have 2 questions:

  1. what's the correct way to share feature branches between developers?
  2. how can I push back the changes in developer B's repository to developer A's original one?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

花间憩2024-12-28 07:27:15

共享功能分支的最简单方法是将它们推送到中央存储库,以便任何人都可以从中提取。这样您就可以简单地使用主存储库已有的基础设施,并且可以轻松共享代码。

一旦不再需要远程上的功能分支,您可以通过执行以下操作简单地删除它:

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/

更新2:扩展你的第二个问题:

你想要做的是推送到另一个开发人员的非裸存储库。
Git 在之前的某个版本(我认为是 1.6 左右)中引入了裸存储库的概念 - 这是一个没有签出状态但仅包含通常进入 .git 的数据库的存储库

此更改背后的原因是,每当您推送到同事的存储库(当前正在处理某事)时,您就在他的眼皮子底下操纵存储库。所以他检查了版本 featureA-1 .. 开始工作 .. 然后你将 featureA-2 推送到他的存储库上,当他想要提交时,他遇到了麻烦,因为他所在的分支已经前进了一次他在提交期间没有看到的提交发展。

因为这是相当具有破坏性的 - 大多数人都采用了本地 git 存储库(您积极工作的存储库)的概念应该是私有的,而您拥有公共 git 存储库(分叉) )您接收和共享更改的地方。这样,您在工作期间就永远不会被其他人打断(无论如何,这就是去中心化模型背后的整个想法),并且只能合并您想要的更改。 (没有人可以把某些东西强加到你当前的工作上)。

The easiest way to share feature branches is to simply push them to the central repository so anyone can pull from them. That way you can simply use the infrastructure you already have for your main repository and you can easily share code.

Once a feature branch on the remote is no longer needed you can simply delete it by doing a

git push <server> :branch

I'd advise against sharing directly between developer machines as that is prone to problems like users being on different networks (not connected to each other).

If possible you can also use the GitHub model where there is one central repository on the server (the blessed main repo).
And besides that main repository each developer has a "fork" of that repository where he has full commit access and can push branches to his liking.

In this case you can add your coworkers forks as remotes to your repository while maintaining easy access to the one centralized server (saving you the hassle of setting up SSH keys on every machine etc etc)..

A description on the GitHub model can be found here:
http://www.eqqon.com/index.php/Collaborative_Github_Workflow

Update: As a commentor pointed out this is a good link to get started with the centralized-feature-branch workflow: http://nvie.com/posts/a-successful-git-branching-model/

Update2: To expand on your second question:

What you are trying to do is push to a non-bare repository of another developer.
Git introduced in some previous version (I think 1.6 or so) the concept of a bare repository - that's a repository that has no checked out state but only contains the database that normally goes into .git.

The reasoning behind this change was that whenever you push to your fellow co-workers repository (who is currently working on something) - you are manipulating the repository right under his nose. So he checks out version featureA-1 .. starts work .. you then push featureA-2 onto his repo and when he wants to commit he runs into trouble because the branch he was in has advanced by one commit he didn't see during development.

Because this is quite disruptive - Most people have adopted the notion of local git repositories (the ones where you actively do work on) should be private while you have a public git-repo (the fork) where you receive and share changes. That way you will never be interrupted by anyone else during your work (that's the whole idea behind the decentralized model anyway) and can only incorporate changes you want to have. (Nobody can push something onto your current work).

风追烟花雨2024-12-28 07:27:15

您可以推送到非裸存储库。您不能做的是推送到具有您要推送到签出的分支的非裸存储库。这其中的原因应该是有道理的。更改其他人可能正在处理的文件是不正确的。

通常,您会希望推送到 master 或其他一些公共共享分支。为了避免这种冲突,远程非裸存储库的所有者应该在本地分支或至少某个其他分支上工作。然后你就可以推送到共享分支。

使用您的示例:

  1. 开发人员“B”将开发人员 A 的计算机添加为远程
  2. 开发人员“B”运行 gitbranchremoteA/newfeature
    1. 开发人员“A”在本地分支机构工作。 git checkout -b work-newfeature
  3. 开发人员“B”在此分支上工作,提交他的工作并将更改推送回远程A。
    1. 开发人员“A”进行变基以获得新工作:git rebase newfeature

You can push to a non-bare repo. What you cannot do is push to a non-bare repo that has the branch that you are pushing to checked out. The reason for this should make sense. Changing the files that someone else is possibly working on would be incorrect.

Typically you will want to push to master or some other common shared branch. In order to avoid this conflict, the owner of the remote non-bare repo should work on a local branch or at least some other branch. Then you can push to the shared branch.

To use your example:

  1. developer "B" adds developer A's machine as a remote
  2. developer "B" runs git branch remoteA/newfeature
    1. developer "A" does work on a local branch. git checkout -b work-newfeature
  3. developer "B" works on this branch, commit his work and pushes the changes back to remoteA.
    1. Developer "A" rebases to get the new work: git rebase newfeature
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文