How do I update a GitHub forked repository? 同步分出來的分支

我的英文和理解力都超低,所以我覺得學git 好難哦!看半天都懂不懂 Q_Q;我還是努力地研究一下,我預計,這些暫時學到的東西,過三天應該就會都忘光光了!所以特地寫一篇筆記,幫助下次能快點回神。

故事開始於有一天我 fork(分支) 了別人 github 上的project,但 fork 出來之後更新就中斷了,我改我的,別人改別人的。我 fork 的 project:
https://github.com/haiwen/seadroid

我在自己fork的project 修改了一些地方,原作者則是改了「很多地方」,要 merge 是大工程!! 但是神奇的 git 居然一行指令就搞定,真的很酷。

下面的文章,我看了,但不知道為什麼有人是用 git merge, 有人是 git pull –rebase upstream master,我覺得太難懂了,就略過,假裝沒看到,先挑一個試試看。


依照這篇文章最下面附的相關文章,我先用下面這個命令來加入遠端的 repository,在這邊的情境也就是比較新的、上游的 repository

git remote add upstream https://github.com/haiwen/seadroid.git

下完後,沒有任何反應,但是用 git remote -v 可以看到剛才加入的 upstream

附註:upstream 是 remote name、可以自己取名,不要重複就好,這次是用 upstream 做示範.

接著下:

git fetch upstream

回的結果:

  • remote: Counting objects: 132, done.
  • remote: Compressing objects: 100% (10/10), done.
  • remote: Total 132 (delta 62), reused 62 (delta 62), pack-reused 57
  • Receiving objects: 100% (132/132), 29.86 KiB | 0 bytes/s, done.
  • Resolving deltas: 100% (63/63), completed with 29 local objects.
  • From https://github.com/haiwen/seadroid
  • * [new branch]      contacts                -> upstream/contacts
  • * [new branch]      dev2                    -> upstream/dev2
  • * [new branch]      develop                 -> upstream/develop
  • * [new branch]      feature/document_provider -> upstream/feature/document_provider
  • * [new branch]      feature/support_client_side_encryption2 -> upstream/feature/support_client_side_encryption2
  • * [new branch]      fix_photo_gallery_crash -> upstream/fix_photo_gallery_crash
  • * [new branch]      hb                      -> upstream/hb
  • * [new branch]      horizon_base            -> upstream/horizon_base
  • * [new branch]      master                  -> upstream/master
  • * [new branch]      maven                   -> upstream/maven
  • * [new branch]      mxh_seafile             -> upstream/mxh_seafile
  • * [new branch]      titatium_backup         -> upstream/titatium_backup

再下指令:

git checkout master

說明:因為要更新的 branch 是 master,所以我就先切到 master branch.

 

再下合併指令:

git merge upstream/master

回傳結果:

Merge made by the ‘recursive’ strategy.
app/build.gradle | 16 +–
app/src/main/AndroidManifest.xml | 19 +–
…/java/com/seafile/seadroid2/SeafConnection.java | 129 +++++++++++———-
…/java/com/seafile/seadroid2/data/DataManager.java | 15 ++-
…/seadroid2/data/StorageManagerLollipop.java | 9 +-
…/seadroid2/ui/activity/AccountsActivity.java | 18 ++-
…/seadroid2/ui/activity/BrowserActivity.java | 2 +
…/ui/activity/CreateGesturePasswordActivity.java | 10 +-
…/seadroid2/ui/activity/SettingsActivity.java | 3 –
…/ui/activity/UnlockGesturePasswordActivity.java | 6 +-
…/ui/adapter/SeafItemCheckableAdapter.java | 15 ++-
…/seadroid2/ui/fragment/SettingsFragment.java | 8 ++
app/src/main/res/values/styles.xml | 5 +
13 files changed, 151 insertions(+), 104 deletions(-)

執行的結果的截圖:

附註:在下這個指令時,會進入 vi 的執行畫面,要求我打一些字,幫這次的 merge 留下一些註解,我就輸入 update from original,然後按 ESC , :wq.

這個 merge 是 local 的 merge 還需要使用 push 才會推到 github server 上。

最後一個指令:

git push

回傳結果:

Counting objects: 143, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (63/63), done.
Writing objects: 100% (143/143), 14.78 KiB | 0 bytes/s, done.
Total 143 (delta 78), reused 116 (delta 53)
remote: Resolving deltas: 100% (78/78), completed with 26 local objects.
To https://github.com/max32002/seadroid.git
21fe5b3..ff45589 master -> master


完全不下指令,在github 上操作的「懶人解法」,我覺得反而比較難,因為都馬看不懂 Q_Q;

To update a fork directly from GitHub. This still works, BUT it will lead to a dirty commit history.

  1. Open your fork on GitHub.
  2. Click on Pull Requests.
  3. Click on New Pull Request. By default, GitHub will compare the original with your fork, and there shouldn’t be anything to compare if you didn’t make any changes.
  4. Click switching the base if you see that link. Otherwise, manually set the base fork drop down to your fork, and the head fork to the upstream. Now GitHub will compare your fork with the original, and you should see all the latest changes. enter image description here
  5. Create pull request and assign a predictable name to your pull request (e.g., Update from original).
  6. Scroll down to Merge pull request, but don’t click anything yet.

Now you have three options, but each will lead to a less-than-clean commit history.

  1. The default will create an ugly merge commit.
  2. If you click the dropdown and choose “Squash and merge", all intervening commits will be squashed into one. This is most often something you don’t want.
  3. If you click Rebase and merge, all commits will be made “with" you, the original PRs will link to your PR, and GitHub will display This branch is X commits ahead, Y commits behind <original fork>.

So yes, you can keep your repo updated with its upstream using the GitHub web UI, but doing so will sully your commit history. Stick to the command line instead – it’s easy.

 


相關文章:

如何同步 Github fork 出来的分支
http://jinlong.github.io/2015/10/12/syncing-a-fork/

更新從 GitHub 上 fork 出來的 repository
(或是同步兩個不同 server 端的 repository)
https://www.peterdavehello.org/2014/02/update_forked_repository/

How do I update a GitHub forked repository?
http://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository

連猴子都能懂的Git入門指南
https://backlogtool.com/git-guide/tw/
OH My God, 連猴子都比我厲害。

相關文章

新增留言