git提交代码gerrit

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的基本步骤:

  1. 开始使用git bisect之前,首先确定一个已知的”坏”提交和一个已知的”好”提交,这样git bisect才能找出中间的提交。

  2. 使用git bisect start命令来开始使用git bisect。如果你没有指定”坏”提交和”好”提交,git bisect会默认使用HEAD作为”坏”提交,使用历史中的第一个提交作为”好”提交。

    例如:git bisect start

  3. 在使用git bisect命令之前,首先要告诉git哪个是”坏”提交和哪个是”好”提交。可以使用git bisect bad 命令来标记”坏”提交,使用git bisect good 命令来标记”好”提交。

    例如:git bisect bad HEAD
    git bisect good abc123 (abc123是一个”好”提交的commit哈希值)

  4. 一旦”好”提交和”坏”提交都被标记,git bisect将会自动切换到一个介于这两个提交之间的提交。

  5. 测试当前提交并将结果告诉git。根据测试结果将当前提交标记为”好”提交或”坏”提交。可以使用git bisect good命令将当前提交标记为”好”提交,使用git bisect bad命令将当前提交标记为”坏”提交。

    例如:git bisect good (如果当前提交是”好”的)
    git bisect bad (如果当前提交是”坏”的)

  6. 根据你的测试结果,git bisect将会自动切换到下一个介于”好”和”坏”之间的提交,然后再次让你测试并告诉git测试结果。

  7. 重复第6步,直到git bisect找到导致问题的特定提交。一旦找到,git bisect将返回最早的有问题的提交。

  8. 使用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 检查是否修改成功

### 如何通过Git Bash将代码提交Gerrit #### 安装必要的软件和配置环境 为了能够顺利地使用Git Bash向Gerrit服务器推送更改,首先要确保已经正确安装并配置好了Git以及设置了SSH密钥。这一步骤至关重要,因为大多数情况下访问Gerrit都是基于SSH协议完成的。 #### 初始化本地仓库并与远程库关联 创建一个新的项目或者克隆现有的Gerrit托管项目的副本至本地计算机上: ```bash git clone ssh://<username>@review.example.com:29418/<project-name> cd <project-name> ``` 这里`ssh://<username>@review.example.com:29418/`代表的是Gerrit服务端地址,而`<project-name>`则是目标项目的名称[^4]。 #### 配置全局用户名和邮箱 为了让每次提交都能附带正确的身份信息,在首次操作前应当先设定好用户的姓名与电子邮件地址: ```bash git config --global user.name "Your Name" git config --global user.email you@example.com ``` #### 创建新分支进行开发工作 建议在一个独立于默认master/main分支的新分支上来做所有的改动,这样可以保持主线清晰干净,并且方便后续管理不同版本间的差异: ```bash git checkout -b feature_branch_name ``` #### 添加文件到暂存区并提交变更 当完成了某些功能实现或是修复了一些Bug之后,就可以准备把这些变化记录下来了。此时需要利用`git add .`命令把所有被修改过的文档加入到索引(即所谓的“暂存区”),然后再用`git commit`来保存这些变动的信息: ```bash git add . git commit -m "commit message describing changes made." ``` 值得注意的是,由于Gerrit特有的审核流程机制的存在,普通的`git push`并不能直接应用于此类场景下;相反,应该采用特定格式化的语法来进行推送动作——具体来说就是加上参数`HEAD:refs/for/master`(假设要推送到main分支): ```bash git push origin HEAD:refs/for/master ``` 这条语句的作用在于告知远端服务器当前所处的位置(`HEAD`)是要作为候选补丁集的一部分提交给`master`分支接受审查而非立即合并进去。 #### 处理可能遇到的问题 有时可能会碰到权限不足或者其他原因导致无法成功推送的情况发生。这时可以根据具体的报错提示采取相应的措施加以应对,比如确认是否已安装合适的IDE插件支持等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值