我是Git新手(来自SVN)。我想知道是否有可能建立一个3层的软件开发环境。我说的第三层是这样的:
SVN
(as top remote repo)
|
GIT 1
(as middle tier remote repo)
/ \
GIT 2 GIT 3
(local git repo) (local git repo)
目前,我没有使用中间层(Git1)远程存储库。因此,只有本地Git存储库才会将更改推送到远程SVN存储库。
由于顶层SVN repo并不总是对我可用(由于连接问题),我想知道是否可以在中间层(Git1)放置一个中间层Git repo,所有客户端(Git2和Git3)都会推送更改,比方说,在一天结束时,Git1的更改将推送到SVN。
所以问题是:这种设置可能吗?
发布于 2011-12-16 10:28:48
当您推送回svn
时,作者身份将会丢失(如果您有多个提交者,这一点很重要),因为git-svn
使用一个用户来推送更改。但更糟糕的是,推送到svn
的提交将被修改(将添加svn
版本),这将使未来的工作变得痛苦,即使不是完全不可能。
发布于 2012-05-02 12:09:23
我同意Michal的观点,即3层解决方案可以巧妙地解决在存在到强制SVN顶层的糟糕网络连接的情况下处理分布式git副本的问题。
我自己也有这个问题。
我也同意Michael的观点,如果你试图以一种不守纪律的方式来做这件事,事情可能很快就会变得一团糟。
我还没有实现这个解决方案,但是我大概知道一个解决方案是什么样子的。
基本的想法是让git1维护一个以一种非常受控的方式更新的挂起分支。Git2和Git3中的开发人员会将他们的工作建立在未决的基础上(或者更好的是,在定义良好的时间点上获取未决的标签)
让我们:
SVN干线是跟踪
- pending always refers to a merge commit
- git rev-list --merges ^trunk pending^1 is empty # (no pending merge commits)
- pending and pending^1 are always sametree
--merges^待处理增量是空的,
然后,将增量集成到挂起中:
git checkout -f -B tmp delta
git rebase --onto pending^1 pending tmp
git checkout pending
git merge --ff-only tmp
git merge -s ours delta
git branch -D tmp
要将未来集成到待定中:
git checkout -f -b tmp future
git rebase --onto pending^1 pending tmp
git checkout pending
git merge --ff-only tmp
git merge -s ours future
git branch -D tmp
要将挂起集成到SVN中:
与SVN同步中继:
git checkout trunk
git svn rebase # should never fail
*此处为检查点中继
将挂起的^1重新设定为主干
git checkout -f -B tmp pending^1
git rebase --onto trunk trunk tmp
git checkout trunk
git merge --ff-only tmp
git svn dcommit # could fail with a race condition
# rollback to *** if this happens
将合并记录在pending中
git checkout -f -B tmp trunk
git merge -s ours pending
git checkout pending
git merge --ff-only tmp
git branch -D tmp
git tag INTEGRATED-XXX pending # Every commit reachable from INTEGRATED-XXX
# has been integrated with SVN
此解决方案在挂起的分支上使用仅信息(-s ours)合并提交,以记录源自git-land的提交已被合并到预定要交付到svn-land的分支中的事实。
因此,即使为了将提交提交到SVN而发生了rebase,这对于git-land中基于这样的提交的任何人来说都不应该是问题,因为git rev-list^pending应该只显示未集成的提交,并且集成周期的后续迭代只会重新设置这些提交的基础。
诚然,我只是举例说明了快乐世界的情况。我也没有说明增量不是与待决的简单线性偏差的情况。
如果挂起中有很多未交付的工作,并且在SVN上的rebase失败并且无法修复,那么事情可能会变得非常麻烦。只要你能解决这个问题,而不是中止rebase,你就很好。如果你不得不放弃重置基地,重建将会是混乱的。
我确实计划为这个策略实现一些脚本支持,并将在这里发布更新,让你知道它是如何进行的。
https://stackoverflow.com/questions/8532795
复制相似问题