如何在 Git 中管理多个开发分支？
我有一个系统的 5 个分支 - 让我们称它们为 master、London、Birmingham、Manchester 和 demo。它们仅在配置文件上有所不同，并且每个都有自己的一组图形文件。
当我进行一些开发时，我从 master 创建一个临时分支，在功能之后调用，然后进行处理。当准备好合并时，我会检查 master 和 git merge 功能来引入我的工作。这看起来效果很好。
现在我需要将更改转移到其他分支中，同时又不丢失它们之间已有的差异。我怎样才能做到这一点？我在伯明翰获得伦敦的图形以及配置文件中的冲突方面遇到了无穷无尽的问题。
当分支最终正确时，我将其推送到仓库，并将每个分支拉到 Linux 机器上进行最终测试，从那里发布到生产环境中使用 rsync（设置为忽略 .git 存储库本身）。这个阶段也运行得很好。
我是目前唯一的开发人员，但在寻求帮助之前我需要先确定流程：）
I have 5 branches of one system - let's call them master, London, Birmingham, Manchester and demo. These differ in only a configuration file and each has its own set of graphics files.
When I do some development, I create a temp branch from master, called after the feature, and work on that. When ready to merge I checkout master, and git merge feature to bring in my work. That appears to work just fine.
Now I need to get my changes into the other branches, without losing the differences between them that are there already. How can I do that? I have been having no end of problems with Birmingham getting London's graphics, and with conflicts within the configuration file.
When the branch is finally correct, I push it up to a depot, and pull each branch down to a Linux box for final testing, From there the release into production is using rsync (set to ignore the .git repository itself). This phase works just fine also.
I am the only developer at the moment, but I need to get the process solid before inviting assistance :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有两种技术可以提供帮助：
因此，当您开发新功能时，您需要做的就是让其他站点从中受益是确保它们各自的存储库引用最新的公共代码存储库作为子模块。只需更新 git 子模块即可完成。
另外，使用模板配置文件，您存储的只是配置值，而不是实际的配置文件本身（它们是生成的）。
这允许您在每个站点上进行一些微调，而不必“忽略”本地修改。
总之：不要尝试在一个存储库（以及涉及的所有合并和变基）中管理所有方面（通用代码、配置文件、特殊文件……），而是尝试模块化您的应用。
Two techniques can help:
So when you develop a new feature, all you need to do for the other sites to benefit from it is to make sure their respective repo reference the latest common code repo as a submodule. Just a
git submodule updateto do and you are done.Plus, with template config files, all you are storing are config values, not the actual config files themselves (they get generated).
That allows you some fine-tuning on each site, without having to "ignore" local modifications.
In conclusion: instead of trying to manage all aspects (common code, config files, special files, ...) in one repo (with all the merge and rebase that will involve), try to modularize your application.
git rebase是你的朋友。像往常一样在主分支中进行更改。完成后，检查其他分支机构之一（例如伯明翰）并运行
git rebase master。 git 将拉取您在当前提交和伯明翰所基于的提交之间对 master 所做的更改。互联网上有关于该命令的很好的文档。这是我发现的两个http://darwinweb.net/articles/86
http://www.eecs.harvard.edu/~cduan/technical/git/git- 5.shtml
还有很多其他的。您会发现很多人都在谈论变基的危险。请注意这些担忧，但我怀疑在您的案例中，好处远远大于风险；了解危险就成功了一半。
git rebaseis your friend.Make your changes in your master branch as you always do. When you are done, checkout one of your other branches (say, Birmingham) and run
git rebase master. git will pull in the changes you made on master between the current commit and the commit on which Birmingham is based. There are good documents on the command out on the interweb. Here are two I foundhttp://darwinweb.net/articles/86
http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml
There are many others. You will find many people talking about the dangers of rebasing. Pay heed to those concerns, but I suspect the benefits vastly outweigh the risks in your case; and knowing the dangers is half the battle.
另一种技术：
一旦您的新功能位于 master 中，请将 master 合并回所有其他相关分支。
原始状态：
master 中的新提交：
将新功能合并到伦敦分支，使用 git checkout London； git merge master：
但是请注意，这可能很麻烦，特别是当分支数量增加时。
我对您的系统一无所知，但如果您可以将所有配置放在一个分支中，那可能会更容易（我的意思是让所有五个配置文件和图形文件始终存在于您的文件系统中）。
例如，使用 makefile，您可以根据当前的目标配置选择要编译和链接的源文件。对于您的情况，makefile 可以帮助您将图形文件和配置文件与目标配置关联起来。
如果能够构建所有配置而无需中间进行任何检查，那就太好了，不是吗？
Another technique:
Once your new functionality is in
master, merge back master into all the other relevant branches.Original state:
New commit in master:
Merge the new functionality into the London branch, with
git checkout London; git merge master:Note however that this might be cumbersome, especially if the number of branches increase.
I don't know anything about your system, but if you can have all configurations in one branch it would probably be easier (I mean having all the five configuration files and graphics files always present in you file system).
For example with a makefile, you could choose which source files to compile and link depending on your current target configuration. In your case, a makefile can help you to associate graph files and config files with a target configuration.
It would also be nice to be able to build all your configurations without any checkouts in between, would't it?