发布分布式源代码控制系统 。 Git 是最流行、可靠和高性能的版本控制系统之一，提供基于分支和合并的灵活的非线性开发工具。 为了确保历史记录的完整性和对追溯更改的抵抗力，在每次提交中使用整个先前历史记录的隐式哈希，并且还可以使用开发人员的数字签名来验证各个标签和提交。
与之前版本相比，新版本包含 745 处变更，由 74 名开发人员参与准备，其中 18 名开发人员首次参与开发。 :
- 自版本 1.18 起，新的提交变基模式“git rebase --rebase-merges”取代了旧的“--preserve-merges”选项，该选项现已弃用。 “git rebase”操作用于用新的基础提交替换一系列提交，例如，将正在开发某些新功能的单独分支移动到主分支的当前状态，其中包括在分支之后添加的修复：
o - o - o（我的功能）
/
o - o - o - o - o（主）
o - o - o（我的功能）
/
o - o - o - o - o（主）
为了保留迁移分支中的分支结构，以前可以使用“--preserve-merges”选项，当以交互模式运行时（git rebase -i --preserve-merges），允许编辑提交历史记录，但是不保证存储库结构的完整保存。 新的“--rebase-merges”模式允许您保留正在迁移的分支中的更改结构，同时提供全方位的交互式操作，包括删除、重新分组和重命名提交。
例如，“--rebase-merges” 将提交从单独的分支重新上传到较新的主分支，同时维护迁移分支中的分支结构，并即时对提交注释进行一些更改。
- 添加了对使用结构“git Branch new A...B”和“git checkout -b new”确定其他两个分支的合并基础（合并基础，绑定到共同祖先）的结果创建新分支的支持A...B”，其中“A ...B”涉及在两个指定提交之间定义合并基础，类似于“git checkout A...B”将 HEAD 转移到基础提交和“diff A.A.A.B”如何将 HEAD 转移到基础提交。 ..B”显示了提交“B”和提交“A”之间的更改“Ancestor.
例如，在处理单独的 my-feature 分支时，如果您想要从不同的分支开始，例如从 master 分支中签出 my-feature 分支的同一位置开始，则可以使用此功能。 以前，这需要手动检查更改日志，如果您有大量更改历史记录，这会很不方便，然后运行“git merge-base master my-feature”来计算 master 和 my-feature 分支之间的合并基础的哈希值并创建一个相对于共同祖先“gitbranchmy-other-featurehash”的新分支。 在 Git 2.22 中，您可以使用语法“gitbranch my-other-feature A...B”来创建相对于其他两个分支的合并基础的分支；
- 添加“gitbranch --show-current”选项，用于显示结账操作时获取的分支名称；
- 添加了“git checkout —no-overlay —dir”选项，该选项允许在执行签出操作时将 dir 目录的内容转换为完全对应于 master 分支状态的形式。 例如，如果 dir 目录的本地副本中有一个文件不在 master 分支中，那么默认情况下执行“git checkout master - dir”时它将被保留，如果“--no-overlay” ” 选项被指定，它将被删除；
- “git diff”命令使用通用 API 来解析选项，这使得可以与其他 git 实用程序统一选项处理。 例如，在“git diff”中，所有选项现在都有其对立面（“--function-context”和“--no-function-context”）；
- 添加了过滤附加到“git log”输出中的提交的扩展标签的功能（“trailer” - 附加信息标志，例如 Signed-off-by 和 Co-authored-by）。 可以按键和值过滤标签，例如：
"git log --pretty="%(预告片:key=审核者,valueonly)"; - 添加了新的跟踪引擎 Trace2，提供更灵活和结构化的输出格式。 Trace2允许您收集有关已执行操作和性能数据的遥测数据，以进行更详细的分析和调试（处理程序由用户分配，不向外部发送数据）；
- “git bisect”报告变得更具可读性，其中有问题的提交现在更清晰地突出显示，并显示每个文件更改的摘要统计信息（在更改的行数级别）；
- 用于确定目录重命名的启发式方法已被重新设计，以消除重命名标签的错误安装。 如有疑问，此类目录现在会被标记为冲突；
- 当您尝试在另一个标签上安装一个标签时，会显示一条警告，这通常是错误的，可能会导致在错误的提交上设置标签（例如，像“git tag -f -m “updated message”这样的结构） my-tag1 my- tag2”将导致在旧标签上创建标签，而开发人员希望将新标签安装在旧标签指向的提交上）；
- 启用了位图存储库（基于磁盘的“可达性位图”结构）的生成，它存储有关每次提交可用的对象集的数据，并允许您快速确定基础对象是否存在。 这种结构显着减少了数据检索操作（git fetch）的执行时间。
来源： opennet.ru