L. *_*son 5 git git-workflow git-bundle git-am
我有两个房间,我使用git维护一些源代码,大多数开发发生的"开发"房间和我们实际使用软件的"部署"房间.部署室中也不可避免地发生了一些变化.我希望两个房间在git中分享相同的历史.
限制:
将更改移动到部署室是很简单的git bundle,并跟踪我们移动到部署室的最后一次提交.由于纯文本限制,将更改移出房间更加困难.
目标:在两个未连接的房间之间来回移动,就像发生git pull了一样,即两个房间中的SHA1哈希相同.
至今:
我已尝试git format-patch将更改从部署移回dev,但这不记录合并,因此需要为每个连续的更改集生成不同的补丁集以及如何重现精确合并提交的一些记录发生在两者之间.有一些关于为合并提交制作差异的讨论,但这似乎并没有捕获实际的祖先,只捕获了变化.似乎补丁可能不是足够丰富的格式来提供必要的信息.
可以使用一些bundle-to-text脚本将bundle转换为非压缩和人类可读(ish)格式(然后在下载后再返回)但我没有发现存在这样的脚本的证据.
也许可以编写一个脚本来将历史记录从一些共同的祖先转到最新的提交,并且a)制作补丁或b)重新创建一些众所周知的引用的合并.
回退: 我总是可以将从部署室出来的提交压缩成一个原始补丁并打破历史记录,但是从dev-> deploy进一步下载会破坏任何现有的工作副本.不理想.
更新:
我相信git fast-export可能会做我需要的东西,虽然大多数例子都有它在整个存储库上工作,而不是像部分历史git bundle.我有一个工作的玩具示例,我可以将部分历史记录导出到一个过时的克隆,但它需要我手动编辑快速导出输出,以便我添加from <sha1>到第一个提交.如果没有这个修改,导入会创建不同的sha1,然后抱怨Not updating refs/heads/master (new tip <hash> does not contain <master's hash>).
Update2:
我的git fast-export解决方案确实有效,但它有带宽问题,因为它通过提供全新文件而不是以前文件的差异来工作.这是不可接受的,因为我实际上必须阅读所有这些额外的行.
我从未找到完美的解决方案,但我们现在所做的似乎也有效.主要缺点是部署室内的提交最初有一个SHA1,然后在与开发室合并后更改为不同的SHA1.好消息是git很容易识别它们,因为相同的提交可以merge通过它们.
dev/master 它是开发室中最新开发的.deploy/master 它在部署室有最新的发展.dev_deploy_common 这是两个历史共享的最后一次提交..
当我们将代码从dev移动到部署(使用bundle)时,我们将提交作为dev_deploy_common部署中的分支的一部分(git pullinto dev_deploy_common),然后从deploy/masterdo a git merge dev_deploy_common解决并在那里发生冲突.
当我们将代码从deploy移动到dev(必须是文本文件)时,我们会做一些额外的步骤:
首先,我们变基deploy/master上dev_deploy_common,使我们所有的补丁是连续的.这通常很容易,因为我们已经处理了从将dev从开发部署到部署时发生的合并期间的任何冲突.
其次,我们使用生成补丁集
git format-patch -M25 -C25 --find-copies-harder -k --ignore-if-in-upstream
该-M25 -C25 --find-copies-harder选项只是减少输出文本大小.该-k选项使提交主题保持不变.在--ignore-if-in-upstream制约着我国提交给刚刚因为换新dev_deploy_common.
结果是一patchset.txt组补丁.可以对此文件进行手工审核,然后将其移至开发室.
在开发室中,我们使用以下命令导入补丁集:
git am -k -3 --keep-cr --committer-date-is-author-date patchset.txt
不幸的是,即使我们使用所有命令来保持补丁完全相同,一些属性也会发生变化,主要是提交者.因此,"相同"提交将在开发和部署室中具有不同的SHA1.这种差异将一直存在,直到我们将一个捆绑回到部署室.
将捆绑包从dev移动到部署时,merge操作(通常)会识别相同的修补程序,并使用dev历史记录中的提交无缝替换提交.见步骤1.
| 归档时间： |
|
| 查看次数： |
533 次 |
| 最近记录： |