gerrit

Reference是代码提交的目的地（分支或Tag），Gerrit的权限管理是基于reference进行。默认reference是“refs/heads/”，这个通常不需要修改。"refs/"是控制所有提交的reference
gerit配置参考链接

gerrit 终端命令使用
gerrit除了网页端可以使用web界面，来新建仓库，新增分支，也提供后台终端界面的操作命令，具体使用格式:
gerrit create-project --name $projectname
gerrit create-branch $projectname $newbranch $basebranch
可使用ssh远程使用gerrit终端命令行:
ssh -p $PORT user_name@gerrit_url gerrit create-project --empty-commit --name $prj

关于refs/for/ 和refs/heads:
Branches, remote-tracking branches, and tags等等都是对commite的引用（reference）,引用都以 “refs/……”表示. 比如remote branch: origin/git_int(=refs/remotes/origin/git_int)， local tag: v2.0(=refs/tags/v2.0)， local branch: git_int(=refs/heads/git_int)…

简单点说，就是refs/for/mybranch需要经过code review之后才可以提交；refs/heads/mybranch不需要code review。
（since you want to directly push into the branch, rather than create code reviews. Pushing to refs/for/* creates code reviews which must be approved and then submitted. Pushing to refs/heads/* bypasses review entirely, and just enters the commits directly into the branch. The latter does not check committer identity, making it appropriate for importing past project history）
如果需要code review，直接push
$git push origin master
那么就会有“! [remote rejected] master -> master (prohibited by Gerrit)”的错误信息
而这样push就没有问题，
$git push origin HEAD:refs/for/mybranch

Git

git强制覆盖本地代码：

git fetch --all
git reset --hard origin/master
git pull

git 创建空分支
方法1：
使用 git checkout的–orphan参数: 带–orphan参数会建立一个新的没有提交记录的分支，并保持本地文件不动，因此新建的分支用git status会显示当前文件都需要add进入暂存区。

1. git checkout --orphan branchname
2. git rm -rf . 删除原来代码树下的所有文件
3. git commit -am “xxx”
4. git branch -a 查看分支情况，没有提交记录的分支 git branch 不显示。

方法2：(只能将分支文件清除干净，提交记录存在)

1. git branch <new_branch>
2. git checkout <new_branch>
3. git rm --cached -r .
4. git clean -f -d 创建空的commit
5. git commit --allow-empty -m “[empty] initial commit” 推送新分支，使用 --allow-empty可提交空提交。
6. git push origin <new_branch>

关于git使用patch
git diff > xxx.patch
patch < xxx.patch

git format-patch commit-id -n
-n 用来指定从commit id对应的commit开始算起n个提交。
git apply xx/patch
git am 可以加上commit信息。

检查patch是否可用，没显示文字，就说明可用，且无冲突；
git apply --check ~/xxx/0001-add-11111.patch
打入patch，可以批量，也可以单个。
git am ~/xxx/*.patch

git show-ref打印所有references。List references in a local repository。
git show-branch打印本地仓库当前分支信息。

git add -u <==> git add –update
提交所有被删除和修改的文件到数据暂存区
git add .
提交所有修改的和新建的数据暂存区
git add -A <==>git add –all
提交所有被删除、被替换、被修改和新增的文件到数据暂存区
git commit –am “本次提交描述” 或 git commit –a –m“本次提交描述”
该命令会将本地工作区中修改后，还未使用git add . 命令添加到暂存区中的文件也一并提交上去。相当于git add . 与git commit –m “本次提交描述”两句操作合并为一句进行使用。

关于git submodule用法
https://www.cnblogs.com/lsgxeva/p/8540758.html
git submodule 是在一个git仓库里添加别的git库作为子库，
下拉(pull)整个库时，内部子库不同时更新，需单独git submodule init、update才能实现更新。添加子库用git submodule add。
上传(push)整个库，需先提交子库，再在外部总git下提交整体库。

可以使用本地git库作为远程库测试。
使用方式:

mkdir repos
cd repos
git --git-dir=remote_repo.git init --bare //--bare表明该库只记录git操作，不记录原文件。这样remote_repo 下只存放普通库.git文件夹下的内容。clone也可加--bare。
cd workspace
git clone repos/remote_repo.git localreponame
cd localreponame
git status

git强制覆盖本地文件，与远程仓库保持一致：

git fetch --all
git reset --hard origin/master
git pull

主要执行git reset --hard origin/branchname
–hard 强制使本地源码恢复与远程仓库一致；
不加–hard 本地提交与远程仓库保持一致，但是，本地代码没有修改。应该是。
git fetch 用法：

git fetch origin branch1
这个操作是git pull origin branch1的第一步, 而对应的pull操作,并不会在本地创建新的branch。这个命令可以用来测试远程主机的远程分支branch1是否存在, 如果存在, 返回0, 如果不存在, 返回128, 抛出一个异常.
git fetch origin branch1:branch2
首先执行上面的fetch操作，使用远程branch1分支在本地创建branch2(但不会切换到该分支),如果本地不存在branch2分支, 则会自动创建一个新的branch2分支,
如果本地存在branch2分支, 并且是`fast forward’, 则自动合并两个分支, 否则, 会阻止以上操作.

fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。
因为在这个过程中没有创建commit

squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，
于是使用–squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。

–no-ff指的是强行关闭fast-forward方式。

fast-forward
在分支A的HEAD节点基础上，新建A_1分支，在A_1的分支修改提交，即A_1的HEAD超前A的HEAD两个提交，此时，使用merge，就是默认将A节点快进A_1的HEAD节点上。这样的合并就是fast-forward。这样合并时，显示Fast-forward模式，不会新增commit节点(不显示merge信息)，如果使用non-ff的模式，则必须生成一个新的commit提交。
https://www.cnblogs.com/charlesblc/p/6132384.html

Git 之 merge 与 rebase 的区别 https://segmentfault.com/a/1190000012897637 比较好的文章，讲的清楚明了，其中讲到了fast-forward。没有烧脑，只有讲没有讲清楚。

git merge就是将两个分支的HEAD并成一个节点，git log时会显示这个合并节点下的所有分支的提交以及merge信息。gitk能查看到节点分支合并。

git rebase 将本地分叉提交历史整理成直线。
基于A分支建立A1分支后，A分支及A1分支均有提交，合并A，A1分支。
使用merge，仅仅是将A及A1的HEAD合并成为一个，同时需要解决commit之间的冲突。
merge原理图:

使用rebase，在分支A1使用git rebase A是在A的HEAD提交的基础上，增加A1建立之后的提交，因此会形成直线提交历史。
rebase原理图：

git从别的分支拿文件，或让文件与别的分支保持同步
git checkout [branchname] [filename]

*设置 SSH 免密码登录

1. 使用 ssh-key-gen 命令生成公钥和私钥，这里要注意的是可以对私钥进行加密保护以增强安全性。
   ssh-keygen
2. 用 ssh-copy-id 命令将公钥复制或上传到远程主机，并将身份标识文件追加到节点2的 ~/.ssh/authorized_keys 中：
   ssh-copy-id -i ~/.ssh/id_rsa.pub user@ipaddr。
   -i指定要上传的公钥地址
   注：这里需要区分本地用户(通过证书区分)和远程用户(通过user区分)。

查看project所有分支的提交
gitk -all -d
查看单个分支就用gitk就行

git rebase 、git revert及git reset 的区别：
git revert commitid 回撤提交会为本次的revert操作添加一个提交节点，不会删除先前的提交记录，git log可查看；

git reset commitid 可选择–hard 使本地代码同步指定的节点一致，soft只将提交记录与节点提交保存一致，但是本地代码不变动。
HEAD当前分支最新提交节点
HEAD^当前分支前一次提交节点
HEAD^^当前分支前前一次提交节点

git rebase -i 可以合并提交
rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了

git log --graph --pretty=oneline --abbrev-commit
git log --oneline

git branch --set-upstream 用来设置本地本分支对应的远程分支

gerrit hook

git hook脚本位于库的.git/hooks目录下，当git执行到特定的操作时会调用特定的钩子脚本。当git init或git clone的创建git库时，会在.git/hooks目录下创建示例脚本(xxx.sample)，用户可参照示例脚本的写法开发适合的钩子脚本。https://blog.csdn.net/taiyangdao/article/details/71079021
commit-msg hook
由git commit 命令调用，具体原理:
在Gerrit中，该hook实际上就是一个简短的Shell脚本实现。
commit-msg hook可以接收一个文件名作为参数，该文件中包含写好的commit message，具体逻辑如下：

如果已有Change-Id行则什么都不做，返回状态0。
如果没有Change-Id行，则
    如果有重复的"Signed-of-by"行，如果有则异常退出，返回状态非0。
    否则在Signed-off-by行之前追加插入Change-Id行；
    或Acked-by行之前追加插入Change-Id行；
    或在commit message末尾插入一个空行，然后在空行之后追加插入Change-Id行。

当然，也可以设置Gerrit配置文件gerrit.createChangeId=false禁用该hook。

安装commit-msg hook
两种手动:

scp -p -P 29418 myname@gerrit_server:hooks/commit-msg ~/.git/hooks/
将远程hook拷贝到本地.git/hook下。
chmod u+x .git/hooks/commit-msg
将commit-msg hook统一复制到$GIT_TEMPLATE_DIR路径下。
这样，后续每次git init创建Git库时，被自动复制到新Git库的.git/hooks/目录下。

commit-msg hook使用方式
第一次执行git commit命令时，只要输入具体的commit message，或者根本不必输入任何commit message，而直接采用默认的模板文件内容。git会自动调用commit-msg hook，生成并插入一个Change-Id行。

后续执行git commit --amend时，无需再手工输入任何commit message，甚至可以直接执行如下命令git commit --amend --no-edit。

change-id https://blog.csdn.net/zengfenliang/article/details/79980431
保证已经提交审核的修订通过审核入库后，被别的分支 cherry-pick 后再推送至服务器时不会产生新的重复的评审任务。Gerrit 设计了一套方法，即要求每个提交包含唯一的 Change-Id，这个 Change-Id 因为出现在日志中，当执行 cherry-pick 时也会保持，Gerrit 一旦发现新的提交包含了已经处理过的 Change-Id ，就不再为该修订创建新的评审任务和 task-id，而直接将提交入库。

提交gerrit缺失changeId https://www.jianshu.com/p/1848fabc9360

gitdir=$(git rev-parse --git-dir); scp -p -P 29418 name@git.co.com:hooks/commit-msg ${gitdir}/hooks/ gitdir是解析出当前git的路径，scp把hook文件拷贝到本地git的.git/hooks下。
git commit --amend //不需要修改都行 直接退出即可
git push origin

也可以clone的时候，以clone with hook直接下载代码的命令，下拉代码的同时将hook安装到本地仓库。

jenkins

自动化部署使用的工具，可以用来管理服务器的一些服务或者使服务器定期触发执行指定的脚本。

问题: Jenkins Job执行shell脚本报“command not found”
原因: ssh登录主机可以执行命令，但在Jenkins job的shell中执行报“command not found”。
环境变量(PATH)配置缺少导致
可以分别执行env，应该会看到ssh登录主机和Jenkins job的shel执行结果不同，即两种情况的环境变量不同。主要是环境变量PATH配的不对，PATH为命令工具安装的路径，jenkins在PATH中找不到对应的命令，则报“command not found”。
解决办法:
1、在服务器终端控制台执行 echo $PATH，并复制打印出来的环境变量。
2、jenkins->系统管理->系统设置->勾选Environment variables，添加键值，键：PATH，值：刚才复制的那句话->保存。
参考 https://blog.csdn.net/weixin_34416754/article/details/86006804