git如何在不同分支中保持配置文件不同? [英] git how to keep a config file different in different branches?

问题描述

请允许我先说一下我的尝试.假设我有两个分支，Alice1和Alice2. Alice1拥有自己的服务器，而Alice2也拥有自己的服务器.我希望能够签出到Alice1，编写我的代码，然后通过使用保存在URL配置文件中的URL直接推送代码来在自己的服务器上对其进行测试，因此它必须保留在本地. Alice2也有自己的服务器，如果代码在Alice1上测试得很好，我将签出到Alice2，并与Alice1同步，然后将其推送到Alice2的服务器上.有时我希望Alice1和Alice2具有独立的测试环境，以便在我希望将它们合并之前可以将它们分开.

Allow me phrase my attempt first. Let say I have two branch, Alice1 and Alice2. Alice1 has it's own server and Alice2 has his own too. I want to be able to checkout to Alice1, writing my code, then test it on its own server by pushing the code directly using the URL that is saved in the URL config file so it has to stay in local. Alice2 has its own server also, if the code is tested fine on Alice1, I will checkout to Alice2, and sync with Alice1, then push it on Alice2's server. Sometimes I want Alice1 and Alice2 have independent testing environment so they can be seperate until I want to merge them.

我已经对此进行了很长时间的研究，但仍未找到可靠的答案.最受欢迎的解决方案是使用.gitattribute并执行merge = ours，但它的缺点是git有时在转发时会忽略它们.合并时我也尝试了checkout文件，但这仅在一次合并中起作用，而不是每次合并. Gitignore不能正常工作，因为他们不跟踪该文件，因此该文件中的所有更改都将丢失.

I have been researching this for a long time but still not finding a reliable answer. The most popular solution is using .gitattribute and do merge=ours but it has cons that git will sometimes ignore them in forwarding. I also tried checkout file while merging, but this only works in one merge instead of every merging. Gitignore doesn't work obiviously as they don't track this file so all changes in this file will be lost.

目前，我有两个分支，master和dev.有一个文件调用.clasp.json.我希望此文件在每次签出时在这些分支中都不同，并且合并不应触及这些文件.

Currently, I have two branch, master and dev. There is a file call .clasp.json. I want this file be different in these branches on every checkout, and merge should not touch those files.

我正在考虑是否可以编写一个脚本，该脚本每次在结帐到分支时都根据分支名称生成文件，我不知道是否有办法吗?我发现我可以使用内容过滤器驱动程序，但是那里没有简单的文档，请提出任何建议?

I'm thinking if I can write a script that everytime when checkout to a branch, generate the file based on the branch name, I don't know if there is a way of doing it? I found I can use content filter driver, but there isn't a straight forward document out there, any recommandations please?

我尝试过的方法:该方法可以一次合并，但是在下一次合并中该文件仍然会被合并. https://stackoverflow.com/a/4516022

What I have tried: This method works in one merge, but the file will still get merged in the next merge. https://stackoverflow.com/a/4516022

在merge = ours中正确使用.gitattributes的方法是什么?此方法仅在发生合并冲突时才有效，在我的情况下，我不会在第一次编辑后编辑文件，我只是希望它保持不同每个分支.

Whats the Proper usage of .gitattributes with merge=ours This method will only work if there is a merge conflict, which in my case, I won't edit the file after the first edit, I just want it stay different in each branch.

推荐答案

在Git中无法执行此操作的原因是Git与分支无关. ¹

The reason you can't do this in Git is that Git isn't about branches.¹

好，不能太强了:如问题所示，您可以手动进行操作.但是，您是正确的，在.gitattributes中使用合并驱动程序将不起作用.原因是当您执行运行git merge时，Git:

OK, can't is too strong: as you've shown in your question, you can do it manually. You're correct, though, that using a merge driver in .gitattributes won't work. The reason is that when you do run git merge, Git:

• 计算合并基础；
• 将基础中的配置文件与每个分支提示中的一个进行比较；和
• 如果文件仅在一个分支提示提交中有所不同，请使用该文件的分支提示提交版本.

• computes the merge base;
• compares the config file in the base against the one each branch-tip; and
• if the file is different in only one branch-tip commit, uses that branch-tip-commit version of the file.

如果您可以手动选择文件的合并基础版本，则可以避免三个输入文件中的两个匹配的情况，但是您不能这样做.

If you could pick the merge base version of the file manually, you could avoid situations in which two out of the three input files match, but you can't do that.

那么，您可以做什么 ?有几种类型的选项:

So, what can you do? There are several classes of options:

• 结帐后脚本；
• 过滤器驱动程序；
• Git本身之外的东西.

过滤器驱动程序的想法很吸引人，但它有一个可怕的缺陷:它在之前运行 Git告诉您提供给git checkout或git switch命令哪个分支名称.

The filter driver idea is attractive, but it has a terrible flaw: it runs before Git tells you which branch name was supplied to the git checkout or git switch command.

结帐后脚本方法 可以工作.但是，它确实导致了第三种方法:根本不要在Git中执行此操作.原因是您不想修改跟踪文件(位于Git索引/暂存区中的文件)，该文件以后会引起各种操作上的麻烦.

The post-checkout script method can work. However, it really leads to the third method: don't do it in Git at all. The reason is that you don't want to modify a tracked file (one that is in Git's index / staging-area), which produces all kinds of operational headaches later.

第三个方法是真正有效的方法. 使用未跟踪和忽略的文件，或完全不在Git存储库或启动指令之外的文件来保存配置.允许此文件或启动指令用于 include 其他如果愿意，可以 在Git中的文件，和/或从Git中的 文件构建此文件.如果有用的话，请让您的软件从Git中维护的文件中读取默认值.但是将实际配置保留在其他位置.

The third method is the one that really works. Use a file that is untracked and ignored, or is entirely outside the Git repository, or a startup directive, to hold the configuration. Allow this file or startup directive to include other files that are in Git, if you like, and/or build this file from files that are in Git. Have your software read defaults from files that are maintained in Git, if that's useful. But keep the actual configuration elsewhere.

现在，配置不在Git存储库中，您可以让Git管理存储库中 内的文件，而不会让Git破坏配置.

Now that the configuration is outside the Git repository, you can have Git manage the files that are in the repository, without having Git damage the configuration.

¹ 更准确地说，Git 是关于提交的.提交保留文件，但是Git与文件无关.分支 names 拥有提交哈希ID，但是Git也与分支名称无关.我们在这里关心的Git操作(签出和合并)，即在提交的基础上进行的工作，以及真实名称"提交的内容是其哈希ID.许多提交一次位于多个分支上，而某些提交有时根本不在任何分支上.在存在没有分支名称的提交的情况下，分支名称不能作为提交存在的基础.由于某些提交是多个分支的提示，并且提交内的存储文件是只读的，因此文件实际上不依赖于分支名称.分支名称可以更改，名称可以四处移动.提交后，这些提交将永久固定在适当的位置.

¹More precisely, Git is about commits. Commits hold files, but Git isn't about the files; branch names hold commit hash IDs, but Git isn't about the branch names either. The Git operations we care about here—checkout and merge, that is—work on a commit basis, and the "true name" of a commit is its hash ID. Many commits are on many branches all at once, and some commits are sometimes on no branch at all. With commits existing without branch names, a branch name cannot be the basis for the existence of a commit. With some commits being the tip of multiple branches, and the stored files inside a commit being read-only, the files literally cannot depend on the branch name. Branch names can be changed, and the names can be moved around. The commits, once made, are fixed in place forever.

最后，这里只是一个根本的不匹配.如果您认为Git是关于 commits (而不是分支或文件)的提交持有文件的提交，那么一切都会正常.如果您认为Git与分支有关，那么某些部分就不合适了.

In the end, there's just a fundamental mismatch here. If you think about Git as being about commits—rather than branches or files—with commits holding files, everything all works. If you think about Git as being about branches, some parts just don't fit.

这篇关于git如何在不同分支中保持配置文件不同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！