我有一个奇怪的情况，我可以通过其他方法解决，但我想进一步推动我对git的了解。
我认为图表是有序的。它看起来很疯狂，但我认为它实际上并不那么糟糕。我用方括号表示当前的分支。
upstream
/ \
/ \
/ \
starting point |
/ \ upstream
my OSX \ change (1)
config \ \
| my linux \
worked config more stuff
on A | upstream (2)
|\________ | |
| \| |
| Merge /|
| (OSX into Linux) / \
| | / \
changed worked / |
OSX conf on B / |
| ________/| ___/ [upstream]
|/ | /
| | /
| Merge (upstream
Merge B into Linux)
into OSX |
[OSX] worked
on C
|
worked
on D
[Linux]
所以基本上我们这里有7件＆＃34;工作＆＃34;我已经在概念上将其放入此图表中的各种提交中。标记为A至D的工作单位是实际的＆＃34; work＆＃34;我想使用git merge来通过我的[OSX]和[Linux]工作分支进行传播。
但是我想保持我的配置文件差异（在我的实际情况中这些包括makefile中的一些简单更改，但你也可以想象这是一组很大的配置文件差异）在他们自己的分支本地。
好的，我现在遇到的问题是我想将C和D合并到[OSX]中。但是，由于原因（不失一般性），上游更改（标记为1和2）我实际上想要远离[OS X]。
我想建立一个工作流程，我可以在我的分支机构之间任意切换（比如说我在办公室的Linux上工作，在咖啡店的OS X上工作，因为在咖啡店里SSH太不稳定了）。一个完全合适的解决方案就是，例如，将C和D挑选到[OSX]中，但我认为可以配置所有内容，以便我实际上只需将[Linux]合并到[OSX]中而无需引入上游我想要保留的东西。
我也想出了如何做到这一点。我可以继续进行合并，然后在上游变更（1）和（2）上进行git revert（实际上在功能上只是逆樱桃选择），然后在这一点上我可以自由前进。
所以我对此几乎感到高兴。我认为更强大的是，如果我能以某种方式＆＃34; pin＆＃34;上游＆＃34;上游＆＃34;提交，以便它自动不在（1）和（2）中合并。通过这种方式，它可以让我免于执行潜在的大量樱桃选择或恢复。
这可能吗？