從 Git 中的遠端倉庫分支中提取更改時重新設定本地分支

本教程將介紹從 Git 中的遠端倉庫分支中拉取更改時重新設定本地分支的基礎。

我們使用版本控制系統 Git 來跟蹤對檔案所做的更改。我們在本地倉庫的本地分支中提交更改。此本地分支與遠端倉庫的遠端分支相關聯。

有時，我們會將遠端倉庫的更改與本地倉庫中的更改同步。我們將遠端分支的更改拉入本地分支。

當我們拉入遠端分支更改時，我們可以重新設定本地分支（即）以在已釋出的更改之上重新應用未釋出的更改。

我們現在將用一個例子來說明這一點。

從 Git 中的遠端倉庫分支拉取時，使用 git pull --rebase 對本地分支進行 Rebase

在協作開發環境中，我們使用 Git 在本地系統的本地倉庫中建立分支。我們將此本地分支與遠端倉庫中的遠端分支相關聯。

我們暫存並提交對本地分支中的檔案所做的更改。然後我們將這些更改釋出到遠端倉庫中的遠端分支。

然後，團隊的其他成員也使用相同的倉庫，將已釋出的更改拉入其系統的本地分支中。

因此，我們定期執行將本地更改推送到遠端倉庫並從遠端倉庫拉入已釋出更改的過程。

當將遠端分支的已釋出更改拉入我們的本地分支時，我們可以選擇進行合併或進行變基。

在合併的情況下，我們使用命令 git pull --merge，這是預設選項。當我們在合併案例中拉入遠端倉庫更改時，本地更改將與遠端更改合併。

建立合併提交以指向最新的本地和遠端提交。

在變基的情況下，我們使用命令 git pull --rebase。在 rebase 中，本地分支的未釋出的本地更改被重新應用到遠端倉庫的已釋出更改之上。

在 rebase 的情況下，不會建立新的提交。

假設我們在本地倉庫中有一個名為 feature 的分支，它與遠端倉庫中同名的遠端分支相關聯。

團隊中的每個開發人員都將在其本地系統中擁有 feature 本地分支。

假設一位開發人員已對本地分支 feature 提交了一些更改。

現在，假設其他開發人員已經發布了對遠端倉庫的遠端分支 feature 的一些更改。

因此，現在分支的情況如下圖所示。

              P---Q---R feature (local branch)
             /
A---B---C---D---E---G feature (remote branch)

如上圖所示，我們現在有一個分叉的歷史。我們需要將遠端分支的更改拉入本地分支以獲取已釋出的更改。

假設遠端分支 feature 中的新提交與本地分支中的提交相關（通常是這種情況）。因此，在這種情況下進行拉取時，我們會進行變基而不是合併。

我們需要執行帶有 --rebase 選項的 git pull 命令來執行 rebase。該命令的語法是 git pull --rebase <remote-repository> <remote-branch-name>。

因此，在我們的例子中，要重新定位我們的本地分支 feature，我們將執行以下操作。

$ git pull --rebase origin feature

因此，執行上述 git pull 命令後，分支如下圖所示。

                      P---Q---R feature (local branch)
                     /
A---B---C---D---E---G feature (remote branch)

因此，如圖所示，本地分支 feature 的所有未釋出提交都移動到遠端分支 feature 更改的尖端。不會建立新的提交。

rebase 選項的主要優點是專案歷史比使用合併選項更清晰。

此外，如上圖所示，我們獲得了線性專案歷史記錄。沒有分叉。使用 git log 命令可以輕鬆瀏覽專案的歷史記錄。

因此，我們已經詳細說明了在從 Git 中的遠端倉庫中提取更改時重新定位本地分支。

欲瞭解更多資訊，請訪問 -

1. git-pull
2. 合併與變基