如何正確的使用github進行項目的協同開發?

近期跟小夥伴們一起做一些小的項目，我們自然是使用github來作為版本控制啦～感覺應該是沒找到正確的使用姿勢吧總是覺得很難用；每次向master分支提交pull request之前總是需要更新以下本地的倉庫，如果不小心忘記更新再加上master分支沒有仔細看提交的內容的話就會覆蓋掉master分支上的一些文件，最後甚至逼的大家直接在伺服器上改線上代碼，面對面的喊 "喂！我正改這個文件呢你們別動！", 很是逗逼 -.-

謝邀。

首先你們要學會git的正確的基礎的用法，先把progit的前4章理解完先。其次，忘記更新的情況下，是不可能覆蓋掉的，除非你們選擇了 --force，那隻能是nozuonodie。正確理解merge/rebase先。總之，看書吧。

怎樣使用 GitHub？ - 天豬(劉勇) 的回答

使用git丟代碼的情況，一般來說就是還沒有學會git的正確使用方法，這個時候講流程什麼的都是扯淡的。

先建立起良好的git的工作習慣，再來討論是github的PR模式好用，還是傳統的基於master進行開發方便，或者至少分一個master/develop的模式更好，更進一步的或者git flow比較方便。

對於git初學者，在認真學習pro git的前提下，我有以下建議：

1. 永遠保持你的工作區乾淨，也就是說無論做什麼操作之前，只要工作區不幹凈，就先提交，然後再考慮自己要做什麼。我建議初學者用commit而不是通常大家推薦的stash，因為commit可以在log裡面一目瞭然。

2. 使用自己不熟悉的操作，或者不知道後果的操作，或者有些擔心的操作之前，先創建一個備份的branch。雖然reflog也能夠在操作失敗後把提交找回來，但這個對初學者其實是很有難度的操作，與其在代碼丟掉後不知所措，不如在一開始就做好備份，git的branch功能這麼廉價，創建一個備份不會超過3s。你每熟悉一個命令，每真正掌握一個命令，就可以省略掉一次備份的操作，如此循序漸進。

3. 永遠不要push -f，如果有需要cancel的修改，用reverse反衝後重新建立新的提交。再強調一遍，永遠不要覆蓋已經push的歷史，永遠！

4. 永遠不要merge遠程的同名分支，同名分支在同步的時候一定是rebase，merge是用來合併不同的邏輯分支的，同一個邏輯分支必須rebase。如果對rebase心存疑慮，參考2，在rebase之前，先創建備份分支。

上班途中簡答

&> 每次向master分支提交pull request之前總是需要更新以下本地的倉庫

push 之前要先 pull 這種常識就不用說了吧，當然為了避免衝突可以先 fetch 再手動 merge 或 rebase

&> 如果不小心忘記更新再加上master分支沒有仔細看提交的內容的話就會覆蓋掉master分支上的一些文件

如果你們是採用 pr 的方式向 master 提交修改，可以引入 code review 機制，即提交 pr 的人不應該有權力 merge 這個 pr 到 master。此外可以用 git 的 local hook，確保 push 之前先跑一遍 pull。想偷懶的話可以直接設個

alias gpush = "git pull git push origin master"

&> 最後甚至逼的大家直接在伺服器上改線上代碼

沒事，小項目大家都這麼幹過。不過如果你想更好的利用 git 和 github 的話，最好還是避免直接修改線上代碼，否則線上代碼和 code base 不一樣纔是後患無窮。建議你們寫好編譯部署的代碼，確保 master 中的代碼隨時可以用於生產環境，這樣代碼的改動可以隨時應用於線上，就不會想著去改線上代碼了。

剛好今天研究了github協同開發問題。常見的辦法有兩種：
1.通過邀請的方式，共同開發。適合小團隊
2.通過fork方式。可以用純命令行或者github頁面操作方式進行。

對於您這種情況，建議可以使用邀請共同開發的方式進行。

詳細操作步驟和命令截圖可以參考這裡：

github協同工作

GitHub ,一個擁有數十億行代碼的網站，聚集數百萬個級別程序大神共同研究開源軟體中的問題的網站。作為一隻純正的程序猿，又怎麼可以不知道GitHub 這一巨大的寶藏，並如饑似渴的進行挖掘利用其中的寶藏呢！

? 什麼是Git和GitHub？

（科普篇）

Git 是由Linux 之父Linus Tovalds 為了更好的管理Linux的內核而開發創立的分散式版本控制、軟體配置管理軟體！用人話解釋一遍，就是，Git是管理你的代碼記錄的工具！然而,這麼簡單的功能不是用office 就可以輕而易舉的實現了呢？所以Git的過人之處並不僅僅在於簡單的保存，它甚至可以保存你的每次修改記錄，這就是Git育種與眾不同的特質！也正是因為這個特質，讓Git擁有了很多過人的用處！但這一切侷限於單機操作！從而，GitHub的衍生完美地解決了Git的這個出廠bug，打開官網頁面，赫然的就是：

GitHub lets you version your code, collaborate with others, and share what you』ve built with the world. We』re excited to see what you make.

顯而易見，GitHub可以隨時、隨地、隨心地上傳(push) ,下載（push) 各種文本、代碼文件到在線GitHub ，更像是一個超大的遠程倉庫，可以供你存儲，交流各種文件信息，毫無疑問，作為一個超級雲盤，在平臺上可以隨時上傳，創造屬於自己的開源代碼並和全世界的朋友分享自己的成果！ GitHub就這樣成為了一個各大資深程序猿鍾愛的聚集地！

正因為以上兩個獨一無二的特質，Git的修改記錄存儲以及GitHub為多機交互提供的完美適配，讓Git 和Github 成為了協同工作的首選。團隊成員可以獨立創建分支，隔離工作，最後又共同提交到主代碼庫，各個分支合併到在主枝形成了一棵枝繁葉茂的大樹，眾人合力共同栽種出一棵枝繁葉茂的大樹，為團隊協作提供了完美的交互平臺。此外，GitHub貼心的為大家設計了簡易平臺，可以供使用者 Pull Request 以及修改內容的討論區域，極大程度的優化了使用者的滿發分體驗。

當然，如果有敵方隊友對你的代碼進行了一番修改，你同樣可以通過（Roll back to the Commit）回到自己的初始上傳狀態來應對敵方向你發動的代碼修改攻擊！倘若你和敵方隊友達成共識，你同樣可以通過（Git pull）選項將雲端上的最新修改同步更新到本地！

? 論正確的打開姿勢？

（Simon老師親自全程展示，重點五顆星）

Step1：在本地安裝Git

選擇合適的版本進行安裝，當然這個軟體雖然不是很大，但下載還是有絲絲費力！

Step2：創建和處理本地倉庫（repository）

新建一個文件夾，右擊Git Bash Here. 通過Git init這個命令將新建的文件夾升級成為Git可以直接管理的倉庫。此時本地創建的倉庫和Git已經完美連接，此後涵蓋於此新建文件夾所有的本地修改，刪除等等動作均可以被Git探測並且同步記錄。(遺憾的是，視頻和照片這些二進位的文件目前仍無法做到跟蹤文件的詳細變化)

如果有敵方隊友不滿意你的操作，對你的代碼進行了一番騷操作，你同樣可以通過（Roll back to the Commit）回到自己的初始上傳狀態來應對敵方向你發動的代碼修改攻擊！然而很意外，你和敵方隊友達成共識，你同樣可以通過（Git pull）選項將雲端上的最新修改同步更新到本地！

Step3：創造屬於遠程項目倉庫

SSH公鑰認證可實現SSH免密碼登陸，所以GitHub上倉庫與本地倉庫的連接，也是通過使用了SSH的公開密鑰進行認證的。

同時在GitHub 上註冊帳戶，創建遠程倉庫（ Create New Repo），系統自動生成一個倉庫地址，與本地的新建文件夾運行命令進行關聯（git remote add origins https://github.com/......）然後，本地和遠程的倉庫就已經完成了所有的連接，初始適配完成！至此，可以開啟一段奇妙的GitHub之旅。之後，只要經過簡單的命令（git push origin master）, 或是通過（commit to master）實現將本地的分支推送到遠程倉庫，讓更多的程序愛好者看到你的最新著創作！在雲端上一磚一瓦搭建的項目倉庫通過(open the file in Github Deskpot)可以分分鐘搬運到你的本地文檔，實現實時同步更新，可以說是酷炫到爆炸！