Git查看历史记录小技巧

分享两个Git的小技巧， 都是关于在 IDEA 里查看Git的历史记录的。

这两个技巧，简单却实用。面对年代久远、团队人员流失严重的代码，靠的就是这两个技巧, 从提交记录里品读岁月史书，从蛛丝马迹中寻找遗失的真相。

mr.py

操作 Gitlab MR 的命令行工具的源码与测试代码。

操作 Gitlab MR 的命令行工具

背景

为什么开发这个工具？主要解决以下问题：

1. 提测、上 UAT 时，避免漏合代码。
2. 代码冲突时，团队成员不用再问“解决这个冲突要怎么切分支？”
3. 一个 feature 分支要向多个保护分支提交合并请求时，减少烦琐而易错的选取分支的界面操作。

可能会有人问：为什么会漏合代码？当你在某一个迭代需要来回在不同的 feature 分支切换、一个 feature 横跨多个项目，同时你偶尔还要兼顾 bug 修复的时候，你极容易丢失上下文。
并且，不同的 feature 研发进度不一致，可能出现的一种情况是：feature A 只是合并到 test 分支，但　feature B 却已经合并到了 uat。
对此，有人问你代码到底合并了没，你怎么确认？一个个项目去相应的主干分支里查看提交历史吗？就是因为不想再这样做了，这才有了这个工具。

GitLab CI

前言

GitLab 在企业内部还是比较通用的，其 CI 用起来个人也觉得比 Jenkins 顺手，因此在这里分享一下相关的实践经验。

Git代码合并指南

前言

合并时代码常见问题是冲突、提交错代码以及合并错分支，本文将说明这些问题的解决方案，为代码合并打下坚实的基础，以应对未来可能出现的分支模型多样化、协作流程复杂化的场景。
在说明问题前，先定义一些概念：

• feat：指代功能分支
• dev 与 test：指代两条不同的长驻分支，它们具有以下特点：
  • 受保护，不能直接推送
  • 不会被删除
  • 二者之间不直接合并，也即合并方式一般是 feat -> dev，feat -> test
• MR：merge request。代码合并请求

再论Git Flow

背景

团队目前使用的 Git 协作模式是：

1. 对每个功能建立相应的 feat 分支
2. 上研发、测试、UAT环境时，分别把相应的 feat 分支合并进入长驻 dev/test/uat
3. 如有冲突，则在本地更新长驻分支 dev/test/uat，merge feat into current branch，之后 checkout 一个新分支，作为 conflict resolved 分支，推送并合并至远程长驻分支

这个模式简单好懂，且业界流行，最直观的好处是，可以满足以下需求：

2020-09-21

Git最佳实践

精简提交

一次只提交一个“瘦”的功能，同时只包含相关改动文件。例如，对于两个错误的修复应该进行两次不同的提交。
如果发现写提交信息时，需要写两点以上;  则可以考虑拆分提交。

频繁提交

一次提交应只对应一个“瘦”的功能。从而达到频繁提交的目标。
经常性地提交改动可以确保不会出现特别庞大的提交，同时也可以比较精准地对应到所需要的改动上。

此外，通过频繁地提交也可以比较快速地和其他开发人员来共享你的改动。同样也会避免在整合代码时出现过多的合并冲突。相反的，非常庞大的提交会加大整合代码时出现冲突的风险，解决这些冲突也会非常复杂。

Git常用命令

前言

本文将列举Git常见场景，并给出相应解决方案。

约定： 下文代码块中${}里面表示的是变量，具体值视情况而定，其余的都是正确可执行的命令。

推荐： 图形化交互式Git教程

配置

Mac/Linux 用户 执行以下操作

vi ~/.gitconfig