OpenStack开发过程中常用Git操作场景( by quqi99 )_git review命令添加评审-CSDN博客

本文链接：https://blog.csdn.net/quqi99/article/details/9425385

OpenStack开发过程中常用Git操作场景( by quqi99 )

作者：张华发表于：2013-07-23
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明

http://blog.csdn.net/quqi99 )

Git是一个分布式的代码管理库，linux之父开发，用了三年多了，直观感受的优点如下：

一是真正的分布式，既不用担心哪天服务器坏了代码丢失了，也不用担心像中美之间网速慢啊或断网什么的影响开发，因为本地就是一个代码库。
二是体积小，对存储进行了优化。
三是速度快，因为比较的是哈希。
四是差异比较算法很智能，能到达行级，甚至一行中的列级。
五是支持对二进制的差异比较，如一个Word文档什么的。
六是其它。。。

      虽然对原理也算熟，用得也算多，但一段时间不用还是容易忘，下面记下一些日常工作场景常用到的命令：

场景一：如何往社区提交一个Bug
      安装git： sudo yum install git git-review
     下载代码：git clone https://github.com/openstack/neutron.git

1    通过ssh-keygen命令创建密钥, 然后在“https://review.openstack.org/#/settings/ssh-keys 界面设置public key.
2    运行“git review -s”命令设置git-review (20250604 现在需要用 git commit -a -s 来添加 Signed-off-by, Starting on July 1st 2025 this is changing to follow the Developer
Certificate of Origin (DCO) model, where each change will require a
'Signed-off-by' attestation), 这步会在.git/config文件中添加一个名为gerrit的远程分支ssh://zhhuabj@review.openstack.org:29418/openstack/neutron.git，并且可以通过ssh访问：ssh -p 29418 review.openstack.org)
      如果报“Permission denied (publickey)”这样的错的话，简单运行"ssh-add"命令将ssh key添加到ssh agent即可

      还有一种可能是用户弄错了，ssh -i zhhuabj_lcy01.pem ubuntu@162.213.** -vvv
3   如果想要修改一个bug时，先创建一个本地分支,
      git checkout -b task/132002
4 写完代码之后，也得运行一下pep8测试吧
      pep8 --count --repeat --show-source . 或者     ./run_tests.sh -p -N
5 或者也运行一下单元测试吧
      nosetests -s -v test_backend_sql.py && nosetests -s -v test_db_plugin:TestNetworksV2.test_list_shared_networks_with_non_admin_user
      或者 python -m testtools.run neutron.tests.unit.test_security_groups_rpc
      或者 python setup.py testr --slowest --testr-args='--subunit neutron.tests.unit.test_security_groups_rpc' | subunit2pyunit
      或者 ./run_test.sh -N testtools.run neutron.tests.unit.test_security_groups_rpc
6 提交代码到本地库
      git add -u (修改的文件），若创建了新文件 git add -i
      git commit
      提交信息的格式一般如下，一般分三段，第一段是标准说清楚你要做什么，如果你在改hyper-v模块最好有hyper-v的字眼，这样大家在收到邮件时只看标题就知道你在做什么了，这很重要；第二段简短描述；第三段一般使用“Fixed bug #161317"，＃号很重要，这样会自动在gerrit上链接到bug上。
      Add documentation for upgrading hyperv OpenStack compute node

      This guide covers how to upgrade and configure hyperv OpenStack
      compute node from Grizzly to Havana

      Fixed bug #161317
      如果是延用上次提交的信息使用命令：git commit --amend
7 本来在git review通过后gerrit会自动rebase到master分支的，但是有冲突的话没人帮你改，所以自己在git review前最好在本地做一个rebase操作，有冲突及时改：
      git rebase master 有冲突再解决冲突之后继续执行：git rebase --continue
8 提交代码评审
      git review -t <topic> 或者 git review master -t <topic>

这时会在gerrit服务器上创建一个本地分支：refs/for/master/task/132002, 如果上面改bug时不建分支的话，这里就变成了: refs/for/master，下一个人提交直接就被冲掉了。

9 如果社区上的jenkins出错，确定不是你自己的代码造成的，可以回复“recheck no bug” 触发重新检查，或者"recheck bug ###"

10 说说依赖提交，例如如果一个patch在社区已经被很多人+1了，但这时候有人希望提交一个相关的其他patch, 你当然不想破坏这么多已经+1的成果，所以你会希望再提一个patch但它会依赖前一个patch。注意两点：生成一个新的gerrit评审页是由Change-Id决定的；而是否在一个评审页上产生一个新的change set去破坏+1是由commit id决定的。所以只要保证前一个patch的commit id不变就行了，然后在这个基础上再提交一个patch再git review即可。当然，在git review之前最好先git rebase一下，不然如果本地git rebase的话就会产生一个新的commit id这样同样会产生一个新的change set，不过gerrit还比较智能，那些+1会自动添加上（Automatically re-added by Gerrit trivial rebase detection script.），　一个例子见：https://review.openstack.org/#/c/51375/

另外，如果是两个工程的依赖提交，可参见：Depends-On: <gerrit-change-id>” - Developer’s Guide — OpenDev Manual documentation

场景二：如何rebase代码
git rebase用于在一个分支中合并另一分支，举个例子，一家公司想要用OpenStack做二次开发的话，
在公司内部的git库里创建了三个分支：my-master, my-grizzly, my-havana
OpenStack的git库里的分支叫：    github-master, github-grizzly, github-havana
现在大家把内部代码都提交在my-havana分支，那么也需要时不时将社区的github-havana的代码rebase合并到my-havana分支中
1，首先在.git/config里要有两个remote分支，一个指向内部的版本库，一个指向github的版本库，如.git/config的相应配置如下：
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "my-origin"]
        fetch = +refs/heads/*:refs/remotes/my-origin/*
        url = git://<your_ip>/neutron.git
[remote "github-origin"]
        fetch = +refs/heads/*:refs/remotes/github-origin/*
        url = https://github.com/openstack/neutron.git
[branch "master"]
        remote = my-origin
        merge = refs/heads/master
[branch "my-havana"]
        remote = my-origin
        merge = refs/heads/my-havana
[branch "my-grizzly"]
        remote = my-origin
        merge = refs/heads/my-grizzly
2, 更新上面所有的remote分支 git remote update
3, 因为是要将社区的havana分支的代码同步到自己havana分支，所以为两个远程分支创建对应的本地分支
   git checkout -b github-havana github/stable/havana
   git checkout -b my-havana origin/my-havana
4, 合并，成功后应该用git log -1能看到一个新的合并提交。如果有冲突的话就解决冲突再git merge next
   git checkout my-havana
   git merget github-havana
5, 运行单元测试
tox --recreate -e py27,pep8
./run_tests.sh -V -f
6, 用-n参数(dry-run)测试提交, 提交到名为my-origin的远程分支的my-havana分支中：
   git push -n my-origin HEAD:refs/heads/my-havana
   若没有问题的话真正提交：
   git push my-origin HEAD:refs/heads/my-havana

场景三：cherry pick代码
例如，一个社区bug 1161195被提交到master分支, 社区没有批准进stable-havana分支，或者来不及等它进，这时候公司内部要求进my-havana分支的话，可以将这个bug通过cherry pick合并过来。

注：社区只能cherry-pick代码到stable branch, 例如，将commit cherry-pick到xena的话，社区应该先cherry-pick到stable/xena.　但实际debian包并不是base在stable/xena上的，而是base在19.1.0，那就仍然需要做SRU．cherry-pick可以在lp page上的按钮直接做，只有有冲突时才需要下面这些做
1, 为这个任务创建一个bug.
   git checkout -b stable/havana origin/stable/havana
   git pull
   git checkout -b bug/1161195
2, 在社区找到bug 1161195的代码提交id, 如:5f3fa391ed499750ad68ad5b000b4e2e0a86978e
   可以通过 git log |grep -B 30 <commit-id>查看确认
3, 在bug/1161195分支上执行cherry pick命令：
   git cherry-pick -s -x <commit-id>

如若master->A->B, 要先等A这个backport合并之后，再为A的commit-id来为B准备cherry-pick

若解决了冲突，还得在commit comment处添加例如如下，见：Stable Branches — OpenStack Project Team Guide documentation

Conflicts:
neutron/common/ovn/extensions.py

NOTE(xxx): The conflict is due to having change 666562a258c in Xena.

4, 提交代码评审
git commit or git commit --amend
git review stable-havana -t <topic>

另一个例子：

git clone https://github.com/openstack/charm-ceilometer
git checkout stable/16.07

# come from lauchpad page
git fetch git://git.openstack.org/openstack/charm-ceilometer refs/changes/00/375100/1 && git cherry-pick FETCH_HEAD

git review stable/18.07 -t <topic>

20201014更新, charm patch合并了, 要使用还得cherry-pick到stable branch, cherry-pick直接在review.opendev.org上就有一个'cherry-pick'按钮直接可以做不需要用这里的方法, 如果界面上失败那多半是因为这个fix已经在那个分支了. 在要做cherry-pick之后可以检查一下(Release schedule — charm-guide 0.0.1.dev448 documentation)下一个分支是不是马上要release了, 如果是也许就不需要做了.

场景四：将git产生的patch变成和svn兼容

#!/bin/sh
#
# git-svn-diff
# Generate an SVN-compatible diff against the tip of the tracking branch
REV=`git svn find-rev $(git rev-list --date-order --max-count=1 master)`
git diff --no-prefix $(git rev-list --date-order --max-count=1 master) $* |sed -e "s/^+++ .*/& (working copy)/" \
-e "s/^--- .*/& (revision $REV)/" \
-e "s/^diff --git [^[:space:]]*/Index:/" -e "s/^index.*/===================================================================/"

在本机上创建一个共享的git库：

sudo groupadd git
sudo useradd -d /home/git -m -g git git
sudo passwd git
su - git
mkdir /home/git/patent.git
cd patent.git/
git init --bare --shared

# test in another directory
cd /bak/tmp
git clone git@9.123.136.122:/home/git/patent.git
cd patent
cp test.doc .
git add test.doc
git commit -m "init commit"
git push origin master

这时候肯定是希望大家通过git用户可以访问git库，但又不希望他们通过ssh登录这台机器，所以修改/etc/passwd文件，

将 “ git:x:502:503::/home/git:/bin/bash ”

改成：git:x:502:503::/home/git:/usr/bin/git-shell

这时候还需要将每个客户端的公钥加到/home/git/.ssh/authorized_keys文件里，公钥可以通过ssh-keygen -t rsa生成。

场景五，使用git命令操作bzr与hg

sudo apt-get install mercurial python-hglib
wget https://raw.githubusercontent.com/felipec/git-remote-hg/master/git-remote-hg
wget https://raw.githubusercontent.com/felipec/git-remote-bzr/master/git-remote-bzr
sudo chmod 755 ./git-remote-*
sudo mv git-remote-* /usr/bin

examples:
git clone "bzr::lp:ubuntu/ifupdown"
git clone "bzr::lp:debian/ifupdown"
git clone "hg::http://anonscm.debian.org/hg/collab-maint/ifupdown/"

场景六，依赖提交

有一种情况，我向社区同时提交了两个有依赖的提交，在本地提交这两个提交之后直接git review即可。
现在前一个提交（假设提交id为：187f）要修改，怎么办呢？
a, git rebase 187f^ --interactive，回到要修改的提交的前一个点上
b, 修改那个提交，最后git commit --amend
c, git rebase --continue, 继续变基并且返回到原来的HEAD处
如果中间出现“interactive rebase already started”，用“git rebase -i --abort”命令重来。

场景七, 在lp上创建私有git仓库, 并使用lp评审代码

git clone https://git.launchpad.net/layer-snap

git remote set-url --push origin no_push

# 注意，这里有一个坑，下面链接不应该有+git，并且layer-snap必须和lp里实际的工程名字相同。

#如果有+git的话，提交PR时，原本指定target是layer-snap - [no description]，但它会自动变回~zhhuabj/+git/layer-snap:master

#并且可能会报这种错误”'~zhhuabj/+git/layer-snap:lp1847574 is not mergeable into layer-snap:master'“
# git remote add zhhuabj git+ssh://zhhuabj@git.launchpad.net/~zhhuabj/+git/layer-snap

git remote add zhhuabj git+ssh://zhhuabj@git.launchpad.net/~zhhuabj/layer-snap
git push --set-upstream zhhuabj master #then you will see the new repo in https://code.launchpad.net/~zhhuabj/+git

git remote -v
git branch -a
git fetch --all
git fetch --all --prune
#git fetch origin
#git checkout master
#git rebase origin/master

git checkout -b lp1847574
git commit -m 'test'
git commit --amend -author='Hua <xxx.mail.com>'
git push --set-upstream zhhuabj lp1847574

#如果更新了代码再提交时如果rebase后可能需要添加-f参数, 这里pr将保持不变 - Why do I have to "git push --set-upstream origin <branch>"? - Stack Overflow

The -f is actually required because of the rebase. Whenever you do a rebase you would need to do a force push because the remote branch cannot be fast-forwarded to your commit. You'd always want to make sure that you do a pull before pushing, but if you don't like to force push to master or dev for that matter, you can create a new branch to push to and then merge or make a PR.

# git push -f --set-upstream zhhuabj lp1847574

# Propose for merging - https://code.launchpad.net/~zhhuabj/+git/layer-snap/+ref/lp1847574
# ~zhhuabj/+git/layer-snap:lp1847574 -> layer-snap:master
#target repository -> other: ~openstack-charm-testers/xxxstack-bundles/+git/xxxstack-bundles
target repository -> other: https://git.launchpad.net/layer-snap
target branch: refs/heads/master

场景八: 内核

git remote add xenial git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
git fetch xenial
git log --no-merges --oneline xenial/hwe...xenial/master drivers/net/ethernet/mellanox/mlx5/

git cherry 19.3.0 19.4.0 -v

场景九：确认charm-ceilometer-278是否包括fix d398cd

https://api.jujucharms.com/charmstore/v5/ceilometer-278/archive/repo-info

$ git branch -r -v |grep e06571
  origin/stable/20.10 e06571c Updates for stable branch creation

$ git branch -r --contains  d398cd |grep 20.10
  origin/stable/20.10

其它命令：

git reset HEAD~1 撤销最后一次提交。
git reset --hard HEAD^ 撤销最后一次提交并清除本地修改

git reset --hard Merge_Head 和服务器保持一致

git clean -dfx 删除本地未在版本库的东西

git stash & git stash list & git stash pop 暂存代码

git rebase -i --abort

git tag --contains af055e37a91d215d7174d0b84c86795ca81086a7

git branch -a --contains <sha1>

git tag --contains <sha1>

git grep smp_call_function_many

# refer 9. Viewing History - Git Pocket Guide [Book]

git log v4.13..master --oneline --no-merges kernel/smp.c

git log v4.13..master --grep=smp --oneline --no-merges kernel/smp.c

git log |grep Ibaf4385 一个patch只有一部分，另一部分肯定是被其他patch覆盖了，可用'git log'查找

git revert 7b60534

git cherry -v 16.4.1 16.4.2

PR development

#Click 'Fork' button in https://github.com/openstack-charmers/zaza-openstack-tests.git
git clone git@github.com:zhhuabj/zaza-openstack-tests.git
cd zaza-openstack-tests
git config user.name
git config user.email
git remote add upstream https://github.com/openstack-charmers/zaza-openstack-tests.git
git remote set-url --push upstream no_push

git remote -v
git branch -a
#git fetch --all
#git fetch --all --prune
git fetch upstream         #git fetch upstream master
git checkout master        #switch to local master
git rebase upstream/master #update master
git push -f origin master  #push to orign's master

git checkout -b hm-port
patch -p1 < 0001-Delete-hm-port-on-unit-removal.patch
git add -u
git commit
git push origin hm-port

#Create PR
#https://github.com/zhhuabj/zaza-openstack-tests/branches
#Open the page - https://github.com/zhhuabj/zaza-openstack-tests/pull/new/hm-port
#then Click 'Create pull request' button
#see https://github.com/openstack-charmers/zaza-openstack-tests/pull/600/

#reivew other's patches
https://github.com/openstack-charmers/zaza-openstack-tests/pulls

#Update RP

git checkout master
#git fetch upstream
#git merge upstream/master  #or git rebase upstream/master
git pull upstream master
git push origin master -f   #注意：不要随便使用-f

git checkout hm-port
#git rebase -i upstream/master　＃ if don't run 'git push origin master -f' above
git merge origin/master          # already run 'git push origin master -f' above

git commit -a
git push origin hm-port -f #注意：不要随便使用-f

# then PR will be updated automatically
注意：不要随便使用 -f, -f容易覆盖掉别人新增的commits. 当然，我们这里可以不会，因为我们有PR或者
# gerrit做中转，每个人往PR或者gerrit并且是自己的分支上提交，被批准之才往upstream合并
# commits，顶多是upstream有更新了，本地合并时有冲突rebase一下．这样是安全的．
# 但没有PR或gerrit，几个人同时往一个git库里提交时，并且都往master分支里提交时，如果乱使用-f容
# 易出问题．此时，即使采用'git commit --amend'来提交--amend也可能造成上游commit更改．
# 如果采用'git rebase -i'来合并commits的话更可能给合作者造成困扰．
# 具体到PR这里，如果采用-f，虽然不会覆盖代码，但也可能造成PR上无法看到各commits之间的差异．
# 最好采用下列方法更新PR(采用git pull --rebase):
git checkout master
git pull --rebase upstream master
#git push origin master -f
 
git checkout hm-port
#git rebase origin/master
git rebase upstream/master hm-port
 
git commit -a
git push origin hm-port

参考：https://www.cnblogs.com/kevingrace/p/5896706.html
git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase

注意:　但是对于PR (https://github.com/openstack-charmers/zaza-openstack-tests/pull/600/) 又要求使用'git merge'代替'git rebase'和不使用'--amend'来保留review history, 这样在PR合并之后再一起合到master里去．

git checkout master
#git pull --rebase upstream master
git fetch upstream
git merge upstream/master
git push orign master    #do not use '-f'

git checkout hm-port
#git rebase upstream/master hm-port
git fetch origin
git merge origin/master

git commit               #do not use '--amend'
git push origin hm-port  #do not use '-f'

# 20211012更新，这种不用git rebase改用git merge来保留PR历史的情况，最好在新建patch时不要更新代码
# 直接在旧代码上做新patch，有冲突了再和他们商量是rebase还是merge 
# rebase时自己的代码会在最上面。merge时自己的代码混在其中并且还会多出merge commit
# 如果已经用上面的代码merge了，可以用下列命令回到之前的

$ git reflog
1b7b3d7 (HEAD -> hm-port) HEAD@{0}: merge origin/master: Merge made by the 'recursive' strategy.
d353f3c (origin/hm-port) HEAD@{1}: checkout: moving from master to hm-port
$ git reset --hard d353f3c

# 20211028更新，有冲突了直接merge就行
git checkout master
#git pull --rebase upstream master
git fetch upstream
git merge upstream/master
git checkout hm-port
git merge master
git push origin hm-port
git push origin master    #do not use '-f'

k8s PR Process

cd /bak/golang/src/k8s.io
git clone https://github.com/kubernetes/kubernetes
cd kubernetes
#fork kubernetes project - https://github.com/zhhuabj/kubernetes
git remote add zhhuabj git@github.com:zhhuabj/kubernetes.git
git remote set-url --push origin no_push
git remote -v
git branch -a

git fetch origin
git checkout master
git rebase origin/master

git checkout cri_stat
git rebase origin/master cri_stat
git commit --amend --author="Zhang Hua <xxx@gmail.com>"

go test -v -run TestExtractIDFromCgroupPath k8s.io/kubernetes/pkg/kubelet/stats
alias testcases="sed -n 's/func.*\(Test.*\)(.*/\1/p' | xargs | sed 's/ /|/g'"
go test -v -run $(cat pkg/kubelet/stats/cri_stats_provider_test.go | testcases) k8s.io/kubernetes/pkg/kubelet/stats
git push zhhuabj cri_stat  #do not use '-f'

#创建一个issue, - https://github.com/kubernetes/kubernetes/issues/106514
#一般输入/sig node 之后（这个可能应该由reviewers来做），之后reviewers也得做：/triage accepted
#好像一般自己不做/assign， 因为只有项目的owner才能merge， 一般是在pr被review之后由reviewers使用/assign <owner>来merge RP

#提交PR - https://github.com/kubernetes/kubernetes/pull/106515
# 上步创建issue时跟着提示填写会自动按模板生成bug description. 这里提PR时的comment可根据下节的模板做
# https://prow.k8s.io/command-help
/release-note-none
/kind bug
# 模板里已经有了上面的release-not与kind，所以就不需要上面命令再做了

# reviewers接着设置priority与lgtm，最后assign给有权限merge的人
/priority important-soonish
/lgtm
# for approvals, please assign xxx after the PR has been reviewed.
/assign @xxx
也可以 /cc @xxx 通知谁来评审

也可参考：K8s 系列(二) - K8s PR 怎样才能被 merge？ -https://segmentfault.com/a/1190000040437510

如何backport
在RP被merge到master之后，并且可能被reviewers标记成priority/critical-urgent的patch才能backport
见：
https://kubernetes.io/zh/docs/contribute/generate-ref-docs/contribute-upstream/
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md

注意，创建issue时跟着提示填写会自动按模板生成bug description. 对于提PR时的comment可根据下列模板做：

Extract containerID from system.slice/containerd.service style cgroupPath

### What type of PR is this?

/kind bug

### What this PR does / why we need it:

PR #104039 handles one style cgroupPath,

kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2fc932ce_fdcc_454b_97bd_aadfdeb4c340.slice/cri-containerd-aaefb9d8feed2d453b543f6d928cede7a4dbefa6a0ae7c9b990dd234c56e93b9.scope

but not the following style cgroupPath, so there is this PR.

system.slice/containerd.service/kubepods-burstable-pod36b6d6be73b1065af369b3985edafa09.slice:cri-containerd:79fedb3bd23ca77c9d9ccb41909038316f713df22b54b7d942b71d3812e7c74e

### Which issue(s) this PR fixes:

Fixes #106514

### Special notes for your reviewer:


### Release note:

NONE

### Special notes for your reviewer:

### Does this PR introduce a user-facing change?

### Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

如何backport?

在RP被merge到master之后，并且可能被reviewers标记成priority/critical-urgent的patch才能backport
见： https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md5
k8s每年3个版本，1.23将是2021年的最终版本 - https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/
https://github.com/kubernetes/sig-release/blob/master/release-engineering/versioning.md
X.Y.Z (X is the major version, Y is the minor version, and Z is the patch version.)
X.Y.0-{alpha,beta}.W, W>0, alpha与beta版本
X.Y.Z-rc.W (Branch: release-X.Y), rc版本
X.Y.0 (Branch: release-X.Y), 最终release版本
X.Y.Z, Z > 0 (Branch: release-X.Y)
hua@t440p:/bak/golang/src/k8s.io/kubernetes$ git tag |grep v1.22
v1.22.0
v1.22.0-alpha.0
v1.22.0-alpha.1
v1.22.0-alpha.2
v1.22.0-alpha.3
v1.22.0-beta.0
v1.22.0-beta.1
v1.22.0-beta.2
v1.22.0-rc.0
v1.22.1
v1.22.1-rc.0
v1.22.2
v1.22.2-rc.0
v1.22.3
v1.22.3-rc.0
v1.22.4
v1.22.4-rc.0
v1.22.5-rc.0

最多支持3个版本，也就是说当v1.23出来之后，v1.20就不再支持。最新的v1.23.0将在20211215发布，参见：https://www.kubernetes.dev/resources/release/
基本上是一个月一做patch release（eg: origin/release-1.22), 见：https://kubernetes.io/releases/patch-releases/

backport只能到patch release版本中去（也就是origin/release-1.22), 
最新的到1.22未批准的cherry-pick: 
https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Ado-not-merge%2Fcherry-pick-not-approved+base%3Arelease-1.22
backport的一个例子： https://github.com/kubernetes/kubernetes/pull/106338
backport必须被release manager批准 - https://kubernetes.io/releases/release-managers/

OpenStack SRU

例如，要求将commit 8a890ed29 backport到xena release. 代码已经在yogo 20.0.0中，目前最新稳定分支是yoga release


UA支持Jammy和Focal, Impish已经EOL可以不管　－　https://ubuntu.com/about/release-cycle#ubuntu
UCA支持Xena到2023/04 - https://ubuntu.com/about/release-cycle#openstack-release-cycle
commit理论上应该先进Upstream Xena, 然后直接进Focal的UCA cloud-archive:xena即可(本来应该one by one, 但它已经在20.0.0也就是yoga中)，不需要关心UA因为xena不是UA的base(Focal的base是Victoria)
但是社区只能cherry-pick到stable/xena，不能cherry-pick到19.1.0，再继续SRU到19.1.0

Upstream支持Xena到2021/10, 但是Extended Maintenance到2023/04 (https://releases.openstack.org/), 也就是说符合这些定义（https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes）的fix在2023/04还是可以进Xena的.

注意两点：
１，上面是代码已经在yoga，要sru到xena中，如果是要sru到Wallaby呢，那得一个个来，先到xena到再Wallaby
２，上面要sru的xena不是base, 如果是要sru到base的Victoria呢？先是upstream，代码得依次merge到xena再到wallaby再到victoria, 然后sru到uca-xena再到uca-wallaby, 还得到ua-victoria再到uca-victoria(通过这步是自动做的), 至于uca还得考虑release(如focal, xenial)是否EOL

20220505 - 运行'hexo deploy'时报:kex_exchange_identification

$ ssh -T git@github.com
kex_exchange_identification: Connection closed by remote host
$ proxychains ssh -T git@github.com
kex_exchange_identification: Connection closed by remote host

# change to another proxy type, so that's because proxy server-side has disabled
# 22 port for github.com, or change to use port 443 instead,
# see https://idreamshen.github.io/posts/github-connection-closed/
$ proxychains ssh -T git@github.com
Hi xxx! You've successfully authenticated, but GitHub does not provide shell access

20230803 - Launchpad git PR

$ grep -r 'git.launchpad.net' ~/.gitconfig  -A1
[url "git+ssh://zhhuabj@git.launchpad.net/"]
        insteadof = lp:

#https://code.launchpad.net/charm-prometheus-openstack-exporter
git clone https://git.launchpad.net/charm-prometheus-openstack-exporter prometheus-openstack-exporter
cd prometheus-openstack-exporter
git remote add zhhuabj git+ssh://zhhuabj@git.launchpad.net/~zhhuabj/charm-prometheus-openstack-exporter
git remote set-url --push origin no_push

git remote -v
git branch -a
git fetch --all
git fetch --all --prune
#git fetch origin
#git checkout master
#git rebase origin/master

git checkout -b lp2029445
git add -u
git commit
git push zhhuabj lp2029445

#submit PR
https://code.launchpad.net/~zhhuabj/charm-prometheus-openstack-exporter/+git/charm-prometheus-openstack-exporter/+ref/lp2029445/+register-merge
https://code.launchpad.net/~zhhuabj/charm-prometheus-openstack-exporter/+git/charm-prometheus-openstack-exporter/+merge/448328

20230914 - cherry-pick for github PR

git checkout master & git pull
git checkout zed
git checkout -b zed_lp2021550 origin/stable/zed
git cherry-pick -s -x 996f2410632b44a7dc207cc4bbfc1a38c83140a8 1a90eb03052102a2e8d906262f97e7f3ff87fcdc
git push zhhuabj zed_lp2021550
#select stable/zed for base repo, and zed_lp2021550 for header repo
PR - https://github.com/zhhuabj/charm-helpers/pull/new/zed_lp2021550

20231020 - git review -t

运行git review记得-t为各个不同工程下不同branch设置相同的topic (不用-t显示设置的话默认会用branch name), eg: https://review.opendev.org/q/topic:bug%252F2021550

#https://bugs.launchpad.net/horizon/+bug/2054799/comments/19
$ git log --oneline origin/stable/2024.1 | grep -m1 'Fix Users/Groups tab list when a domain context is set'
3fce54017985 Merge "Fix Users/Groups tab list when a domain context is set" into stable/2024.1
$ git describe 3fce54017985
24.0.0-5-g3fce54017985

20231023 - 使用GPG加密git commit

参考：【精选】用OpenSSL做自签名的证书(by quqi99)_openssl code-signin_quqi99的博客-CSDN博客
1, 使用‘gpg --armor --export $GPGKEY’命令导出GPG public key, 然后更新到git页面 https://github.com/settings/keys
2, 使用'git commit --amend --author="Zhang xxx <xxx.zhang@xxx.com>" -S<GPG_private_key>' 加密git commit, 注意，如果看到这个错误“error: gpg failed to sign the data”，那是一是邮箱名要正确，二是-S后接GPG_private_key (这个可以通过命令：gpg --list-secret-keys --keyid-format LONG 查看）

3, 验证： git log --show-signature
4, 运行git push zhhuabj lp2039403 -f 后从PR页（https://github.com/canonical/snap-openstack/pull/42）可以看到commit后有一个"Verified"状态了