使用 git-svn 维护一组本地提交
我正在使用 git 来开发一个在 subversion 中托管的项目,使用 git-svn:
git svn clone svn://project/
我的一般工作流程是在 master 分支上重复编辑和提交,然后通过以下方式提交到 svn 存储库:
git stash
git svn dcommit
git stash apply
' 的本地修改之一stash' 命令正在保留,我不想提交到 svn 存储库,是更改的数据库连接字符串。在没有额外“隐藏”步骤的情况下保留此本地更改的最方便方法是什么?
我怀疑像“stash”或“quilt”这样的东西就是我正在寻找的东西,但我仍然很新,我认为我错过了一些可以导致确切咒语的术语。
更新:我发现的唯一解决方案似乎避免了 git stash
+ git-svn action
+ git stash apply
系列是手动更新 git-svn ref:
(check in local-only change to 'master', then...)
$ cat .git/refs/master > .git/refs/remote/git-svn
$ git svn fetch (with at least one new SVN revision)
这使得仅本地提交成为两个 svn 修订之间的奇怪(可能不安全)提交。
I am using git to develop against a project hosted in subversion, using git-svn:
git svn clone svn://project/
My general workflow has been to repeatedly edit-and-commit on the master branch, then commit to the svn repository via:
git stash
git svn dcommit
git stash apply
One of the local modifications that 'stash' command is preserving, that I don't want to commit to the svn repository, is a changed database connection string. What's the most convenient way to keep this local change without the extra 'stash' steps?
I suspect that something like 'stash' or 'quilt' is what I'm looking for, but I'm still new enough to git that I think I'm missing some terminology that would lead to the exact incantation.
Update: The only solution I found that seems to avoid the git stash
+ git-svn action
+ git stash apply
series was to update the git-svn ref manually:
(check in local-only change to 'master', then...)
$ cat .git/refs/master > .git/refs/remote/git-svn
$ git svn fetch (with at least one new SVN revision)
And that leaves the local-only commit as a weird (probably unsafe) commit between two svn revisions.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
一种可能的方法是拥有一个仅进行本地修改的“本地”分支,并从中分支出一个“工作”分支。在此设置中,您可以:(
自然地,并为其创建一个 shell 脚本)
我刚刚开始在项目中使用此方法,此方法可能有缺点。
One possible approach is to have a "local" branch with the local-only modifications, and branch a "work" branch from it. In this setup you can:
(and create a shell script for it, naturally)
I just started using this on a project and there may be drawbacks to this method.
我必须同意,真正的解决方案是不要提交不属于存储库的内容。我会去找你试图说服的人,告诉他你想添加一种机制,可以用你在本地系统上添加的文件覆盖默认属性。
例如,没有干净的方法来解决重命名属性时可能发生的合并冲突。所以我认为你正在寻找一个实施不佳的解决方案的黑客,这就是为什么没有直接回答你的问题会显得不那么黑客。
I must agree that the real solution is not to commit stuff that doesn't belong in the repository. I'd go to the guy you're trying to convince and tell him that you want to add a mechanism where you can override the default properties with a file you add on your local system.
There is no clean way to solve the merge conflicts that might occur when the property is renamed for example. So I think you're looking at a hack for a poorly implemented solution and that is why no direct answer to your question is going to seem unhackish.
不完全是您问题的 git 答案,但仍然有用:
这是 django 圈子中的标准做法,将数据库连接等包含在不在存储库中的本地文件中,称为 localsettings.py
该文件对于每个环境都是唯一的您部署在;它有助于在存储库中包含一个示例文件,例如 localsettings.py.example。
否则,包含所有存储库的配置文件并实现基础设施以根据主机名查询适当的文件。
Not exactly a git answer to your question, but useful nonetheless:
It is a standard practice in the django circles to include the database connections etc in a local file that is not in the repository, called localsettings.py
This file is unique to each environment you deploy in; It helps to include an example file with the repo, say, localsettings.py.example
Otherwise, include all repos' config files and implement infrastructure to query the appropriate ones based on the host name.
我将 stg (它是 quilt 但与 git 集成)与 git svn 一起使用。
我在 stg 中有补丁,以我不想发送到上游的方式修补构建系统 - 所以这就像你的数据库补丁。
应用补丁:
stg pop -a
stg 推送我想要应用的补丁名称
git svn dcommit
或根据最新的 SVN 进行变基:
git svn fetch
stg rebase trunk (或者你的 svn 分支的名称)
I use stg (which is quilt but integrated with git) alongside git svn.
I have patches in stg that patch the build system in a way that I don't want to send upstream - so thats like your DB patch.
To apply patches:
stg pop -a
stg push patch-name-that-i-want-to-apply
git svn dcommit
or to rebase against latest SVN:
git svn fetch
stg rebase trunk (or whatever your svn branch is called)