显示标签为“git”的博文。显示所有博文

2022年2月28日星期一

使用gpg签署git

gpg

即GNU Privacy Guard（GnuPG或GPG）是一个密码学软件，用于加密、签名通信内容及管理非对称密码学的密钥，是自由基金会开发的OpenPGP软件，遵循OpenPGP数据加解密标准（RFC 4880），与PGP保持兼容。

使用方法见：https://daemonyang.blogspot.com/2021/12/gpg.html

查看本地`gpg`密钥列表

$ gpg -k

创建`gpg`密钥

$ gpg --gen-key

`git`默认`gpg`密钥

可以配置全局/本地的默认签名密钥

添加到全局

$ git config --global user.signingkey 23E3B35D753BC78E

或者使用--local配置单个项目

$ git config --local user.signingkey 23E3B35D753BC78E

配置的默认签名密钥可供git commit和git tag使用

使用`gpg`签名提交

使用-S[<keyid>], --gpg-sign[=<keyid>]选项指定git commit使用的gpg签名

keyid为可选项，如果指定，必须紧挨着-S，中间不能有空格；如果不指定，则使用提交者信息Your Name <your@email.address>来查找gpg密钥并使用；如果配置了user.signingkey，则采用user.signingkey配置的默认gpg密钥进行签名

譬如gpg签名密钥的ID为23E3B35D753BC78E

$ git commit -S23E3B35D753BC78E -m "commit message"

或

$ git commit --gpg-sign=23E3B35D753BC78E -m "commit message"

通过git log --show-signature可以查看带签名信息的提交记录

`commit.gpgSign`强制签名

可以设置commit.gpgSign配置项，强制git commit使用gpg密钥签署每个提交：

$ git config --global commit.gpgsign true

或者使用--local配置单个项目

$ git config --local commit.gpgsign true

取消强制签名配置

使用--no-gpg-sign选项取消commit.gpgsign配置项设置的强制签名限制

使用`gpg`签名`tag`

`-s`默认密钥签名

git tag命令使用-s, --sign选项时，会根据提交者信息Your Name <your@email.address>来查找gpg密钥用来签署tag；如果配置了默认签名密钥user.signingkey，则使用默认密钥进行签名。示例：

$ git tag -s v1.0.1 -m "tag v1.0.1"

如果你不希望使用自定义gpg密钥，可以配置默认签署密钥：

$ git config --global user.signingkey 23E3B35D753BC78E # 或者使用--local配置单个项目

签署完成可以使用git show来查看：

$ git show v1.0.1
tag v1.0.1
Tagger: Ben Straub <ben@straub.cc>
Date:   Sat May 3 20:29:41 2014 -0700

tag v1.0.1
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJTZbQlAAoJEF0+sviABDDrZbQH/09PfE51KPVPlanr6q1v4/Ut
LQxfojUWiLQdg2ESJItkcuweYg+kc3HCyFejeDIBw9dpXt00rY26p05qrpnG+85b
hM1/PswpPLuBSr+oCIDj5GMC2r2iEKsfv2fJbNW8iWAXVLoWZRF8B0MfqX/YTMbm
ecorc4iXzQu7tupRihslbNkfvfciMnSDeSvzCpWAHl7h8Wj6hhqePmLm9lAYqnKp
8S5B/1SSQuEAjRZgI4IexpZoeKGVDptPHxLLS38fozsyi0QyDyzEgJxcJQVMXxVi
RUysgqjcpT8+iQM1PblGfHR4XAhuOqN5Fx06PSaFZhqvWFezJ28/CLyX5q+oIVk=
=EFTF
-----END PGP SIGNATURE-----

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

`-u`自定义密钥签名

可以使用-u <keyid>, --local-user=<keyid>选项手动指定gpg密钥：

$ git tag -u 23E3B35D753BC78E v1.0.1 -m "tag v1.0.1"

`tag.gpgSign`

可以设置tag.gpgSign配置项，强制git tag使用gpg密钥签署每个tag：

$ git config --global tag.gpgsign true

或者使用--local配置单个项目

$ git config --local tag.gpgsign true

注意，-u <keyid>, --local-user=<keyid>选项不受这个配置项控制

`--no-sign`取消强制签名配置

使用--no-sign选项取消tag.gpgSign配置项设置的强制签名限制

`git merge`合并

`--verify-signatures`检查签名

git merge命令可以使用--verify-signatures选项检查并拒绝携带可信密钥签署的提交：

$ git merge --verify-signatures non-verify-branch
fatal: Commit ab06180 does not have a GPG signature.

`-S`签署合并生成的提交

-S[<keyid>], --gpg-sign[=<keyid>]选项使用方式与git commit的同名选项相同，可以为合并生成的提交使用密钥进行签署

$ git merge --verify-signatures -S  signed-branch
Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <schacon@gmail.com>

You need a passphrase to unlock the secret key for
user: "Scott Chacon (Git signing key) <schacon@gmail.com>"
2048-bit RSA key, ID 0A46826A, created 2014-06-04

Merge made by the 'recursive' strategy.
 README | 2 ++
 1 file changed, 2 insertions(+)

`git pull`拉取提交

`--verify-signatures`检查签名

git pull命令也可以使用--verify-signatures选项检查并拒绝携带可信密钥签署的提交：

$ git pull --verify-signatures origin master
fatal: Commit ab06180 does not have a GPG signature.

`-S`签署合并生成的提交

-S[<keyid>], --gpg-sign[=<keyid>]选项使用方式与git merge相同，可以为合并生成的提交使用密钥进行签署

$ git pull --verify-signatures -S  signed-branch

`git push`推送

`--no-signed`、`--signed=false`

不签署推送

`--signed`、`--signed=true`

签署推送，如果服务器不支持签署推送，则推送失败

`--signed=if-asked`

如果服务器支持签署推送，则签署；不支持则不签署，不会直接失败

git rebase

`-S`签署变基生成的提交

-S[<keyid>], --gpg-sign[=<keyid>]选项使用方式与git merge相同，可以为变基生成的提交使用密钥进行签署

$ git rebase -S  signed-branch

`AndroidStudio`使用`gpg`签名

修改配置文件：

# Linux/macOS
~/.gnupg/gpg.conf
# Windows 10
C:\Users\<user name>\.gnupg\gpg.conf

添加：

use-agent
no-tty
default-key 23E3B35D753BC78E

`Windows`无法找到`gpg`密钥问题

git commit -a -S -m "modify .gitignore file"
gpg: skipped "A012BF1DEF404999678A307A23E3B35D753BC78E": No secret key
gpg: signing failed: No secret key
error: gpg failed to sign the data
fatal: failed to write commit object

解决

https://stackoverflow.com/a/51009405

$ git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe"

参考

Telling Git about your signing key

https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification

Set up Keybase.io, GPG & Git to sign commits on GitHub

Android Studio and Git - How do I GPG-sign my commits?

2017年6月29日星期四

Git分支管理策略 -- Git-Flow

Git-Flow是2010年Vincent Driessen在他的博客中提出的一个git分支模型，是最流行的分支模型。

分支类型

Git-Flow包含了两大类共五小类分支类型，下面我们一一介绍：

主分支（main branches）
1. master
2. develop
辅助分支（supporting branches）
1. Feature branches
2. Release branches
3. Hotfix branches

主分支

主分支包括master和develop分支，这两个分支作为主分支，始终存在于远程仓库中。

`master`分支

master分支是git仓库创建后自动创建的分支。最终测试通过的正式版本都是在这个分支上发布的。

`develop`分支

develop分支最初由master分支分出来，这个分支用来反映下一个发布状态的最新代码。我们在发布下一个版本时，首先要将功能分支开发完成的功能在develop分支中合并、整理，达到稳定状态时才会创建预发布分支进行发布准备。

创建`develop`分支

$ git checkout -b develop master
Switched to a new branch 'develop'

辅助分支

辅助分支在开发中属于临时性的分支，在使用完成后都可以删除。

功能分支（Feature branches）

Branch off	Merge back
develop	develop

功能分支一般从develop分支分出，用来开发新功能新特性。这个分支最终会合并到develop分支（如果不需要这个功能了，也可以放弃这个分支的合并并删除）。

功能分支一般只存在于开发者本地仓库，不需要推送到origin仓库。在合并到develp或抛弃后，删除这个分支。

创建功能分支

下面我们从develop分支创建feature-1功能分支：

$ git checkout -b feature-1 develop
Switched to a new branch 1feature-1'

合并功能分支到`develop`

功能开发完成，准备发布下一个发布版本时，先合并到develop分支：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff feature-1
Merge made by the 'recursive' strategy.
 build.gradle                      | 7 +++++++
 src/main/java/me/daemon/Main.java | 7 +++++++
 2 files changed, 14 insertions(+)
 create mode 100644 build.gradle
 create mode 100644 src/main/java/me/daemon/Main.java
$ git branch -d feature-1
Deleted branch feature-1 (was c6fc6e6).
$ git push origin develop

预发布分支（Release branches）

Branch off	Merge back
develop	develop and master

预发布分支用来准备新版本的发布。

我们在开发中，一个版本可以包含多个功能或特性的开发，可能需要多个功能分支并行开发。当这些功能都开发完成后，准备发布时，先将这些功能分支合并到develop分支，然后从develop分支分出预发布分支。

当分出预发布分支后，我们可以用这个分支用来提测，修复bug等，这样develop分支就可以继续进行下一个版本的开发工作，新版本的功能分支可以合并到develop分支而不影响上一个版本的测试、修复BUG、发布等工作。

创建预发布分支

从develop分支创建预发布分支release-v0.1：

$ git checkout -b release-v0.1 develop
Switched to a new branch 'release-v0.1'

创建预发布分支后，在该分支上修改发布版本号，然后提交修改。

完成预发布分支

在预发布分支通过最终测试，准备发布时，需要合并到master和develop分支。

首先合并到master并打上tag：

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git merge --no-ff release-v0.1
Merge made by the 'recursive' strategy.
 build.gradle                         | 9 +++++++++
 src/main/java/me/daemon/Feature.java | 7 +++++++
 src/main/java/me/daemon/Main.java    | 7 +++++++
 3 files changed, 23 insertions(+)
 create mode 100644 build.gradle
 create mode 100644 src/main/java/me/daemon/Feature.java
 create mode 100644 src/main/java/me/daemon/Main.java
$ git tag -a v0.1 -m "tag v0.1"

然后合并到develop：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-v0.1
Merge made by the 'recursive' strategy.
 build.gradle | 2 ++
 1 file changed, 2 insertions(+)

此时，该预发布分支的使命已经完成，可以删除该预发布分支：

$ git branch -d release-v0.1
Deleted branch release-v0.1 (was 7942f36).

BUG修复分支（Hotfix branches）

Branch off	Merge back
master	develop and master

BUG修复分支类似与预发布分支，都是用来准备下一个版本的发布。不同的是，预发布版本是我们计划好的功能与特性集合的发布，而BUG修复版本是为了紧急修复当前发布版本的BUG而存在的。

一般我们开发中遇到的非致命、非紧急的BUG往往选择随同下个版本一起发布，只有遇到致命问题才需要立即在当前发布版本基础上分出分支，修改BUG，并立即发布下一个版本。因此BUG修复分支一般是从master分支分出的。修复完成后要合并到master及develop分支。

创建BUG修复分支

从master分支创建BUG修复分支hotfix-1.0.1：

$ git checkout -b hotfix-0.1 master
Switched to a new branch 'hotfix-0.1'

在hotfix-1.0.1上升级版本号、修复BUG，然后提交修改。

完成BUG修复

首先合并到master并打tag：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-0.1
Merge made by the 'recursive' strategy.
 src/main/java/me/daemon/Feature.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git tag -a v0.2 -m "tag v0.2"

然后合并到develop：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-0.1
Merge made by the 'recursive' strategy.
 src/main/java/me/daemon/Feature.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

这里要注意，如果此时存在一个预发布分支，准备发布下一个版本，那么BUG修复分支的修改要合并到预发布分支，而不是develop分支。而在预发布分支发布后，BUG修复的代码会随着发布的代码一起合并到develop。

最终，可以删除BUG修复分支：

$ git branch -d hotfix-0.1
Deleted branch hotfix-0.1 (was 17dd42a).

推送远程仓库

将分支都推送到远程仓库：

$ git push --all

推送tag：

$ git push origin v0.1
$ git push origin v0.2

也可以一次推送所有tag：

$ git push origin --tags

示例

我将示例放到我的github上，地址为：https://github.com/daemon369/git-flow-demo。为了演示，辅助分支没有删除。

图示

参看

A successful Git branching model

Git分支管理策略

topic分支和merge分支的运用实例

订阅：博文 (Atom)

2022年2月28日星期一

使用gpg签署git

gpg

查看本地gpg密钥列表

创建gpg密钥

git默认gpg密钥

使用gpg签名提交

commit.gpgSign强制签名

取消强制签名配置

使用gpg签名tag

-s默认密钥签名

-u自定义密钥签名

tag.gpgSign

--no-sign取消强制签名配置

git merge合并

--verify-signatures检查签名

-S签署合并生成的提交

git pull拉取提交

--verify-signatures检查签名

-S签署合并生成的提交

git push推送

--no-signed、--signed=false

--signed、--signed=true

--signed=if-asked

git rebase

-S签署变基生成的提交

AndroidStudio使用gpg签名

Windows无法找到gpg密钥问题

解决

参考

2017年6月29日星期四

Git分支管理策略 -- Git-Flow

分支类型

主分支

master分支

develop分支

创建develop分支

辅助分支

功能分支（Feature branches）

创建功能分支

合并功能分支到develop

预发布分支（Release branches）

创建预发布分支

完成预发布分支

BUG修复分支（Hotfix branches）

创建BUG修复分支

完成BUG修复

推送远程仓库

示例

图示

参看

Android logcat

查看本地`gpg`密钥列表

创建`gpg`密钥

`git`默认`gpg`密钥

使用`gpg`签名提交

`commit.gpgSign`强制签名

使用`gpg`签名`tag`

`-s`默认密钥签名

`-u`自定义密钥签名

`tag.gpgSign`

`--no-sign`取消强制签名配置

`git merge`合并

`--verify-signatures`检查签名

`-S`签署合并生成的提交

`git pull`拉取提交

`--verify-signatures`检查签名

`-S`签署合并生成的提交

`git push`推送

`--no-signed`、`--signed=false`

`--signed`、`--signed=true`

`--signed=if-asked`

`-S`签署变基生成的提交

`AndroidStudio`使用`gpg`签名

`Windows`无法找到`gpg`密钥问题

`master`分支

`develop`分支

创建`develop`分支

合并功能分支到`develop`