記得：用快樂去奔跑，用心去傾聽，用思維去發展，用努力去奮鬥，用目標去衡量，用愛去生活。
git命令
1）新建一個分支：
git checkout -b feature_order_users_1.0 origin/master
git add . 添加當前目錄的所有文件到暫存區
git commit -m ‘描述’ 提交暫存區到倉庫區
2）合併當前分支到develop分支
git checkout develop
git merge --no-ff feature_order_users_1.0
git push origin develop
3）確認沒有問題後，合併到master分支：
git checkout master
git pull origin master
git merge --no-ff fixhot-liyunfang0522-login
git tag -a fixhot-liyunfang0522-login 打標籤
git push origin master
4）最後，刪除分支：
刪除本地 git branch -d <BranchName>
刪除遠程 git push origin --delete branchname
查看項目分支 git branch -a
刷新項目分支 git feach -p 再查看
回滾 git log -10
git reset --hard 2723823h 重置暫存區與工作區，與某次commit保持一致
git push -f origin master 強行推送當前分支到遠程倉庫，即使有衝突
git add . 添加當前目錄的所有文件到暫存區
git checkout . 恢復暫存區的所有文件到工作區
git config --global user.name " "
git config --global user.email " "
git fetch --all 查看所有分支
git checkout fixhot-- 切換到要上線的分支
git pull origin fixhot-- 拉代碼到本地
git checkout master 切換master
git merge --no-ff fixhot-- 合併要上線的分支 到當前分支
git reset --hard 重置暫存區與工作區，與上一次commit保持一致
git pull origin master 重拉代碼最新的
git merge --no-ff fixhot-- 合併
git status 會有幾個衝突的 修改
分支介紹
master
爲主分支，指向 可用於生產環境 的狀態。
develop
爲整合分支，總是反映 下一個版本的最新開發狀況
當 develop 分支上的源代碼達到一個穩定點並準備發佈時， 所有的更改都應
該以某種方式合併回 master 分支， 然後使用發行版本進行標註。
輔助分支
--- 功能分支 發佈分支 修復 Bug 分支 支持成員間並行開發， 輕鬆跟蹤功能開發、生產版本發佈、還能快速修復生產環境中產生的 Bug 。和主分支不同的是，輔助分支只有有限的生命週期，通常在完成使命後會被刪除。
功能分支
可能源自於：develop 分支 必須合併回：develop 分支 命名慣例：均可，不能包含 master， develop， release-* ，hotfix-* 功能分支通常存在開發人員的倉庫中，不會出現在 origin 倉庫。
創建一個功能分支
當我們開始寫一個新的功能時，請從 develop 分支中切換出來 # git checkout -b myfeature develop 新建一個分支並切換到該分支
在develop中加入已經完成的功能
完成的功能被合併進入 develop 分支中 $ git checkout develop 切換到develop分支 $ git merge --no-ff myfeature 合併myfeature分支並保留myfeature分支歷史 $ git push origin develop 上傳本地指定分支到遠程倉庫 --no-ff 標記將會在分支合併的時候在創建一個新的提交對象，即使這次合並可以使用 fast-forwark方法進行提交，這就可以避免丟失功能分支的歷史信息並且可以把所有的功能在疊加在一起提交上去
發佈分支
可能源自於：develop 分支 必須合併到：develop 和 master 分支 分支命名習慣：release-*
創建發佈分支
假設我們當前發佈的產品版本爲 1.1.5 ，並且即將發佈一個新的大版本。 develop 分支已經爲『下一版』做好了準備，我們決定把版本號改成 1.2，那麼，我們要做的只是檢出發佈分支並給它一個可以反映版本號的名字： $ git checkout -b release-1.2 develop 新建並切換到rel $ ./bump-version.sh 1.2 $ git commit -a -m "Bumped version number to 1.2" 提交所有修改過的 -a 只提交添加的 -a -m 提交添加的和修改過的
直到確定會推出發佈版的這段時間裏，新分支都會一直存在。在此期間，bug 修復可能會應用到這個分支上（而不是 develop 分支）。bump-version.sh 是一個虛構的腳本文件，用以改變工作副本中的一些文件來反映新版本。（當然也可以手動啦，重點是 那些 改變的文件）然後，碰撞後的版本號就被提交了。
完成併發布你的分支
$ git checkout master 切換到master $ git merge --no-ff release-1.2 $ git tag -a 1.2 打含附註的標籤 在文本添加 -m 方便 總結，只要在打標籤時添加-m”xxxx”，都可以添加標籤說明，並在git show 顯示的信息中顯示打標籤者、打標籤日期和標籤說明。而git tag -a應該只是聲明要打一個含附註的標籤，可以用-m添加，又或者是使用它跳轉的文本編輯軟件添加，總之加上-a的標籤必須要有標籤說明，而git tag不會強制要求。當使用git tag -m效果和git tag -a -m是一樣的。
爲了保持發佈分支所做的更改一致，我們需要將這些更改合併到 develop 分支中。
$ git checkout develop $ git merge --no-ff release-1.2 這一步可能會導致合併衝突（可能是因爲我們已經更改了版本號）。如果是這樣，嘗試修復它並再次提交。現在我們已經完成了所有步驟，發佈分支可以被刪除了，因爲我們不再需要它了： $ git branch -d release-1.2
熱修復分支
分支可能來自於：master 必須合併到：develop 和 master 分支命名慣例：hotfix-* 當生產版本中的一個嚴重的 bug 必須馬上被修復，熱修復分支可能從 master 分支上用於標記生產版本的對應標籤上創建分支。其本質是當有人準備對生產版本進行快速修復時，團隊成員（在 develop 分支）可以繼續工作。
創建修復bug分支
修復 bug 分支創建於 master 分支。 例如，1.2版本是當前生產環境的版本並且有 bug 。 $ git checkout -b hotfix-1.2.1 master 新建並切換 $ ./bump-version.sh 1.2.1 bump-version.sh 是一個虛構的腳本文件，用以改變工 作副本中的一些文件來反映新版本。 $ git commit -a -m "Bumped version number to 1.2.1" 打標籤 不要忘記在關閉分支後更新版本號！ 然後，修復 bug ，一次提交或多次分開提交。 $ git commit -m "Fixed severe production problem"
完成一個修復 bug 分支
bug 分支需要合併到 master 和 develop 分支上，以保證在下一版本中也包含該 bug 修復。 這與完成發佈分支完全相似。 首先，更新 master 並對這次發佈打上 tag 。 $ git checkout master $ git merge --no-ff hotfix-1.2.1 合併分支並保留歷史 $ git tag -a 1.2.1 然後，在 develop 分支裏包含 bug 修復分支的改動： $ git checkout develop $ git merge --no-ff hotfix-1.2.1 對於上面的規則，有一點是例外的： 當發佈分支已經存在時， bug 修復分支的改動應該合併到該發佈分支，而不是 develop 分支。當發佈分支完成的時候， 把 bug 修復分支反向合併到發佈分支中，最終也會導致 bug 修復被合併到 develop 分支中去。（如果 develop 分支中的工作馬上就要這個 bug 修復的改動並且不能等待發布分支完成，那麼現在你也可以安全地將 bug 修復合併到 develop 分支中去。）
git分支事務
1、master權限
受保護分支 別人無權限合併和提交到master
先修改項目成員權限 再修改項目分支權限
