git使用总结
以前只是簡單git簡單用法，并有遠程merge權限，但現在由于沒有merge權限，所以使用上存在一定問題。
問題1：git push失敗，顯示有沖突，只能git pull產生沖突，自動merge會進行，產生新的提交，兩次commit提交含有merge會被Leader否決。
改進方法。add之前，
有兩種方法來把你的代碼和遠程倉庫中的代碼合并
a. git pull這樣就直接把你本地倉庫中的代碼進行更新但問題是可能會有沖突(conflicts)，個人不推薦
b. 先git fetch origin（把遠程倉庫中origin最新代碼取回），再git merge origin/master（把本地代碼和已取得的遠程倉庫最新代碼合并），如果你的改動和遠程倉庫中最新代碼有沖突，會提示，再去一個一個解決沖突，最后再從1開始
如果沒有沖突，git push origin master，把你的改動推送到遠程倉庫中。
如果兩個merge后，產生兩個commit，然后pull是up-to-date狀態,合并成一個的方法
git reset 前一個commit ID
git stash
git stash drop
丟棄
git reset?前一個commit ID
git stash
git pull
git stash pop
git add .
git commit -m ""
git push
問題2：提交時根本沒有branch，提交失敗。
?解決方法：repo sync后沒有? repo start --all <branchname> #這一步不能漏掉，否則克隆的所有倉庫默認處于no branch狀態，容易導致后面工作時添加的代碼丟失。
問題3：1個大項目，本地多個branch,且各自git提交在不同branch，盡管小的git成功提交和小的mm編譯成功，但造成最后大項目整體編譯會出現問題。編譯是以branch進行的，盡管子模塊git編譯都沒有問題，但整體編譯時子模塊不同branch造成各個Branch不是最新代碼，所以失敗。
解決辦法：
方法一：暴力法，效果最好。1：新建branch,并將舊分支進行強制刪除。，2：更新新建branch。repo sync，3repo start --all <branchname>，其中 branchname用新建branc名字。
方法二：解決各自Branc沖突，將代碼stash后，重新拉取新代碼，2：更新各個branch。repo sync，3repo start --all <branchname>，其中 branchname用希望編譯的branch名字。
問題4：打補丁方式。
首先，打補丁命令git commit --amend --no-edit 。
打補丁建議不更新，直接打補丁。一旦更新，打補丁會出現問題。
?
問題5:git rebase使用（轉自https://blog.csdn.net/TTKatrina/article/details/79288238）
使用git版本管理工具，必問git rebase的用法，但之前項目組人數5人，一直使用的是git pull，git commit 和git push，幾乎沒有用git rebase來變基，減少難看的merge 類型的commit。
最近一個新項目，兩地合作辦公大概有10人共用一個項目分支，幾分鐘內可能有多人提交，造成連續多個merge在gitk的路徑中，看不清某個人某次有價值的提交是哪一條，故組長建議大家使用git rebase。
看了2015年多個博客，前人栽的樹，整理如下，方便新人查看。
merge和rebase解決沖突的差別圖不貼了，主要是新使用的時候不知道寫什么命令行。
命令行的使用直接上代碼，git rebase 替代 git merge 大致過程：
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
附錄前人博客鏈接:
簡單對比git pull和git pull –rebase的使用
[精華部分]使用下面的關系區別這兩個操作：
git pull = git fetch + git merge
git pull –rebase = git fetch + git rebase
(附圖解)git pull –rebase 做了什么？ 以及 Cannot rebase: You have unstaged changes 解決辦法
很喜歡如下圖：
git pull –rebase 理解
這個命令做了以下內容：
a.把你 commit 到本地倉庫的內容，取出來放到暫存區(stash)（這時你的工作區是干凈的）
b.然后從遠端拉取代碼到本地，由于工作區是干凈的，所以不會有沖突
c.從暫存區把你之前提交的內容取出來，跟拉下來的代碼合并
所以 rebase 在拉代碼前要確保你本地工作區是干凈的，如果你本地修改的內容沒完全 commit 或者 stash，就會 rebase 失敗。
還附上了git add -u的解釋：
git add 的幾種參數區別：
git add -A 保存所有的修改
git add . 保存新的添加和修改，但是不包括刪除
git add -u 保存修改和刪除，但是不包括新建文件。
如果只想提交某個文件，可以使用git add 路徑/文件名 或者 git add 路徑/
git rebase 使用詳解
這一篇解釋了手動解決沖突時<<<<和=====的含義
一般情況下rebase都是會有沖突的，詳細查看沖突可以用命令git status然后就會顯示哪個文件有沖突，然后打開有沖突的哪個文件，會發現有一些“<<<<<<<”， “=======”， “>>>>>>>” 這樣的符號。
對于rebase的工作流以代碼的形式也體現的很清楚：
git rebase while(存在沖突) {git status找到當前沖突文件，編輯解決沖突git add -ugit rebase --continueif( git rebase --abort )break; }除去替代merge，git rebase還有合并多個commit的功能，如下取自知乎:
(知乎)git rebase有哪些用法？
原文似乎不樂意被轉載，簡單記錄如下，明細還是看原帖子。還沒試驗過，先記錄如下：
兩種經典用法
問題場景1.如何刪除歷史中某項提交？
【案例】去除提交列表中的某個commit，例如在master分支上A->B->C->D->E->F, 除去D。
方案一：
git checkout C //將HEAD切換到C提交
git cherry-pick master^ //master^即E,將E放在C后面，E的HSA1值改變
git cherry-pick master //master即F,將F放在E后面，F的HSA1值改變
git checkout master //將HEAD切換到master分支
git reset –hard HEAD@{1} //將HEAD切換到最新的F
方案二：
采用變基的方式
git rebase –onto C E^ F //前后開閉區間，E^即D，表面C后面加上(D,F]
git checkout master
git reset –hard HEAD@{1}
方案三：
交互式變基
git rebase -i D^
然后刪除第一行(?沒明白意思)
問題場景2.如何合并歷史提交？
【案例】在master分支上A->B->C->D->E->F, 合并D到C，即A->B->CD->E->F。
方案一：
git checkout D
git reset –soft HEAD^^
git commit -c C//-c表示重用C的提交信息
git cherry-pick E
git cherry-pick F
git checkout master
git reset –hard HEAD@{1}
方案二：
用變基命令
git checkout D
git reset –soft HEAD^^
git commit -c C//-c表示重用C的提交信息
git tag newbase
git rebase –onto newbase E^ master
git tag -d newbase//清理該tag
方案三：交互式變基
git rebase -i C^
將第二行的pick更改為squash，二者將合并(?還是沒明白意思)
?
轉載于:https://www.cnblogs.com/zhougong/p/9128303.html
總結
- 上一篇： node express 学习笔记
- 下一篇： async/await工作机制探究--N