Github操作完備指南

一。fork專案以及保持同步

 

1，首先fork 別人的一個專案：

fork

2，在自己的賬戶下找到剛才的專案，複製自己專案地址

github 指標HEAD

3，clone到本地：

git clone

 

4，如果專案有依賴包，還要安裝依賴包。一般 bower install 即可(有bower.json檔案時)。

5，fork 之後保持同步（windows環境）

    （1）git remote -v  ;

這個命令用於檢視所有遠端庫(remote repo)的遠端url, 如果只輸入git remote就是列出所有遠端庫。

origin 自己github上的專案

（2）發現沒有原作者的專案地址，git命令： 

git remote add upstream  原作者專案url；

git remote add upstream

這個命令用於新增原作者remote repo(遠端庫), 該操作只需操作一次即可 這個時候輸入git remote -v,會得到結果：

（3）可以用git status命令檢視當前改動；

（4）保持同步：

git fetch('拿來、取來') upstream（'上游、上行'） 

git fetch upstream

git checkout('檢驗、檢出') master

git checkout master

接下來就是合併這兩個分支，將原作者專案的修改同步到自己這裡（注意還是指本地專案，不是自己Github空間裡的專案）。

git merge upstream/master

本地同步完成後，同步到自己的github上：

git push origin（‘起源、原點’） master

至此, origin的master branch已經於原作者專案同步了。

username and  password

up-to-date

保持同步的小結：

保持同步可以用四個命令，按順序是：
git checkout master ,  git fetch upstream, git rebase,  git push。

---

NOTE:

更新working branch(當前工作的branch)

 

。之所以需要這麼做, 是因為, 假設你開發花了三天時間. 而三天之內upstream上面更新過. 然後, 如果你在這個時候提交PR, 理論上是不能merge的. Git會報錯, 因為它發現你開始工作的節點與upstream當前的HEAD指標不同了.

。當然, 如果這三天upstream上沒有任何更新, 你的PR就可以隨時merge, 因為你的程式碼是基於未改動的upstream master寫的, 所以不會出現conflicts

。更新working branch, 相當於: 把upstream master上的改動應用到當前的working branch. 結果就是, 可以假裝你的working branch是基於改動後的upstream master寫的

。git checkout master, 然後git fetch upstream, 然後git merge 或git rebase

     ..首先切換到master branch (origin的master branch)是獲取upstream上面所有的更新, 並獲取HEAD指標。
     ..理論上, git merge和git rebase 此時 都可以更新origin的master branch. 強烈推薦使用git rebase master. 原因見下文

。git checkout [workingBranch], 然後git merge master或git rebase master

     ..這兩個命令都是把master branch(當然, 是origin上的master branch)更新的內容應用到working branch上面.
     ..區別在於, 使用git merge, 會讓你當前在working branch上面已經做的更改與upstream master的更改在timeline上出現分支. 而使用rebase, 會把你的更改加到upstream master更改的後面, 結果是整體時間軸呈線性的, 沒有分岔。
     ..也可以使用git rebase -i master來實現互動式rebase, 這一步驟一般是在提交PR之前做, 允許使用者squash commit (合併commit,把之前的幾次commit合為一個)
     ..如果自己當前的branch有過改動也沒關係, 在rebase的過程中, 會讓你處理conflicts, 處理好之後用git add [files]提交改動後的特定檔案或者用git add .提交全部檔案,即可完成rebase

至此, origin上的working branch已經與原作者沒有衝突, 可以隨時merge。

---

關於push

 

。首先配置一下全域性環境, git config --global push.default simple

。第一次push到some branch的時候用一次git push -u origin [someBranch] (效果等同於git push --set-upstream origin [someBranch]). 以後再要push到這個branch只需要git push就可以了, 前提是, 你在這個branch上.

---

關於branch

 

。本地刪除branch是git branch -d xxx.
       ..如果有未提交的內容, 想強行刪除branch, 就是git branch -D xxx. 謹慎使用, 這樣會讓你的未提交內容丟失

。如果想在Github裡刪除名為dev的branch, 命令是git push origin :dev

---

Commit

 

。git commit是把當前的改動放到Staging area(一個緩衝區)

。記得使用git commit -m "[commitMessage]"

Commit Message的寫法:

      。基本格式: 型別: [主題]

       。型別分為如下幾種:

feat: Feature的縮寫, 新的功能或特性

fix: bug的修復

docs: 檔案修改, 比如修改應用了ngDoc的專案的ngDoc內容

style: 格式修改. 比如改變縮排, 空格, 刪除多餘的空行, 補上漏掉的分號. 總之, 就是不影響程式碼含義和功能的修改

refractor: 程式碼重構. 一些不算修復bug也沒有加入新功能的程式碼修改

perf: Performance的縮寫, 提升程式碼效能

test: 測試檔案的修改

chore: 其他的小改動. 一般為僅僅一兩行的改動, 或者連續幾次提交的小改動屬於這種

       。作用域:

這個引數用來描述這次改動發生的位置.
比如更改了css檔案, 就可以把"css"放在這裡. 比如更改了JS檔案, 可以把"js"放在這裡
對於多個作用域, 可以用逗號分隔. 比如"html, png"

       。主題:

簡略描述改動了什麼
用英文寫, 用現在時, 不要用過去時. 最開頭不需要大寫
中間可以有逗號, 但結尾不要有句號
細節寫在PR的詳細內容裡, 不需要寫在這裡

       。示例

改動1: 在JS檔案裡修復了一個可能會使HTML不顯示結果的bug
git commit -m "fix(js) fix a bug that may cause rendering issue of HTML"

改動2: 在HTML裡面加入了處理瀏覽器相容性的程式碼
git commit -m "feat(html) add code for browser compatibility"

改動3: 優化了AngularJS名為mainSvc的Service非同步傳送HTTP request效能
git commit -m "perf($service) enhance async perf of mainSvc sending HTTP request"

Pull Request

標題採用預設設定即可. 預設為commit (或squash之後commit) 的commit message。詳細內容欄:

在第一行加上引號內的內容, "- [ ] LGTM". 別人review你的程式碼之後就在這兒給你打個勾, lgtm是look good to me的縮寫.

Review別人程式碼的時候, 如果覺得沒問題, 打鉤之後在底下評論"LGTM"

支援Markdown和Emoji

檢視別人的PR

review別人PR的時候, 建議下載到本地, 檢視後再確定是否通過

專案路徑中找到.git/config, 在upstream底下加上: fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

配置好之後, git fetch upstream

在github上找到你想要review的PR的編號, 如果是3, 就在本地, git checkout pr/3, 然後就可以看到改動之後的程式碼了

Log與Reflog

git log用來查詢repo的版本變動情況. 如果有需要的話, 可以通過commit ref來恢復

建議使用git log --oneline --decorate --graph作為查詢命令

git reflog用來查詢本地的操作歷史. 確切一點說, 是查詢HEAD的變化情況. 每一次HEAD變動, 都會記錄在reflog裡

---

二。Creating Project Pages manually

原文：https://help.github.com/articles/creating-project-pages-manually/#make-a-fresh-clone

1，Make a fresh clone

$ git clone github.com/user/repository.git     (# clone our repository)

git clone 

2，Create a gh-pages branch

$ cd repository

$ git checkout --orphan('孤兒‘) gh-pages 
(# Creates our branch, without any parents (it's an orphan!))
(Switched to a new branch 'gh-pages')

$ git rm -rf .  
(# Remove all files from the old working tree)
(rm '.gitignore'  ···)

git checkout --orphan gh-pages

git rm -rf .

3，Add content and push

Now you have an empty working directory. You can create some content in this branch and push it to GitHub. For example:

$ echo "My Page">index.html

$ git add index.html

$ git commit -a -m "First pages commit"

$ git push origin gh-pages

4，Load your new GitHub Pages site

After your push to thegh-pagesbranch, your Project Pages site will be available at 'http(s)://<username>.github.io/<projectname>' .

二（續）Creating Pages with the automatic generator

https://help.github.com/articles/creating-pages-with-the-automatic-generator/

---

三。github提供的提示

1，create a new repository on the command line

echo "# git-testing" >> README.md
git initgit add README.md
git commit -m "first commit"
git remote add origin https://github.com/kingrychen/git-testing.git（示例）
git push -u origin master

2，push an existing repository from the command line

git remote add origin https://github.com/kingrychen/git-testing.gitgit
push -u origin master

3，import code from another repository

 

作者：一隻小菜鳥
連結：https://www.jianshu.com/p/79454cf00945