文章目錄

• 第一階段：註冊設定階段
• 問題一：在使用git時配置的全域性郵件和使用者名稱作為區分使用者，如何區分
• 第二階段：使用問題階段
• 問題一：如何對專案作出貢獻步驟
• 操作步驟：
• 補充
• 問題一：pull request提交過於遲緩，導致原專案與提交的專案發生了衝突，此時應該如何辦？
• 解決方法：
• 操作步驟：
• 步驟一：將原專案作為一個上游庫
• 步驟二：fetch 原專案庫分支（主要區別不是預設分支）
• 步驟三：將分支merge掉
• 步驟四：解決衝突
• 步驟五：在此提交and push
• 步驟六：開啟github看見新的提交
• 步驟七：重新拉去pull request的檔案，此時沒有conflict問題
• 自此，問題解決。

第一階段：註冊設定階段

問題一：在使用git時配置的全域性郵件和使用者名稱作為區分使用者，如何區分

關鍵字：區分使用者，使用者識別。
GitHub 使用使用者郵件地址區分 Git 提交。 如果你在自己的提交中使用了多個郵件地址，希望 GitHub可以正確地將它們連線起來

作用：這樣所有的郵箱會體現是一個使用者的操作。( 當 GitHub 發現任意版本庫中的任意提交資訊包含了這些地址，它就會將其連結到你的賬戶）

第二階段：使用問題階段

問題一：如何對專案作出貢獻步驟

操作流程總覽：
通過這種方式，專案的管理者不再需要忙著把使用者新增到貢獻者列表並給予他們推送許可權。 人們可以派生這個專案，將修改推送到派生出的專案副本中，並通過建立合併請求（Pull Request）來讓他們的改動進入源版本庫

流程通常如下：

1. 從 master 分支中建立一個新分支
2. 提交一些修改來改進專案
3. 將這個分支推送到 GitHub 上
4. 建立一個合併請求
5. 討論，根據實際情況繼續修改
6. 專案的擁有者合併或關閉你的合併請求

操作步驟：

一：情形：你想要參與某個專案，但是並沒有推送許可權，這時可以對這個專案進行“派生”。 派生的意思是指，GitHub 將在你的空間中建立一個完全屬於你的專案副本，且你對其具有推送許可權。
關鍵字：沒有push 許可權，想要參與
解決：使用fork（派生） 建立一個專案副本
例項：

首先，單擊“Fork”按鈕來獲得這個專案的副本。

這裡修改後提交的內容

如果你點選了那個綠色按鈕，就會看到一個新頁面，在這裡我們可以對改動填寫標題和描述，讓專案的擁有者考慮一下我們的改動。通常花點時間來編寫個清晰有用的描述是個不錯的主意，這能讓作者明白為什麼這個改動可以給他的專案帶來好處，並且讓他接受合併請求

提交後在原來的倉庫中多出了pull request1 請求。

此時視角轉到專案的擁有者角度
專案管理者受到請求如何處理,這裡整個流程轉到
合併請求討論頁面
pull request 下的具體頁面進行操作
接下來可能會通過電子郵件進行互動，就像我們在 分散式 Git 中提到的工作流程那樣，但是在 GitHub，這些都在線上完成。專案的擁有者可以審查修改，只需要單擊某一行，就可以對其發表評論.
當維護者發表評論後，提交合並請求的人，以及所有正在（Watching）這個版本庫的使用者都會收到通知。(這些人都會收到專案管理者的郵件的每個評價都會發送一個一份郵件）我們待會兒將會告訴你如何修改這項設定。現在，如果 Tony 有開啟電子郵件提醒，他將會收到這樣的一封郵件

每個人都能在合併請求中發表評論。
在合併請求討論頁面 裡我們可以看到專案擁有者對某行程式碼發表評論，並在討論區留下了一個普通評論。你可以看到被評論的程式碼也會在互動中顯示出來。

討論完後，貢獻者根據要求再次修該程式碼並且提交，在討論提交介面會自動新增跟蹤程式碼貢獻者新的提交，在討論介面

此時，專案擁有者可以直接merge 或者如果你需要，你還可以將分支拉取並在本地合併。如果你將這個分支合併到 master 分支中並推送到
GitHub，這個合併請求會被自動關閉。
這裡的merge都是no-fast-forward都會留下合併提交記錄的。

補充

問題一：pull request提交過於遲緩，導致原專案與提交的專案發生了衝突，此時應該如何辦？

關鍵字：提交衝突，原分支，提交分支
問題描述：
如果你的合併請求由於過時或其他原因不能幹淨地合併，你需要進行修復才能讓維護者對其進行合併。GitHub會對每個提交進行測試，讓你知道你的合併請求能否簡潔的合併。

解決方法：

如果專案貢獻者看到了像不能進行乾淨合併中的畫面，你就需要修復你的分支讓這個提示變成綠色，這樣維護者就不需

方式評價：你有兩種方法來解決這個問題。你可以把你的分支變基到目標分支中去（通常是你派生出的版本庫中的 master
分支），或者你可以合併目標分支到你的分支中去。
GitHub上的大多數的開發者會使用後一種方法，基於我們在上一節提到的理由：我們最看重的是歷史記錄和最後的合併，變基除了給你帶來看上去簡潔的歷史記錄，只會讓你的工作變得更加困難且更容易犯錯。
git rebase or pit pull 兩種方式

操作步驟：

說明：以下步驟是跟著文件自己走一遍出來的

我的
前提：區別：自己是在dev 分支進行修改和提交的解決衝突的
關鍵字：dev 分支衝突修改

步驟一：將原專案作為一個上游庫

步驟二：fetch 原專案庫分支（主要區別不是預設分支）

步驟三：將分支merge掉

步驟四：解決衝突

步驟五：在此提交and push

步驟六：開啟github看見新的提交

步驟七：重新拉去pull request的檔案，此時沒有conflict問題

自此，問題解決。