git提交代码gerrit

原创已于 2024-12-20 12:56:34 修改 · 1.2k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#git #大数据

于 2024-12-19 15:40:24 首次发布

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