我希望我在本地git存储库中跟踪的文件在运行git-svn dcommit时没有检入中央svn存储库。我经常对存储库中跟踪的文件进行长期本地更改。有时这是为了调试代码。我还有项目IDE文件,我想跟踪。使用普通的旧svn,我只是将这些文件放入标记为“XYZ:不要检查”的更改列表中,然后在我实际需要提交更改时手动处理问题。
理想情况下,我想检查我的更改到我的主分支,但设置一些阻止这些特定更改传播到svn repo的东西。我会以传统方式使用git和git-svn,但某些提交永远不会被推高。显然,每次我提交时我都可以手动执行此操作,但这很痛苦。
我考虑过并放弃了一些事情。我不想排除这些文件,因为有时候我需要进行更改才能获得提交。此外,我希望这些文件出现在我创建的任何本地分支中,就像IDE文件一样。但是,我无法将这些更改隔离到单个分支,因为我会在每个分支中都需要它们,就像IDE文件一样。看起来像guilt或stgit这样的东西可能会做我想要的,但它并不明显,因为他们在git之上添加了他们自己的复杂层,我还在学习。
答案 0 :(得分:2)
我对git有点新,但我建议在你当地的git repo中使用一个单独的master和working分支。
仅将“非SVN”文件添加到工作分支中。通常在工作分支中进行所有代码更改。当“非SVN”文件发生更改时,使用唯一提交添加这些文件,并设置提交消息前缀(即“local:”或“private:”)。当您准备好提交SVN时:
显示要添加到SVN的提交日志:
git co working
git cherry master
将所有上游提交添加到主分支,忽略“私有”提交。重复此步骤,直到所有上游提交都在master中。
git co master
git cherry-pick <SHA1>
将提交推送到SVN repo:
git svn rebase
git svn dcommit
答案 1 :(得分:2)
我目前解决问题的方法是使用堆叠git(stg)并将这些本地更改作为单独的补丁维护。当我需要提交Subversion时,我会做一个
stg pop # naming the patches that should not be commited
stg commit # the rest of the patches to commit
git svn dcommit
stg push # naming the patches that are used locally
将这些作为单独的补丁维护的好处是我可以轻松地修改我的单元测试以测试不同的数据库后端。所以通常我会对Oracle进行测试,但如果我想检查Derby,我会做
stg push local-mods-derby
ant tests
stg pop
或者如果我想测试PostgreSQL,我运行
stg push local-mods-test-postgresql
ant tests
stg pop
这里,“local-mods-derby”和“local-mods-test-postgresql”是补丁名称。
因此,使用stg。
可以很容易地保留单独的工作补丁答案 2 :(得分:1)
您是否考虑过不在主分公司工作?
如果您将更改保存在本地git分支中,您可以定期合并或仅选择所需的更改到您的svn跟踪分支。切换到跟踪分支,运行您的dcommit。然后回到你当地的分公司并重新加油。
如果您想要在多个分支中进行更改,请将它们全部基于同一分支点。通过变基将该分支保持为主数据+更改。然后对于所有其他分支,只需重新关闭该基本分支。
答案 3 :(得分:0)
您可能需要考虑使用存储。
git-stash - Stash the changes in a dirty working directory away
虽然你所描述的内容可能不足。
答案 4 :(得分:0)
我做了一些研究,并提出了一种可能做到这一点的可能性:2个git存储库指向同一目录。环境变量GIT_DIR存储本地存储库目录的名称。如果未设置,git默认为.git,但它可以是任何内容。
我能做的是在.git中有一个映射到我的Subversion存储库的存储库。这是常见的情况。然后我可以在.localgit中拥有另一个存储库。必须将每个存储库配置为忽略另一个存储库管理的文件。这很容易!否定模式。
当我更改我想要签入的仅本地文件时,我要么更改我的GIT_DIR环境变量,要么使用--git-dir命令行参数。如果我有正确的排除/忽略设置,我将不必担心碰撞。显然有一些开销要保持最新,但是我可以编写一个包装脚本,当文件添加到另一个文件时,该脚本会将文件添加到一个repo的排除中。此外,该开销仅在每个文件中发生一次,而不是像多分支建议那样在每次提交时发生。
如果我想让它更简单,我可以使用命名约定,但我也可以在每个单独的文件上执行,因为本地文件的数量几乎肯定是单个数字(否则我是做错事。)
我用这种方法看到的一个缺点是,我无法以与SVN存储库中的文件相同的方式分支,存储和重置仅本地文件。尽管如此,我对这些修改的修改可能与我的主编辑不同步,因此我认为这在实践中不会是一个重大问题。我还可以为那些具有多存储库感知功能的函数编写包装器。此外,在管理仅限本地文件时,我必须更加明确,但几乎任何情况都必须处理,缺少多个存储库构建到git本身。