GitHub級聯主分支更改而不覆寫客戶端自定義

我有一個保存在 Github 中的 Larave 專案。它的主要分支叫做core.

我有一個客戶需要對這個專案進行一些修改。所以我已經克隆了這個 repo 并為客戶設定了它。然后我為他做了一些改變。更改包括 - 一些額外的資料庫欄位、不同的發票格式和一些邏輯更改。

我們經常對core存盤庫進行錯誤修復和更改。如何在不覆寫我們為客戶所做的定制的情況下降低客戶專案的這些更改？

我看著分支和合并。但這不會被合并。由于我為客戶所做的更改不是暫時的。它是永久性的。我們將同時運行該專案的多個版本。但是當我們在核心中進行更新時。我們希望它向下級聯。我應該使用什么結構？

我試過了，Pull但它覆寫了我為客戶所做的事情。

uj5u.com熱心網友回復：

這不是——或者至少不應該是——關于 Git 的問題，而是關于如何構建自己的系統以支持可配置客戶端的問題。但是既然你問的是Git，那么讓我們看看 Git 對git merge. （此外，關于如何構建軟體的問題通常“太大”并且對 StackOverflow 來說沒有重點；考慮一下姊妹網站之一，例如SoftwareEngineering。）

請記住，git pull字面意思是：

1. 運行git fetch，然后
2. 默認情況下，運行第二個 Git 命令git merge。

第一個步驟- git fetch-obtains從其他一些Git倉庫新的提交：在這種情況下，錯誤修復和改變一些庫中，您控制或使用。第二個步驟，你可以選擇git rebase來代替git merge，但目標的第二個步驟是一樣的無論哪種方式，具有作為其目標，利用所獲得的新的提交第一步驟。我們通過結合作業來做到這一點。

該git merge命令是組合在多個不同的提交字串中完成的作業的主要方式。git rebase相反，該命令會重復挑選現有的提交，目的是“改進”每個提交；每個cherry-pick都是一種特殊的merge形式，所以最后你還是要理解merging。因此，此時正確的介紹是合并。如果您還不太熟悉 Git 提交是什么以及為您做了什么，那么您現在應該去閱讀它。

現在，鑒于我們有一些構成圖表的提交集，我們可以很容易地進入這樣的情況：

          I--J   <-- branch1 (HEAD)
         /
...--G--H
         \
          K--L   <-- branch2

也就是說，我們branch1使用 commit “on” branch J。其他人向我們提供了我們K-L現在使用名稱branch2（或者可能是origin/branch2，但branch2為了簡單起見我畫了這個）的提交。

雖然每個提交都有每個檔案的完整快照，但兩個分支顯然會在 commit 處收斂H。也就是說，當我們從當前最新的 commit 開始向后作業時J，我們會逐步 commit I， then H， then G，依此類推。同時，如果我們從他們最近一次提交的時間向后作業L，我們將逐步提交K，然后H，然后G，等等。這意味著提交H是共享的——它在兩個分支上，連同它的所有祖先——我們可以很容易地選擇它作為最好的共享提交，因為根據定義它是最新的共享提交（所有其他共享提交必須早于H）。

Git 的合并操作將使用由提交的存在形成的提交圖自動找到提交（HGit 稱之為合并基礎）。我們所要做的就是告訴 Git：

• 查看我們當前的提交H；
• 看看提交L；
• 找到合并基地，并開始合并程序。

我們通過運行git merge branch2or 來做到這一點。任何允許 Git 定位提交的東西在這里就足夠了：我們不必使用分支名稱。我們通常做的使用分支的名字，因為這是最簡單的我們，但所有的Git需要的是找到一種方法：它的作品了，其余自身。git merge hash-of-LLL

Git 如何執行合并操作

找到合并基礎提交后H，Git 現在已準備好執行合并操作。這包括：

• 將每個檔案與H中的每個檔案進行比較J，以查看我們在每個檔案中所做的更改（如果有的話）；
• 將每個檔案與H中的每個檔案進行比較L，以查看它們在每個檔案中所做的更改（如果有的話）；
• 當 Git 處理它時，它會弄清楚我們是否重命名、添加或洗掉了任何整個檔案，對它們也是如此。通常所有三個提交都具有相同的檔案集，因此這種額外的皺紋不會引起任何胃灼熱，對于這個特定的答案，我們將忽略這種可能性。

對于許多合并中的許多檔案，沒有人改變任何東西。這使得合并檔案變得微不足道：三個提交中的三個版本中的任何一個都可以，因為所有三個版本都是相同的。（Git 的自動檔案重復資料洗掉在這里非常方便：Git 立即知道檔案是否在兩個或三個提交中重復。）

對于許多合并中的其他檔案，要么我們更改了某些內容，要么他們更改了某些內容，但是如果我們更改了某些內容，它們不會觸及該檔案，反之亦然。同樣，這使得合并該檔案變得微不足道：Git 只需要采用任何一個更改的. 但是，我們可以將其視為第三種也是最復雜的情??況的特例。

Last, we have the third and most complicated case: both we and they made changes to the same file. What Git does for this case is straightforward and not clever at all: Git simply combines the changes. If we deleted line 3 and they didn't do anything to line 3, Git will delete line 3. If they added a line between lines 10 and 11 and we didn't, Git will take their added line. Git repeats this process for every modification—line by line, because Git's internal git diff works on a line-by-line basis.¹ As long as the changes we make to some line(s) do not touch or overlap the changes they make to other line(s), Git is able to do this line-by-line work by itself, and does so.

If Git is able to resolve all files on its own, Git will normally go on to make a new merge commit on its own as well. A merge commit is the same as any other commit: it has a unique hash ID and contains a snapshot—a copy of every file, as of the form it should have when extracted later—and some metadata. The only thing special about a merge commit is that instead of one parent commit hash ID, the metadata list of parent commits lists two parents.² We can draw that here as:

          I--J
         /    \
...--G--H      M   <-- branch1 (HEAD)
         \    /
          K--L   <-- branch2

Note that, as usual, the current branch—branch1—now points to the new commit, and the new commit M points back to the commit you were on a moment ago, commit J, as usual. What's different about M is that it has a second parent L, indicating that this commit joins two histories: one that results from starting at J and working backwards, and one that result from starting at L and working backwards.

¹Note that this means that Git is utterly unable to combine changes to binary files. If you have a conflict in a binary file, Git will refuse to help you out here.

²Technically, this is two or more, with "more" producing what Git calls an octopus merge. Octopus merges don't do anything you cannot do with ordinary merges. (In fact, except for joining up multiple branches, they do less than you can do with an ordinary merge, which is their ultimate value proposition: if you see an octopus merge in a Git history, you know that, despite the many inputs, the merge itself was simple—or as simple as it could be based on the number of inputs.)

Merge conflicts

Sometimes we and they make different changes to the same line. For instance, a line might read:

the red ball

in some file in the merge base commit H. We change this to:

the blue ball

but they change it to:

the red cube

Git has no idea how to combine these two changes. If the result should be "the blue cube", you will have to make that change yourself. Git also declares a conflict if we change two lines that "touch", even though in some cases this might not be necessary. This is based on years of experience with merge algorithms: this seems to produce the result most humans find the most pleasing, or at least, has done so historically.

In any case, Git will now take the combined changes—plus any conflicts—and apply the combined changes to the file from the merge base. That way, Git keeps our changes and adds theirs, or, depending on your point of view, keeps their changes and adds ours. (The result is the same either way.) If Git encountered nothing it declared as a merge conflict, it goes on to arrange for the combined-changes file to go into the next commit. Otherwise, Git leaves behind a mess:

• Git's index (see this answer for more about the index AKA staging area) will contain all three versions of the file, from the merge base, the HEAD or --ours commit, and the other or --theirs commit;
• the working tree copy of the file will contain Git's best effort at combining the changes, including conflict markers.

Your job is to come up with the correct combined file—you can do this in any way that pleases you—and then to adjust Git's index to hold the correct copy of the file. Git doesn't need the working tree copy at all, but git add tells Git: make the index version of the file match the working tree version, with the side effect of deleting from the index the extra versions that prevent committing. Most people thus mostly find it easiest to fix up the working tree copy and then run git add, or to use git mergetool, which is a command that:

1. runs some tool of your choice to do the "fix up working tree file" step, then
2. runs git add for you.

Note that this is really all that git mergetool does, so git mergetool does not add a lot of value. However, the process of extracting all three input files—merge base, --ours, and --theirs—is a bit tedious, and before git mergetool runs your choice of merge tool (vimdiff, kdiff3, Beyond Compare, or whatever else you may like), it automates this part of the job.

Once we've resolved all conflicts, we tell Git to finish the merge, by running either git merge --continue or git commit. Git then goes on to make merge commit M as usual.

Conclusion for real merges

In any case, we now have a complete overview of what git merge does for the case where we start with:

          I--J   <-- branch1 (HEAD)
         /
...--G--H
         \
          K--L   <-- branch2

Git will use HEAD to locate commit J, the argument to git merge to locate commit L, and the commit graph to locate the merge base commit H. Git will then diff the snapshot in H against those in J and L as needed to find changes, combine the changes, and apply the combined changes to the files from the merge base H. If the combining goes smoothly, Git will make the resulting merge commit M on its own. If not, Git will stop in the middle of the merge, force us to finish the merge—we cannot proceed without either finishing or aborting the merge, due to the messed-up state of Git's index³—and when we do finish the merge we get the same merge commit M, this time with human intervention.

³This is a real problem. There is no proper way to deliver a partial merge to someone else, making collaborative merging difficult. Fortunately, with most smaller merges, one person can do the job.

A special case

As a special case, consider what happens if we're in the following situation:

...--G--H   <-- branch1 (HEAD)
         \
          I--J   <-- branch2

Suppose we now run git merge branch2. If Git were to follow the usual rules for merges, it would:

• locate commits H and J as ours and theirs;
• locate the common merge base, which is commit H again;
• diff H vs H to see what we changed;
• diff H vs J to see what they changed;
• combine these changes; and
• make a new merge commit.

The result would look like this:

...--G--H------M   <-- branch1 (HEAD)
         \    /
          I--J   <-- branch2

where I've used the letter M again to stand for "merge". But: what's in the snapshot in commit M? We had Git diff commit H vs commit H to see what we changed, and by definition, if we compare H against it self, nothing changed. So Git combines our "nothing" with whatever they did—presumably, something—and the resulting files necessarily exactly match all the files in commit L.

One might legitimately wonder: Why bother? And in fact, by default, git merge does not bother. It detects that commit H is commit H and that there's therefore nothing of ours to carry forward. Instead of merging, Git does a fast-forward operation (which git merge chooses, rather cheekily, to call a "fast-forward merge" even though nothing is merged). Instead of merging, then, Git just drags the branch name branch1 "forward", like this:

...--G--H
         \
          I--J   <-- branch1 (HEAD), branch2

There's no need for the kink in the drawing any more, so we can draw this graph like this now:

...--G--H--I--J   <-- branch1 (HEAD), branch2

The fast-forward non-merge "merge" is now complete, by virtue of simply making both branch names point to commit J.

Sometimes there is nothing to do

Suppose that we have a graph that looks like this:

...--G--H   <-- branch2
         \
          I--J   <-- branch1 (HEAD)

That is, this is like the fast-forward case, except we're on the later commit J, rather than the earlier commit H. If we run git merge branch2 now, Git will say "already up to date" and quit. There's literally nothing to do: commit H is already part of our history at commit J.

These two special cases work by finding the merge base as usual: if the merge base is one of the two end-point commits, we have a special case. The special case is either "nothing to do" (the merge base is the other commit) or "fast-forward" (the merge base is not the other commit, but is our commit). So Git will always find the merge base.

The last special case

There's a final special case, which with any luck you will never encounter. Suppose we have a graph like this one:

...--o--A---M1--o--L   <-- branch1 (HEAD)
         \ /
          X
         / \
...--o--B---M2--o--R   <-- branch2

where o represents a commit (or any number of commits) that aren't interesting, and the two M commits are two merges whose input commits are A and B (plus some merge base, not shown here, that Git found automatically).

如果我們git merge branch2現在運行將Land 中的作業結合起來R，則提交A和B都是“同樣好的”提交作為合并基礎候選者。兩個提交都在兩個分支上，并且沒有一個“離終點更遠”（如果我們使用通常的最低公共祖先演算法，兩個提交哈希 ID 都會以未確定的順序從中出來）。

Git 有多種方法來處理這個問題，但 Git-2.34 之前的默認策略是合并合并基礎A并B產生臨時提交，然后使用臨時提交作為合并基礎來合并L和R. 在 Git 2.34 中，一種新演算法嘗試做與合并遞回相同的事情，但沒有那么多瘋狂和浪費精力。⁴ 我自己還沒有研究過新演算法，因此不會在這里嘗試解釋它。

⁴ “正常”的非遞回合并主要發生在 Git 的索引中，作業樹檔案偶爾用于臨時存盤。2.34 之前的merge-recursive代碼使用相同的方法執行每個內部合并，merge-recursive code并從結果中逐個提交（或至少是一個樹物件），如果需要，添加到包含沖突標記的索引檔案中。這為“外部”合并提供了適當的合并基礎，但意味著合并沖突向前傳播，這意味著像 GitHub 這樣的網站不能使用此代碼。新merge-ort代碼在記憶體和 Git 的索引中進行了整個合并，而不使用臨時檔案，而且——據我所知——也直接處理遞回，

標籤：

上一篇：如何重寫Rebase檔案內容以更改多個提交

下一篇：解決合并中的所有索引/作業樹沖突后，`gitcommit`和`gitmerge--continue`之間的區別？