一。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