所以，我有一个web项目，主机url是硬编码的，我想继续只更新一个分支，并且能够获得两个不同版本的代码，一个用于生产（服务器域），一个用于测试（localhost）。
我知道可能有很多方法以编程方式，甚至使用配置文件或脚本来完成。但我想知道是否可以用git来完成。
所以例如。
master-> commit 1 -> commit 2 ..... -> HEAD
localhost/branch -> commit x (where url is different) -> ... -> master head
所以在这种情况下，localhost / branch在提交2之后被检出master并添加了commit x然后跟踪master的HEAD，所以每次提交master都将通过fastforwarding更新localhost / branch。
有类似的东西吗？
答案 0 :(得分：2)
简答：不。
快进实际上是一个标签移动的东西，并且以＆＃34;是祖先＆＃34;为条件。 property：从提交C old 移动到C new 的标签以快进方式移动当且仅当C old 是C new 的祖先（请注意，身份移动，即当两个提交ID相等时，可以被认为是快进，或者可以简单地完全忽略，因为它实际上并不是移动）。
实际上，由于提交ID的哈希包含其所有自己的祖先ID，如果您的＆＃34;提交x在分支localhost/branch＆＃34;在分支master的提示提交的祖先中不，然后添加到分支master的任何新提交都不能成为提交x的后代，直到提交x本身已合并。此时您必须保持配置更改（以便master具有您不所需的配置更改）或放弃您的配置更改（以便master根据您的意愿而有所不同）。显然，您将选择后者，但这意味着，如果您将标签localhost/branch移动到指向与标签master相同的提交，那么localhost/branch也将不< / em>包含此配置更改。
更简洁地说，为了合并分支，您将放弃x中所做的更改，并且您必须合并分支为了使用快进标签移动。
顺便说一下，如果正确绘制提交链，这可能会更有意义。它们总是向后指向，而不是向前，标签指向最新：
C1 <- C2 ... <- C8 <-- HEAD=master
\
Cx <-- localhost/branch
这里的所有箭头都指向左侧（或Cx的情况下左右）。
现在，如果您向C9添加新的提交master（由HEAD指向）：
C1 <- C2 ... <- C8 <- C9 <-- HEAD=master
\
Cx <-- localhost/branch
请注意，Cx仍然不在master的历史记录链中，现在从C9开始并返回C1并停止，但不包括Cx。
你可以（强行）更改localhost/branch以直接指向C9，但如果这样做，它也不再包含Cx。
如果您希望维护此类事情，您需要做的是创建一个新的合并提交（或随着时间的推移，尽可能多次）将master分支提交拼接到localhost/branch提交中：
C1 <- C2 ... <- C8 <-- HEAD=master
\ ... \
Cx ... C8x <-- localhost/branch
然后：
C1 <- C2 ... <- C8 <- C9 <-- HEAD=master
\ ... \ \
Cx ... C8x <- C9x <-- localhost/branch
请注意，提交C8x和C9x不在分支master上（从C9开始向后工作，我们找不到它们）但是是 on localhost/branch。请注意，将C9合并到localhost/branch（创建C9x）将应用自上一次合并（C8创建C8x）以来的更改，因为＆＃34 ;合并基地＆＃34; （最早的共同祖先）是提交C8，自C8以来唯一的更改是C9中的更改。
真正理解git的一个关键是理解合并 C9到localhost/branch与 cherry-picking C9的区别localhost/branch。两者都会使用工作树执行完全相同的操作 - 都会查找从C8到C9的增量并将其应用于C8x - 但合并记录这在新提交的历史记录中，通过给它两个父提交ID，而cherry-pick不提供（新提交只有一个父提交ID）。
（如果这没有意义，请不要担心。:-)如果确实有意义，恭喜你，你真的知道git是如何工作的。）