tag: Git

前言 笔者最近在主导一个项目的架构迁移工作，由于迁移项目的历史包袱较重，人员合作较多，在迁移过程中免不了进行多分支、多次 commit 的情况，时间一长，git 的提交记录便混乱不堪，随便截一个图形化的 git 提交历史给大家感受一下。 各种分支疯狂打架宛如后宫争宠的妃子们，之所以会出现这种情况，主要还是因为滥用 git merge 命令并且不考虑后续的理解成本导致的。如今在大厂工作的程序员们，频繁接受变更的需求，一旦一开始考虑不周到，就一定会出现了大量无意义的 commit log，加上“敏捷”理念的推广，产品的快速迭代上线变成了核心指标，这些无意义的 commit log 便被“下次再处理”，久而久之就混乱不堪了。 而我们在看一些开源仓库时，会发现他们的 commit 记录十分整洁，其实这并不是社区的程序员能力更强，而是因为他们没有 KPI 大棒的鞭笞，在提交代码前会花时间整理自己的 commit log。而这就是本文的主角了——“Git Rebase”。 git rebase 和 git merge git rebase，中文翻译为“变基”，通常用于分支合并。既然提到了分支合并，那就一定离不开git merge这个命令。 相信每个新手程序员刚进入职场的时候，都会听到“xxx 你把这个分支 merge 一下”这样的话。那么问题来了，假如你有 6 个程序员一起工作， 你就会有 6 个程序员的分支， 如果你使用 merge, 你的代码历史树就会有六个 branch 跟这个主的 branch 交织在一起。 上图是 git merge 操作的流程示意图，Merge 命令会保留所有 commit 的历史时间。每个人对代码的提交是各式各样的。尽管这些时间对于程序本身并没有任何意义。但是 merge 的命令初衷就是为了保留这些时间不被修改。于是也就形成了以 merge 时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录，主分支上只保留 merge 的历史记录。子分支随时都有可能被删除。子分子删除以后，你能够看到的记录也就是，merge 某 branch 到某 branch 上了。这个历史记录描述基本上是没有意义的。 而 git rebase 中文翻译为“变基”，变得这个基指的是基准。如何理解这个基准呢？我们看一下下图。...

之前看过几个新闻，说是因为程序员的疏忽，将公司服务器的密钥上传到 GitHub 上，导致公司数据丢失，造成了很严重的影响，恰巧最近看到一篇英文博客有介绍如何防止 Git 泄露，下面是我的翻译内容，原文来自于 5 Best Practices To Prevent Git Leaks，如果有翻译不当的地方欢迎指正，希望能对你有所帮助。 无数的开发人员正在使用 Git 进行版本控制，但是许多开发人员对 Git 的工作方式并没有足够的了解。有些人甚至将 Git 和 Github 用作备份文件的工具。这些做法导致 Git 仓库中的信息遭到泄露。每天都有数千个新的 API 或加密密钥从 GitHub 泄漏出去。 我在信息安全领域工作了三年。 大约在两年前，我们公司发生了一起非常严重的安全问题，是由于 Git 仓库发生了信息泄露导致的。 一名员工意外地在 Github 上泄露了 AWS 的密钥。攻击者使用此密钥从我们的服务器下载很多敏感的数据。我们花了很多时间来解决这个问题，我们试图统计出泄漏了多少数据，并分析了受影响的系统和相关用户，最后替换了系统中所有泄漏的密钥。 这是一个任何公司和开发人员都不愿经历的悲惨故事。 关于整件事情的细节我就不多写了。事实上，我希望更多的人知道如何去避免 Git 的信息泄露。以下是我提出的一些建议。 建立安全意识 大多数新人开发者没有足够的安全意识。有些公司会培训新员工，但有些公司没有系统的培训。 作为开发人员，我们需要知道哪些数据可能会带来安全问题。千万记住，下面这些数据不要上传到 Git 仓库中： 任何配置数据，包括密码，API 密钥，AWS 密钥和私钥等。 个人身份信息（PII）。根据 GDPR 的说法，如果公司泄露了用户的 PII，则该公司需要通知用户和有关部门，否则会带来更多的法律麻烦。 如果你在公司工作，未经允许，请勿共享任何与公司相关的源代码或数据。 攻击者可以在 GitHub 上轻松地找到某些具有公司版权的代码，而这些代码都是被员工无意中泄露到 Github 上的。 我的建议是，应该将公司项目和个人项目严格区分。 使用 Git 忽略（Git ignore） 当我们使用 Git 创建一个新项目时，我们必须正确地设置一个 .gitignore 文件。....