我想创建一个存储库[B],它在一个名为x_master的分支中跟踪远程存储库的主[A]。它自己的主人也应该是初始创建时的克隆,其他人[Devs]可以克隆并推送更改。
偶尔,由于A中有变化,我需要能够将它们拉下来并将它们合并到B的x_master中(如果我理解这一点,那么它应该是快进的,因为它们将是唯一的变化。 B)上的x_master分支,然后能够将这些变化合并到B的主人身上,从而将任何人在他们拉动时克隆B的主人。
我在概念上想要的是:
master x_master
[A] <---------> [B] <-------> [Dev2]
^-------> [Dev1]
master
最终我需要在完成所有开发时将B的主人的更改推送到A的主人,但是A中的更改将需要合并到B
我已经尝试了各种克隆 - 镜像,分支 - 轨道,并且似乎没有正确推送和拉动A和B中的更改。
答案 0 :(得分:7)
我确信它有一个快捷方式,但我倾向于使用基本命令。无论如何,请为B
设置存储库:
$ cd repo_B
$ git init --bare
$ git remote add upstream URL_FOR_REPO_A
$ git fetch upstream +master:refs/heads/x_master
$ git branch master x_master
当修改上游存储库时,您需要在裸存储库 1 中提取这些更改:
$ git fetch upstream +master:refs/heads/x_master
这将覆盖{sup> 2 x_master
中任何可能的更改,因此您最好不要单独留下该分支。 :)
当/如果A发生变化时,您需要将x_master
中的上游更改合并到master
。不幸的是,在这个阶段可能存在冲突,因此必须使用我们裸存储库的克隆来完成。只需克隆B存储库(到本地或远程位置),然后将x_master
合并到master
,解决冲突并推回。
最后的任务是将master
中的开发推送到存储库A.这可以通过两种方式完成。第一种方法是直接将B的主服务器推送到存储库A.这可以通过运行:
$ git push upstream
存储库B上的。另一种选择是使用第三个存储库从master
到x_master
的更受控制的合并:
$ git clone URL_FOR_REPO_A
$ cd repoDir
$ git remote add dev URL_FOR_REPO_B
$ git fetch dev
$ git branch --track master_b dev/master
$ git merge master_b
$ <resolve conflicts, if any>
$ git push origin master
完成后,您可以将远程配置为仅默认获取该分支:
$ git configure branch.upstream.fetch +master:refs/heads/x_master
使用--add
,您甚至可以添加更多分支来获取:
$ git configure --add branch.upstream.fetch +branch_1_0:refs/heads/x_branch_1_0
现在,fetch可以在没有refspecs的情况下正常工作:
$ git fetch upstream
为了防止推送到master
repo_B
,您可以使用pre-receive
或update
等server-side hook。
答案 1 :(得分:1)
我受到启发,但也被vhallac的回答搞糊涂了。我认为更简单的东西也可以起作用......
mkdir (name).staging.git ; cd (name).staging.git
git init --bare
git remote add origin (remote-repo)
定期(包括最初),您将需要获取更改并更新本地分支...
git fetch
for remote in $(git branch -r) ; do git branch --force --no-track $(basename $remote) $remote ; done
请注意,每次获取时都需要更新本地分支,否则第三级repo将看不到上游更改。我的示例更新所有本地分支,但您可以改为仅针对感兴趣的分支手动执行此操作。我建议创建一个别名“git staging-fetch”,它将这两行组合成一个命令。
只要不需要合并(只需进行常规推送),从暂存存储库推送到主存储库就很简单。如果推送因冲突而失败,那么您需要通过两个级别获取更新并解决工作存储库中的问题。
注意:此方案不需要名为“x_master”的分支。 Git内置支持使用本地分支来影响远程分支。因此,所有“主”分支都被称为“主”,但在引用紧邻上游存储库中的分支时,您可以根据具体情况将其称为“origin / master”或“staging / master”。
branch: origin master staging master working master
============= ============== ==============
origin sees: master
staging sees: origin/master master
working sees: staging/master master
答案 2 :(得分:0)
最好的方法是让一个负责任的开发人员(称他为dev0)来做这些事情。他必须具有对A的读写权限。他可以将A设置为本地仓库中的遥控器,并通过将A / master的提交提取到他的本地x_master并将其推送到B来维护B / x_master。正如您所提到的,那应该是轻松,永远快速前进。 (所以它可以编写脚本)
由于B / x_master对所有开发人员也是可见的,任何人都可以合并(并查看/修复冲突)x_master,当他们觉得需要将它集成到开发中时。
开发完成后,dev0会将master合并到x_master。由于可能的冲突,这无论如何都需要人的监督。此时他还有机会取消合并并执行其他提交以反映您的开发分支中的冲突。所以你也可以在小组讨论它们。完成后,dev0可以再次尝试将master合并到x_master。然后x_master被推送到A / master。
答案 3 :(得分:0)
我假设A和B都是裸存储库,仅用于推拉,对吧?
我认为最简单的方法就是在A和B之间简单地建立一个中间存储库。也就是说,一个非裸的存储库,有一个工作树。这样,你可以从A和B中的任何一个分支中完全和平地隔离并与其他人隔离,微调合并直到你对它们完全满意,然后将它们推送到A和B中的任何一个
当然,如果您已有工作副本,则只需将该副本用作该中间存储库即可。没有特别需要创建一个明确的;只需在临时分支机构中完成所有中间工作。