git使用总结

以前只是简单git简单用法，并有远程merge权限，但现在由于没有merge权限，所以使用上存在一定问题。

问题1：git push失败，显示有冲突，只能git pull产生冲突，自动merge会进行，产生新的提交，两次commit提交含有merge会被Leader否决。

改进方法。add之前，

1. 有两种方法来把你的代码和远程仓库中的代码合并

   a. git pull这样就直接把你本地仓库中的代码进行更新但问题是可能会有冲突(conflicts)，个人不推荐

   b. 先git fetch origin（把远程仓库中origin最新代码取回），再git merge origin/master（把本地代码和已取得的远程仓库最新代码合并），如果你的改动和远程仓库中最新代码有冲突，会提示，再去一个一个解决冲突，最后再从1开始

2. 如果没有冲突，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 大致过程：

git stash
git pull —rebase
git stash pop
手动解决冲突
git add -u
git rebase —continue
如果此时提示No rebase in progress?则表示已经没有冲突了；否则上面两步要重复多次
git commit -m “xxx”
git push origin [branch] -f

• 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然后就会显示哪个文件有冲突，然后打开有冲突的哪个文件，会发现有一些“<<<<<<<”， “=======”， “>>>>>>>” 这样的符号。

“<<<<<<<” 表示冲突代码开始

“=======” 表示test与master冲突代码分隔符

“>>>>>>>" 表示冲突代码的结束

<<<<<<<  
所以这一块区域test的代码

=======  
这一块区域master的代码

>>>>>>> 

对于rebase的工作流以代码的形式也体现的很清楚：

git rebase 
while(存在冲突) {
    git status
    找到当前冲突文件，编辑解决冲突
    git add -u
    git rebase --continue
    if( 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，二者将合并(?还是没明白意思)

---