如何使用 git /github 处理两个独立但非常相似的代码库？
处理 git 和 git-hub 中两个独立但非常相似的代码库的最佳方法是什么？
背景
我有一个小型 shell 脚本项目的 git 存储库。它只有 2 或 3 个代码文件，而我经常在单个文件中工作。尽管我最初创建该项目是为了服务于我的特定目标，但我编写它是为了对其他人更有用。我编写通用用例版本，然后对其进行修改以适应我的特定目标。在特定版本中，我可能会修改变量，输入密码，切换某些代码的顺序，取出 for 循环......等等。
我尝试过的方法
我尝试了两种不同的方法，但都没有达到我认为的最佳效果：
- 两个单独的存储库
- 问题：在一个代码中修改的代码无法轻松且有选择性地合并到其他代码
- 一个存储库中的其他两个分支
- 问题：分支最终会合并在一起。我的意思并不是将它们完全合并在一起，而是有选择地合并部分代码。
- 问题：我发现当尝试在分支之间使用合并命令时，很容易混淆哪个分支中的哪些代码被合并。我以某种方式在两个分支之间合并了代码，这是完全无意的，并且没有任何迹象表明合并不正确，直到我查看了两个分支中的文件内容
我还看到 如何将两个独立但相似的代码库合并为一个SVN 代表？ 这是关于 SVN 的。因为我不知道 SVN，所以我很难理解。我认为这是一个不同的问题，因为他并没有试图公开该代码的一个版本。
我想要解决的用例
具体来说，这个问题在以下情况下暴露出来：
- 注释同步 - 我正在准备我的专用版本，并注意到我可以在行尾添加解释性注释。我添加了它，但评论现在不在通用版本中。
- 我不想共享的东西 - 我正在准备我的专用版本，并添加密码或更改操作完成的顺序。我不希望这些更改进入通用版本。
- 同一文件 - 上述两个更改通常位于同一文件中，这使得很难将内容合并在一起。有交互式合并，但我不知道交互是否可以在单个文件内完成。
- 一般->专业化 - 我或其他人可能会更新通用版本以添加新内容或评论，这些内容或评论对我的专业版本也很有用。我想把这些从将军那里拿过来->专门化，不会弄乱专门版本中的任何其他代码差异。
Git 与 Github
我的问题主要是想知道如何在 git 的范围内执行此操作。然而，它也可能对如何与 github 交互产生影响。我的通用版本已在 github 上发布。专用版本不应该出现在 github 上。我认为如果我小心的话，我上面的分支方法不会推送两个分支......但我总是不确定。无论哪种方式，解决方案都应该允许有一个公开版本和一个仅保存在本地的版本......即使它有点复杂或需要小心。
What is the best method to handle two separate, but very similar code-bases in git and git-hub?
Background
I have a git repository for a small shell script project. It only has 2 or 3 files of code in it, and I am often working in a single file. Though I have originally made the project to serve a specific goal of mine, I write it to be more generally useful to others. I write the general use case version and then modify it to be specific to my specific goal. In the specific version, I might modify variables, put in a password, switch around the order of some of the code, take out a for loop... whatever.
What ive tried
I have tried two different methods and neither work as optimal as I would think that it could:
- Two seperate repos
- Problem: code modified in one, cant easily and selectively be merged over to other
- Two branches in one repo
- Problem: Branches are meant to eventually merge back together. I do not mean to ever fully merge these back together, but to selectively merge parts of the code.
- Problem: I found that when trying to use merge commands between the branches, it was very easily confusing as to what code in what branch was being merged. I somehow merged code amongst the two of them that was completely unintended and there was no indication as to the incorrect merge until I looked at the content of the files in both branches
I also saw How to merge two seperate - yet similar - codebases into one SVN rep? that is about SVN. Tough for me to follow since I do not know SVN. I think though that it is a different question, because he is not trying to make one version of this code public.
Use-cases I want solved
Specifically the issue comes to light when:
- Comment sync - I am prepping my specialized version, and notice that I could add an explanative comment at the end of a line. I add it, but the comment is now not in the generalized version.
- Stuff I dont want shared - I am prepping my specialized version and I add in a password or change the order of how operations are done. I DO NOT want these changes going to the generalized version.
- Same file - The above two changes will often be in the same file, which makes it hard to merge stuff together. There are interactive merges, but I do not know if the interaction can be done within a single file.
- General -> Specialized - I or someone else might update the generalized version to have new content or comments that would be useful to also have in my specialized version. I want to bring these over from general -> specialized, without messing with any other code differences in the specialized version.
Git vs Github
Mostly my question is wondering how to do this inside of git's confines. However, it may have implications on how to interact with github also. My generalized version is up on github. The specialized version should NOT be up on github. I think that my branch method above did not push both branches if I was careful... but I was always unsure. Either way, the solution should allow for there to be one version that is public, and one version that is just kept locally... even if it is a little complex or requiring care.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这可以通过两个分支轻松完成。我不知道你为什么说“在一个代码中修改的代码，不能轻易地、选择性地合并到另一个代码中”，因为合并在 Git 中非常容易。
我建议的结构是为您的通用版本创建一个分支，为您的个人版本创建一个分支。合并应该只发生在一个方向，从通用分支到个人分支。这意味着您对通用版本所做的任何更改都会合并到个人版本中。
换句话说，这是可以的......
这是你永远不应该做的......
如果你在你的个人版本中进行了更改，并决定在通用版本中使用相同的代码会很漂亮，你应该能够用樱桃镐就能很容易地处理这个问题。只需要稍微深思熟虑即可在个人分支中组织提交。您需要在个人分支中进行一次提交，其中仅包含您想要带到通用版本中的更改，然后只需将其从个人分支中挑选出来并将其放到通用分支上即可。
两个存储库可以完成同样的事情。这会降低您意外将个人版本上传到 Github 的风险，但也会使使用两个不同版本变得更加乏味。
就我个人而言，我会在同一个仓库中使用两个分支。
This can easily be done with two branches. I'm not sure why you say "code modified in one, cant easily and selectively be merged over to other," because merging is quite easy in Git.
The structure I would suggest is to have a branch for your general version and a branch for your personal version. Merges should only ever happen in one direction, from the general branch to the personal branch. This means that any changes you make to the general version get incorporated into the personal version.
In other words, this is OK...
This you should never do...
If you make a change in your personal version, and decide that it would be spiffy to have that same code in the general version, you should be able to handle this fairly easily with a cherry pick. It will just take a little forethought to organize the commits in the personal branch. You will need a commit in the personal branch that contains only those changes you want to bring over to the general version, then simply cherry pick it off the personal branch and drop it onto the general branch.
Two repositories can accomplish the same thing. This would reduce the risk of you accidentally uploading your personal version to Github, but it would make it more tedious to work with the two different versions.
Personally, I would go with two branches in the same repo.
为了避免将您的专用版本推送到 github，请将
push.default配置设置为tracking（或upstreamfor git >= 1.7.4.2） 。请参阅 http://longair .net/blog/2011/02/27/an-asymmetry- Between-git-pull-and-git-push/ 了解详细信息。无论您使用单独的存储库还是仅使用一个分支，合并都应该同样有效。作为一个高层次的答案，你最终必须非常擅长合并。其中很大一部分将来自于真正深入研究 git 在分支、合并和变基方面如何在低级别上工作。与其他一些版本控制系统不同，我发现 git 需要对其内部结构有深入的了解才能真正正确地使用它。
To avoid pushing your specialized version to github, set the
push.defaultconfig totracking(orupstreamfor git >= 1.7.4.2). See http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/ for the gory details.Merges should work equally well whether you use a separate repo or a just a branch. As a high level answer, you're ultimately going to have to get really good at merging. A lot of that will come from really digging into how git works at a low level regarding branching, merging, and rebasing. Unlike some other version control systems, I've found the git requires a deep understanding of its internals to really use it properly.
我赞同使用两个分支的想法：通用版本的公共分支（推送到 GitHub）和专用代码的私有分支（未在 GitHub 上发布）。但是，我想补充一点，
git stash是一个重要的工具，它允许您在您概述的场景中做您想做的事情（您正在开发个人版本） ，并且您发现通用版本中需要进行更改）。始终在常规分支中实施常规更改确实是一种很好的做法，然后执行“
现在，此外，您还可以有效地使用
git stash;”让我们假设您正在更新专用版本并考虑一般更改：您将当前更改保存到专用版本：
这会存储与上次提交相比的更改，而不创建新的提交。这对于存储正在进行的未提交的工作很有用。
您转到总分支，以便进行您正在考虑的总体更改：
然后您可以像往常一样实现您的常规修改并提交它。
在继续处理您的专用版本之前，您导入一般更改：
git 足够智能，可以很好地做到这一点：只应对您的代码进行最新的、通常有用的更新。
您可以通过导入正在进行的隐藏工作来恢复专业分支上的工作：
仅此而已！关键是使用 git stash 来保存工作中的更改，而无需为此创建提交，然后使用 git stash pop 应用回更改代码>.
I second the idea of using two branches: a public branch for the general version (which is pushed to GitHub) and a private branch for your specialized code (which is not published on GitHub). However, I would like to add that
git stashis an essential tool that allows you to do what you want to do in the scenario that you outline (you're in the middle of working on the personal version, and you find a change to be done in the general version).It is indeed good practice to always implement general changes in the general branch, and then do
Now, you can usefully use, in addition,
git stash; let's take the scenario where your are updating the specialized version and thinking about a general change:You save your current changes to the specialized version:
This stashes the changes compared to the last commit, without creating a new commit. This is useful for storing your uncommitted work in progress.
You go to the general branch so as to make the general change that you were thinking about:
You can then implement your general modification and commit it as usual.
Before resuming work on your specialized version, you import the general change:
git is intelligent enough to do this nicely: only the latest, generally useful update should be made to your code.
You resume your work on the specialized branch by importing your stashed work in progress:
That's all! The key is to use
git stashin order to save changes in the middle of your work, without creating a commit just for this, and then to apply back your changes withgit stash pop.使用 git 子模块。如果您想保留子模块的单独分支，请在该项目的存储库中创建一个分支，并将所有更改保留在该分支本地，并在子模块签出中仅使用该分支。
不同变更集之间的合并需要半手动完成。 Git 具有出色的合并支持，如果您不让两个分支彼此距离太远，您应该能够通过最少的手动干预来获得合并。 github（或任何其他托管提供商）实际上与这一切无关。如果您想将分支保持私有，请勿将其推送到公共存储库。就这么简单。
Use git submodules. If you want to keep a seperate branch of the submodule, make a branch in that project's repo and keep all changes locally to that branch, and use only that branch in the submodule checkout.
The merging between different change sets is something you'll need to do half-manually. Git has great merge support, and if you don't keep the two branches too far from each other, you should be able to get by minimal manual intervention. github (or any other hosting provider) really has nothing to do with any of this. If you want to keep a branch private, don't push it to the public repo. Simple as that.