过去三周我一直在使用git-svn。
目前我的工作流程是这样的。
问题
我想要的是在本地编辑文件,将文件移动到服务器,测试,提交。
这可能是一个很好的工作流程吗?
我以前的尝试包括
我没有尝试过最后一步,因为git-svn提到如果你使用git-svn,从另一个git repo推/拉/合并是危险的。
请您使用示例命令建议一些有效的工作流程吗?
由于
答案 0 :(得分:3)
我可能遗漏了一些内容,但我认为git svn
文档中的警告不适用于我在下面建议的工作流程。 (顺便说一句,我假设您很乐意只从开发框中git svn dcommit
开心。)
将存储库中的存储库克隆到本地计算机上。假设您然后在本地创建一个名为excellent
的新主题分支。你在新的分支上做了一些工作。
现在你想在dev框中测试它,但为了避免推入非裸存储库的问题,你可以使用一种技术suggested in the git FAQ直接推送到{{{{}下的引用1}}。例如,您可以这样做:
refs/remotes/
现在您应该登录开发框。然后,您可以根据刚刚使用git push origin excellent:refs/remotes/from-desktop/excellent
您可以像在示例中的主题分支一样处理此分支,如果您对此感到满意,请确保在执行git checkout -b excellent from-desktop/excellent
之前仍然执行相同的序列,即git svn dcommit
,git rebase master
,git checkout master
,git merge excellent
我不明白为什么该工作流会导致git svn dcommit
出现问题,因为在执行git svn
之前,您需要小心工作并将其合并到master
。< / p>
答案 1 :(得分:1)
我使用的工作流程与您的工作流程相反,效果很好。
通过倒置,我的意思是我的git-svn仓库在我当地的盒子上,然后我推送到开发箱。
有三个回购:
我很少在测试回购中编辑(#3)。如果我做了一个简单的编辑,我通常只需在本地框上的repo#1上手动进行相同的编辑。我偶尔将测试仓库(#3)的提交推回到裸仓(#2),然后从本地框中将它们拉入git-svn仓库(#1)。更常见的是,我正在寻找一个难以发现的错误并在测试仓库中直接进行一些小改动(#3),当我发现错误时,我只是抛出所有这些调试更改并且将bug直接修复到git-svn repo(#1)中,然后推送到#2,进入#3并进行测试。
工作流程是:
我有时会在第8步之前进行交互式变基,以清理历史记录。