【Github】refusing to merge unrelated histories
更新於 發佈於 閱讀時間約 2 分鐘
這是剛剛才發生的事，新鮮出爐
在完成短網址產生器的作業後，正準備將檔案上傳 Github
建立了新的 respository ，就像之前練習開新分支和合併一樣，按下了 merge 以後……
建立了新的 respository ，就像之前練習開新分支和合併一樣，按下了 merge 以後……
等愣！跳出了錯誤訊息：
refusing to merge unrelated histories
在驚恐之餘，趕緊搜尋了這個訊息
裡面提到的方式是直接設定成允許合併
但能用圖形化介面處理的事情就先不用命令（ｘ）
但能用圖形化介面處理的事情就先不用命令（ｘ）
我注意到網頁中一個相關連結上的「rebase」
這個指令在我使用 sourcetree 的時候就有看到，就在 merge 旁邊
這個指令在我使用 sourcetree 的時候就有看到，就在 merge 旁邊
於是我動手開始查這兩個指令的差異
簡單的列出差異點如下：
＊Merge
1. 在主分支上對副分支執行，將副分支合併進來
2. 不影響歷史紀錄
3. 會建立一個新的 commit 用來 merge
1. 在主分支上對副分支執行，將副分支合併進來
2. 不影響歷史紀錄
3. 會建立一個新的 commit 用來 merge
＊Rebase
1. 在副分支上對主分支執行，副分支將會接到主分支後面
2. 會更動歷史紀錄（commit的時間等）
3. 不會建立用來 rebase 的 commit
副分支會複製一份新的 commit(SHA-1值不同) 接到主分支後面
1. 在副分支上對主分支執行，副分支將會接到主分支後面
2. 會更動歷史紀錄（commit的時間等）
3. 不會建立用來 rebase 的 commit
副分支會複製一份新的 commit(SHA-1值不同) 接到主分支後面
考量到將以 Github 的分支為主
我嘗試了在本機端的分支對來自 Github 的分支執行 rebase
我嘗試了在本機端的分支對來自 Github 的分支執行 rebase
伴隨著進度條完成，畫面上的 commit 變為同一條分支
而我原先本機端參差不一的 commit 建立日期瞬間全部變得一模一樣
而我原先本機端參差不一的 commit 建立日期瞬間全部變得一模一樣
雖然 commit 依然按照先前的順序一個不少的在上面，但心中有種什麼不見了的感覺……（是歷史紀錄）
為了寫這篇文章，我又重新回去翻了遍參考連結
裡面有提到 rebase 的主副誰先誰後，以最後的檔案來說沒什麼差別
裡面有提到 rebase 的主副誰先誰後，以最後的檔案來說沒什麼差別
那如果我以 Github 的分支，對本機端的分支執行 rebase 呢……？
按照參考連結的內容，我試著 reset 回還沒 rebase 的 commit 上
但是本機端的 commit 的 date 並沒有改變，看來是回不去了(?)
但是本機端的 commit 的 date 並沒有改變，看來是回不去了(?)
之後有機會再試試看用新分支 rebase 本機的分支好了
0會員
1內容數
留言0
查看全部
你可能也想看
Google News 追蹤
提問的內容越是清晰，強者、聰明人越能在短時間內做判斷、給出精準的建議，他們會對你產生「好印象」，認定你是「積極」的人，有機會、好人脈會不自覺地想引薦給你
今天在解衝突的時候，同事提到了做merge指令時跟在Gitlab上提交merge request的時候是情況是相反的，我想他或許也沒探究過原因。
曾經我也很疑惑為什麼大家都是說發PR，但是越想越不對勁：
PR的P指的是pull，為什麼是用拉pull而不是用推push？
改稿真的不是一件需要太多情緒的事，把錯的挑出來、改掉，就這麼簡單！很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的，這一版居然是錯的」的鬼故事，把問題找出來解決就好！
更新專案的指令有： 01 `git fetch` 來對專案做「更新 Update」。 02 `git push` 來分享你對專案的「變更 Change」[3]。 03 `git remote` 來管理遠端的儲存庫。 有趣的是，fetch 這個字源於古英語的"fetan"， 表示拿來，取回來的意思。
分支與合併 Branching and Merging[1] 。 這裡提供一個很有趣的說法， 就是理解「分支 Branching」最好的方式， 就是把它理解成「上下文 Context」。
本篇文章介紹如何使用Git Bash進行版本控制操作，包括創建repository、查看狀態、歷程以及加入暫存和提交暫存等操作。透過基本的Git指令，您可以更深入地瞭解Git工具的使用方法。
※ 需要做版本備份時：
git init：初始化此資料夾，由git 開始追蹤版本控制。
git add：將檔案加入到暫存區。
git commit：把暫存區的內容提交到儲存庫。
git status：查看目前所有檔案的狀態。
git log：查看過去所有commit的記錄。
※ 需要做修
※ 簡短說明Git 和 Git Flow 是什麼？如何應用？
Git 是什麼？
Git是一個分散式版本控制軟體，能夠紀錄檔案的狀態變化，以及協調多個開發者之間的工作。它允許團隊成員協作編輯和管理項目的代碼庫，並且能夠追蹤文件的歷史變更、恢復到以前的版本、合併不同版本的代碼，以及解決代碼衝突等。
最近在找資料的時候，偶然發現了兩個有趣的 git 指令：git commit --fixup 和 git rebase -i <sha> --autosquash。
研究了下發現對於像我這種每次 commit 都要斤斤計較，盡可能完美的人來說非常好用，因此寫一篇筆記記錄一下用法。
※ 關於Git (二)
請寫下從 Github 上複製一個專案下來，做一次遞交，然後推上去會用到的所有 git 指令。
複製專案（Clone） markdown-here：
git clone https://github.com/adam-p/markdown-here.git
如果在訊息
提問的內容越是清晰，強者、聰明人越能在短時間內做判斷、給出精準的建議，他們會對你產生「好印象」，認定你是「積極」的人，有機會、好人脈會不自覺地想引薦給你
今天在解衝突的時候，同事提到了做merge指令時跟在Gitlab上提交merge request的時候是情況是相反的，我想他或許也沒探究過原因。
曾經我也很疑惑為什麼大家都是說發PR，但是越想越不對勁：
PR的P指的是pull，為什麼是用拉pull而不是用推push？
改稿真的不是一件需要太多情緒的事，把錯的挑出來、改掉，就這麼簡單！很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的，這一版居然是錯的」的鬼故事，把問題找出來解決就好！
更新專案的指令有： 01 `git fetch` 來對專案做「更新 Update」。 02 `git push` 來分享你對專案的「變更 Change」[3]。 03 `git remote` 來管理遠端的儲存庫。 有趣的是，fetch 這個字源於古英語的"fetan"， 表示拿來，取回來的意思。
分支與合併 Branching and Merging[1] 。 這裡提供一個很有趣的說法， 就是理解「分支 Branching」最好的方式， 就是把它理解成「上下文 Context」。
本篇文章介紹如何使用Git Bash進行版本控制操作，包括創建repository、查看狀態、歷程以及加入暫存和提交暫存等操作。透過基本的Git指令，您可以更深入地瞭解Git工具的使用方法。
※ 需要做版本備份時：
git init：初始化此資料夾，由git 開始追蹤版本控制。
git add：將檔案加入到暫存區。
git commit：把暫存區的內容提交到儲存庫。
git status：查看目前所有檔案的狀態。
git log：查看過去所有commit的記錄。
※ 需要做修
※ 簡短說明Git 和 Git Flow 是什麼？如何應用？
Git 是什麼？
Git是一個分散式版本控制軟體，能夠紀錄檔案的狀態變化，以及協調多個開發者之間的工作。它允許團隊成員協作編輯和管理項目的代碼庫，並且能夠追蹤文件的歷史變更、恢復到以前的版本、合併不同版本的代碼，以及解決代碼衝突等。
最近在找資料的時候，偶然發現了兩個有趣的 git 指令：git commit --fixup 和 git rebase -i <sha> --autosquash。
研究了下發現對於像我這種每次 commit 都要斤斤計較，盡可能完美的人來說非常好用，因此寫一篇筆記記錄一下用法。
※ 關於Git (二)
請寫下從 Github 上複製一個專案下來，做一次遞交，然後推上去會用到的所有 git 指令。
複製專案（Clone） markdown-here：
git clone https://github.com/adam-p/markdown-here.git
如果在訊息