不知道大家有没有听过"Git三剑客"，先说说为什么叫"三剑客"这个名字，我想大概是因为作为程序员我们的编程能力好比内功，而Git在我们手中就好比手中的剑，无论是在公司参与团队协作开发，还是在社区参与开源，Git都是必备技能，因为只有能熟练的使用Git进行团队协作与项目开发才能更好的彰显自己的内功，也就是编程能力，今天就可以一起来讨论一下"Git三剑客"。
Git三剑客
“Git三剑客”通常指的是在软件开发和版本控制领域中紧密相关且广泛使用的三个工具或平台：Git、GitHub 和 GitLab。这三个工具各自具有独特的功能和用途，但共同为开发者提供了强大的版本控制和代码管理支持。
Git三剑客Git
开源的分布式版本控制系统，由林纳斯·托瓦兹（Linus Torvalds）为辅助 Linux 内核的开发而设计。它允许开发者跟踪文件的更改历史，记录谁何时进行了哪些更改，并比较和合并不同的项目版本。
功能：Git 强调速度、数据完整性和分布式工作流。它允许开发者在本地计算机上独立运行，并通过网络与其他 Git 仓库同步。
GitHub
基于 Git 的远程代码仓库托管平台，提供了代码托管、代码审查、问题跟踪、持续集成/持续部署（CI/CD）支持、社区互动等多种功能和服务。GitHub 是开源项目和私有项目最受欢迎的托管平台之一，特别是在需要社区参与和贡献的项目中。
功能：GitHub 不仅允许开发者存储和管理代码，还鼓励开发者之间的协作。通过拉取请求（Pull Requests）、问题跟踪（Issues）和 Wiki 页面等功能，GitHub 促进了开源项目的社区参与和贡献。
GitLab
开源的 Git 仓库管理工具，提供了与 GitHub 类似的功能，但允许开发者在自己的服务器上安装和运行它。GitLab 特别适合那些需要内部部署、担心数据隐私或想要完全控制自己代码仓库的企业和组织。它提供了高度可定制性和可扩展性。
功能：GitLab 包括代码托管、版本控制、问题跟踪、CI/CD 管道、Wiki、代码审查等多种功能，旨在成为一个完整的 DevOps 生命周期工具。
它们之间的相互关系
Git是版本控制系统的核心，提供基本的版本控制功能。
GitHub和GitLab都是基于Git的远程代码仓库托管平台，但GitHub专注于提供广泛的服务和社区支持，而GitLab则更注重可定制性和内部部署选项。
简而言之，Git是工具，GitHub是全球唯一的开源社区，GitLab支持私有部署。
Git的历史发展
Git由Linux创始人Linus Torvalds在2005年开发。当时，他因为BitKeeper公司收回了Linux内核的免费版本控制系统使用权，决定自己开发一个新的系统。Git的开发初衷是为了管理Linux内核的源代码，旨在提供一个快速、高效且能够处理大规模分布式项目的版本控制系统。虽然最初仅用于Linux内核的开发，但Git项目很快传播开来，并被用于管理许多其他Linux项目。
2006年，Git成为开源项目，并迅速获得广泛关注和支持。
2010年，Git成为Linux内核的主要版本控制系统，这标志着Git已经成为了一个可靠且广泛使用的工具。
Git三剑客实践
下面我们就来分享一下Git、GitHub、GitLab的常用命令与实践，由于篇幅关系不会列举的十分完全，但都是最常用的、最优雅的精髓，如果能全部掌握也很厉害了。
Git常用命令
Git的常用命令非常丰富，涵盖了初始化仓库、文件操作、提交、分支管理、远程仓库操作等多个方面。以下是一些常用的Git命令及其简要说明：
1）仓库初始化与克隆
git init：在当前目录下创建一个新的Git仓库。
git clone [url]：克隆远程仓库到本地。
2）文件操作
git add [file]：将指定的文件添加到暂存区，准备提交。如果想提交当前目录下文件可以使用命令git add .，全部文件使用git add *
git rm [file]：从工作区和暂存区删除文件，并提交删除操作。
git mv [file-original] [file-renamed]：重命名文件，并将这个改名放入暂存区。
3）提交
git commit -m "message"：提交暂存区的文件到本地仓库，并附上一条描述本次提交的备注信息。
git commit --amend：修改最后一次提交的备注信息或内容。
4）查看状态与差异
git status：显示工作区和暂存区的状态。
git diff：显示工作区与暂存区之间的差异，或者暂存区与上一个commit之间的差异。
5）分支管理
git branch：列出本地分支，创建或删除分支。
git branch [branch-name]：创建新分支但不切换。
git checkout [branch-name]：切换到指定分支。
git checkout -b [branch-name]：创建并切换到新分支。
git merge [branch-name]：合并指定分支到当前分支。
git rebase [branch-name]：将当前分支的提交重新应用到指定分支上。
6）远程仓库操作
git remote -v：显示远程仓库的详细信息。
git fetch [remote-name]：从远程仓库拉取最新变更，但不合并到本地分支。
git pull [remote-name] [branch-name]：拉取远程分支并合并到本地分支。
git push [remote-name] [branch-name]：将本地分支推送到远程仓库。
git push --force：强制推送更改到远程仓库，即使有冲突。
7）标签管理
git tag：列出所有标签。
git tag [tag-name]：创建一个新的标签。
git show [tag-name]：查看标签的详细信息。
git push origin --tags：遍历你所有的本地标签，并将它们推送到指定的远程仓库。
8）其他常用命令
git log：显示提交日志。
git show [commit-id]：显示某次提交的详细内容。
git stash：暂存当前工作区的修改，以便于切换到其他分支或进行其他操作。
git cherry-pick [commit-id]：选择并应用某个提交的更改到当前分支。
git reflog：查看所有的引用日志，包括已经被删除的提交和分支。
这些命令是Git日常操作中最为基础和常用的部分，掌握它们可以大大提高版本控制的效率和准确性。当然，Git的功能远不止于此，还有更多高级特性和命令等待开发者去探索和学习。
GitHub常用实践方式
GitHub作为广泛使用的代码托管和协作平台，通常使用独立仓库进行开发，涉及到仓库的fork、clone以及分支的维护，其中pull request是关键的一步。
GitHub仓库维护在GitHub上使用Pull Request的一般流程如下：
1）克隆项目：首先，你需要将GitHub上的项目仓库克隆到本地。
2）创建分支：在本地仓库中，创建一个新的分支来包含你的更改。
3）进行更改：在新分支上进行代码更改，并进行必要的测试。
4）提交更改：将更改提交到本地仓库。
5）推送分支：将你的更改推送到GitHub上的远程仓库的新分支。
6）创建Pull Request：在GitHub上，找到你的新分支，并点击“New pull request”按钮来创建一个新的Pull Request。
7）填写信息：在Pull Request页面上，填写标题、描述和其他相关信息，以便其他合作者了解你的更改。
8）等待审查：提交Pull Request后，等待项目维护者或其他合作者进行代码审查和讨论。
9）合并更改：如果Pull Request被接受，项目维护者将合并你的更改到目标分支。
其中，对于仓库中分支的的开发和维护，可以参考Git Flow。
Git Flow
Git Flow是一种基于分支模型的工作流程规范，它强化了分支模型的使用，使得软件开发过程更加清晰和有序。Git Flow的主要流程可以归纳如下：
核心分支
Git Flow依赖于两个核心分支来管理项目的开发和发布：
- master分支：这是主分支，用于稳定的生产环境代码的存放。master分支上的代码都是经过充分测试，并可以立即在生产环境中部署的代码。
- develop分支：这个分支用于存放开发中的代码。所有新功能的开发和bug修复工作都应该基于develop分支进行。当新功能或修复完成并经过测试后，它们会被合并回develop分支。
辅助分支
除了核心分支外，Git Flow还使用一系列辅助分支来支持具体的开发活动：
- feature分支：每个新功能都应该在一个独立的feature分支上开发。这样做的好处是可以并行开发多个功能，而不会相互干扰。当功能开发完成后，feature分支会被合并回develop分支，并可能被删除。
- release分支：当develop分支上的代码达到一定的稳定性和成熟度，需要准备发布时，会从develop分支上拉出一个release分支。在release分支上，主要进行的是修复bug、更新文档等面向发布的活动。当发布准备工作完成后，release分支会被合并回master分支和develop分支，并可能被删除。
- hotfix分支：如果生产环境中出现了需要紧急修复的问题，可以直接从master分支上拉出一个hotfix分支进行修复。修复完成后，hotfix分支会被合并回master分支和develop分支，以确保生产环境和开发环境都能得到修复。
流程概述
- 初始化：创建master和develop分支。
- 新功能开发：基于develop分支创建feature分支，进行新功能的开发。开发完成后，将feature分支合并回develop分支。
- 准备发布：从develop分支拉出release分支，进行发布前的准备工作，如修复bug、更新文档等。准备完成后，将release分支合并回master分支和develop分支。
- 紧急修复：如果生产环境中出现问题，从master分支拉出hotfix分支进行紧急修复。修复完成后，将hotfix分支合并回master分支和develop分支。
Git Flow的优点
- 清晰的分支结构：通过明确的分支命名和用途，使得项目的开发过程更加清晰和有序。
- 并行开发：允许团队成员并行开发多个功能，提高开发效率。
- 灵活的发布策略：通过release分支和hotfix分支的支持，使得项目的发布和紧急修复工作更加灵活和高效。
综上所述，Git Flow通过其核心分支和辅助分支的配合使用，为软件开发团队提供了一个清晰、有序且高效的工作流程规范。
GitLab常用实践方式
GitLab的实践方式可以完全参考Git Flow，所以在此就不做额外讲解啦。
但是GitLab和GitHub在使用实践上除了大部分相同的操作之外也有一些不同之处：
操作方面 | GitLab | GitHub |
|---|---|---|
分支操作 | 支持快速创建、切换和合并分支 可以通过GitLab CI/CD进行自动化测试和部署 | 同样支持分支的创建、切换和合并 可通过GitHub Actions实现类似功能 |
代码审查 | 使用Merge Request（合并请求）进行代码审查 允许在Merge Request中进行评论、讨论和修改 | 使用Pull Request（拉取请求）进行代码审查 Pull Request同样支持评论、讨论和代码修改 |
持续集成/持续部署（CI/CD） | GitLab CI/CD原生集成，无需额外配置 提供丰富的CI/CD模板和文档 | 通过GitHub Actions或第三方服务实现CI/CD GitHub Actions社区提供大量模板，但可能需要额外学习 |
部署方式 | 可自部署在私有服务器上，也可使用GitLab SaaS服务 | 主要提供云端托管服务，但支持通过GitHub Enterprise进行私有部署 |
小总结
Git叫分布式版本控制系统，它的分布式是如何体现的？
Git作为一种分布式版本控制系统，其分布式特性主要体现在以下几个方面：
1）代码仓库分布
：在Git中，每个开发者都可以克隆（clone）整个项目的副本到自己的本地环境中。这意味着每个开发者都拥有项目的完整历史记录和所有分支的副本，而不仅仅是部分代码或历史记录。
2）分布式协作和同步：开发者可以通过网络将自己的更改推送到其他开发者的存储库中共享，并接收其他开发者的更改推送到自己的存储库中。这种分布式的协作方式使得多个开发者可以同时进行工作，更好地协同开发和共享代码。
3）数据一致性和可靠性：Git使用SHA-1哈希算法来标识不同的提交，确保每个版本的唯一性和完整性。这种分布式的数据结构和算法使得Git在数据传输和存储过程中能够保持数据的一致性和可靠性。
参考：
https://blog.csdn.net/sunyctf/article/details/130587970
https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
https://www.cnblogs.com/yangblood/p/14442119.html
