我曾经在一些文件上使用 git update-index --assume-unchanged
命令,以防止它们的更改被提交。
在存储库中使用 git stash
时,这些更改会与其他未完成的更改一起被暂存。这是预期的行为,但是 git stash pop
不会将它们带回来,因此更改就会丢失。
有谁知道如何防止带有 assume unchanged
标记的文件出现在暂存区?另外,也许您知道如何确保针对这些文件进行的任何更改至少被带回来?
我曾经在一些文件上使用 git update-index --assume-unchanged
命令,以防止它们的更改被提交。
在存储库中使用 git stash
时,这些更改会与其他未完成的更改一起被暂存。这是预期的行为,但是 git stash pop
不会将它们带回来,因此更改就会丢失。
有谁知道如何防止带有 assume unchanged
标记的文件出现在暂存区?另外,也许您知道如何确保针对这些文件进行的任何更改至少被带回来?
assume-unchanged是一种性能优化,代表你承诺该文件未发生更改。如果你实际上更改了文件,则不能保证其正确性。你应该重新设计您的仓库,不要提交这些文件(可以提交filename.sample和.gitignore filename),或通过分支操作使你不想与世界分享的文件处于另一个分支或其他隐藏状态。
关于如何隐藏这些更改,我见过/想到了四个建议:
1:使用smudge/clean过滤器在检出时将文件更改为所需的内容,并在签入时清除(比较丑陋)。
2:根据http://thomasrast.ch/git/local-config.html中的描述创建本地配置分支。关键是要记住,你需要在主分支上进行开发,并在配置分支上进行合并以进行测试。然后返回主分支以进行更改、推送等操作。
3:创建私有开发分支,进行永远不希望分享的更改,然后进行虚假合并(git merge -s ours privatebranch)。然后你可以在私有分支上开发和测试,并且你不想分享的更改不会在合并回来时出现,只要该更改与你的正常工作相隔甚远。但是,当你从上游获取新的更改时,你需要将它们直接从上游拉到私有分支。然后你需要将私有分支合并回主分支,并从主分支推送到上游。你绝不能将主分支合并回私有分支。同样,你也不能进行变基(可能rebase -p能够成功,但不保证)。这些合并/变基以及必须出现在哪里使得这种方法不太吸引人。
4:创建私有开发分支,进行永远不希望分享的更改,然后创建合并驱动程序(参见man gitattributes),该驱动程序将拒绝将文件从主分支合并到私有分支或从私有分支合并到主分支(可能通过比较私有分支上文件的SHA值和其他分支上文件的SHA值并复制之前的值,如果匹配则拒绝合并)。
-s ours
。但是当我将主分支合并到私有分支时,它覆盖了我的更改。 - Casebashgit checkout HEAD^ -- myfile
获取旧版本并再次使用 merge -s ours
。-s ours的目的是防止来自private的更改进入main。除非该文件在单个提交中被更改,否则无法阻止来自main的新更改进入private。 - Seth Robertson这个问题类似于在分支切换之间保留git --assume-unchanged文件。我曾经提出使用一个包含这些更改的私有分支,这里我详细介绍了http://blog.ericwoodruff.me/2013/02/git-private-branch-pattern.html。