1. 配置
1.1 用户和邮箱配置
git config --global user.name 用户名
git config --golbal user.email 邮箱地址
~/.gitconfig在该文件保存了你的配置信息
git config --localuser.name 用户名
git config --localuser.email 邮箱地址
~/work/project/.git/config该文件保存了你的配置信息
1.2 自定义提交模版
如果有你有一个项目在~/work/project/目录下,你可以创建一个提交git信息的模版文件".gitmessage",注意里面的提交信息如果是以"#"开头的只是提示信息。
git config --local commit.template .gitmessage #配置是否正确可以通过命令"git config --local --list"进行查看
git commit #该命令执行后就会自动使用.gitmessage模版进行提交
2.git提交补丁
2.1 rebase和merge
1. rebase的使用方法
1) 合并代码
git rebase [基节点]
git rebase [基节点] [待变基节点]
rebase
后面的参数可以是两个,也可以是一个,当rebase
为一个参数的时候其实是省略了第二个参数,第二个参数为HEAD指针当前指向的那个节点
例如:有feature和master两个分支,master和feature分支基于c0,c1,c2有三个提交,然后feature基于C2提交有C6,C7,C8提交,然后master基于C2有C3,C4,C5三个提交,这个时候如果你想把你的feature的C6,C7,C8提交到C3,C4,C5中:
$git checkout feature
$git rebase master 或者 git rebase master feature
实际最后的结果就是c0,c1,c2,c3,c4,c5,c6,c7,c8
C0---C1---C2---C3---C4---C5 (master)
\
C6---C7---C8 (feature)
C0---C1---C2---C3---C4---C5--- C6---C7---C8 (master/feature)
2) 重建提交历史
git rebase -i [地址引用]
例子1:修改最近第二次的提交信息, 1.git rebae -i HEAD^^ ;2.会有两个commit信息,修改第二个commit的pick改成edit,然后退出;3.修改文件;4.git commit --amend;5.git rebase --continue
例子2:合并最近两次的提交信息,1.git rebae -i HEAD^^ ;2.会有两个commit信息,修改第二个commit的pick改成squash,然后退出;3.git rebase --continue
备注:当执行rebase
操作时,git会从两个分支的共同祖先开始提取待变基分支上的修改,然后将待变基分支指向基分支的最新提交,最后将刚才提取的修改应用到基分支的最新提交的后面。
2.merge的使用方法
例子:如果需要把feature的修改合并到master中,参考下面的指令
git checkout master
git merge feature
3.rebase VS merge
异同:首先二者都具备整合分支间变更的能力,但二者的实现手段却大不相同。git merge总是在推进提交历史,并不会影响提交的原始状态,而git rebase整合变更的方式则是对提交历史进行重写
rebae优点:
rebase不产生新节点,当然也不会产生新的commit日志,但是merge过程中会产生一条几乎“无用”的Merge日志。使用rebase操作的最大好处在于你可以让项目提交历史变得非常干净整洁。首先,它消除了git merge操作所需创建的没有必要的合并提交。其次,rebase会造就一个线性的项目提交历史——也就是说你可以从feature分支的顶部开始向下查找到分支的起始点,而不会碰到任何历史分叉。
rebase缺点:
rebase操作产生冲突需要依次逐个进行解决,重写提交历史可能引起混乱,对新手使用也不是很友好。
总结:
在日常的小规模项目开发中,这种差异几乎可以忽略。但是在复杂的多人协作开发场景下,随着项目迭代的不断推进和工程复杂度的不断提高,rebase往往能助力生成相对清爽的提交历史,进而方便追溯工程的演进历史和缺陷排查。
不过为了获得这种便于理解的提交历史,却需要付出两种代价:安全性和可追溯性。如果不能遵循rebase的黄金法则,重写项目提交历史会为协作工作流程带来潜在的灾难性后果。再次,rebase操作丢失了合并提交能够提供的上下文信息——所以你就无法知道功能分支是什么时候应用了上游分支的变更
2.2 gerrit代码提交
1.gerrit代码提交被拒绝
不建议执行“git reset --hard HEAD^”撤销补丁在gerrit上看不到补丁的演变历史,对于补丁的修改只要Change-ID不变,就会形成一个patchse集,推荐修改方式:
例子1:如果补丁是最新的补丁提交
step1:1.修改文件; 2.git add [change files]; 3.git commit --amend; (该例子不是rebase的用例)
step2:git push origin HEAD:refs/for/[branch name]
例子2:如果补丁不是最新的补丁提交,比如有one和two两次提交,我需要修改one的提交信息(one的提交信息更早)
step1:1.git rebase -i HEAD^^^;2.修改第一个补丁的提交pick改成edit;3.git add [change files] && git commit --amend; 4.git rebase --continue
step2:后面的two的提交信息并不会受到第一个提交的影响,git push origin HEAD:refs/for/[branch name]
2.change-id问题
例子:如果你内核打了一个upstream的补丁,你需要推送到对应gerrit中的时候你通过git log看到没有对应的change-id,该补丁无法推送到gerrit进行审核
如果.git/hooks/commit-msg存在,执行git commit --amend --no-edit
如果.git/hooks/commit-msg不存在,curl -Lo ~/work/project/.git/hooks/commit-msg http://gerrit_server/tools/hooks/commit-msg && chmod 777 ~/work/project/.git/hooks/commit-msg
3. 其他命令使用
3.1 stash的使用
使用场景:stash会把未提交的修改保存起来
$ git stash / git stash save “test”
$ git stash list # 查看现有stash
$ git stash apply #会应用第一个stash缓冲,但是不会删除第一个stash
$ git stash pop #会应用第一个stash缓冲,会删除第一个stash
$ git stash drop $stash@{0} #会删除第一个stash
$ git stash show -p #查看修改内容,其中-p代表–patch可以查看特定stash的全部diff
$ git stash branch test-branch #从stash创建分支
$ git stash -u #-u代表–include-untracked可以stash untracked文件
3.2 blame的使用
使用场景:定位代码某一行的修改的commit-id
git blame -L 10,12 [file]
3.3 biosect的使用
使用场景:二分法查找错误
Git bisect是一个在故障排除中非常有用的命令,它可以帮助我们在一个较大的代码库中定位出现问题的特定提交。下面是使用git bisect的基本步骤:
-
开始使用git bisect之前,首先确定一个已知的”坏”提交和一个已知的”好”提交,这样git bisect才能找出中间的提交。
-
使用git bisect start命令来开始使用git bisect。如果你没有指定”坏”提交和”好”提交,git bisect会默认使用HEAD作为”坏”提交,使用历史中的第一个提交作为”好”提交。
例如:git bisect start
-
在使用git bisect命令之前,首先要告诉git哪个是”坏”提交和哪个是”好”提交。可以使用git bisect bad 命令来标记”坏”提交,使用git bisect good 命令来标记”好”提交。
例如:git bisect bad HEAD
git bisect good abc123 (abc123是一个”好”提交的commit哈希值) -
一旦”好”提交和”坏”提交都被标记,git bisect将会自动切换到一个介于这两个提交之间的提交。
-
测试当前提交并将结果告诉git。根据测试结果将当前提交标记为”好”提交或”坏”提交。可以使用git bisect good命令将当前提交标记为”好”提交,使用git bisect bad命令将当前提交标记为”坏”提交。
例如:git bisect good (如果当前提交是”好”的)
git bisect bad (如果当前提交是”坏”的) -
根据你的测试结果,git bisect将会自动切换到下一个介于”好”和”坏”之间的提交,然后再次让你测试并告诉git测试结果。
-
重复第6步,直到git bisect找到导致问题的特定提交。一旦找到,git bisect将返回最早的有问题的提交。
-
使用git bisect reset命令来结束git bisect命令。
例如:git bisect reset
以上是使用git bisect命令的基本步骤,通过这些步骤,可以帮助我们更快地查找导致问题的代码提交。
4. 其他常见命令
4.1 jobs/fg/bg使用
例子1:fg配合ctrl+z和jobs使用
$ vim test1.txt —> ctrl+z
$ jobs #有一个暂停任务
$ fg %1 —> shift+z+z # shift+z+z 等于":wq!"
$ jobs #没有任务
例子2:bg配和ctrl+z和jobs使用
$ sleep 120 &
$ jobs #后台运行中
$ fg %1 —> ctrl+z 暂停运行
$ jobs #查看状态暂停中
$ bg %1 #切换暂停改到运行状态
$ jobs #后台运行中
4.2 普通用户修改root用户文件
例子:vi /etc/profile
step1:执行:“:w !sudo tee %”
step2:输入root密码后修改成功
step3:重新退出:“:q!”
step4: cat /etc/profile 检查是否修改成功