【5分钟学一个新技能】Git：改变天下的协作革命

刚学编程那阵子，我最怕两件事：一是代码写不出来，二是代码写出来却弄丢了。
辛辛劳苦改了一晚上代码，原来能跑，更新后假如出了标题就难以回滚亦或是修复，只能盯着空缺发呆；
和别人一起开辟项目，QQ互传压缩包，偶然也不知道对方改了那里，碰到报错更是头晕，只能对七八个版本傻眼——到底哪个能用？
挖苦之余，有群友说：“你们该用版本管理。”
那是我第一次听说这个词。
什么是版本管理？

简单说，版本管理就是给你的代码“照相片”。
想象一下你写文档。写完一稿，存成“陈诉v1.docx”。改了点，存成“陈诉v2.docx”。又改了点，存成“陈诉终极版.docx”。再改，酿成“陈诉真的终极版.docx”。
这就是最原始的版本管理——手动定名，手动备份。标题很显着：版本多了就乱，想找回某个中心版本得一个个打开看。
专业的版本管理体系，就是帮你自动化这个过程的工具。它会：

• 记载每次改动的内容
  
• 记载谁在什么时间改的
  
• 记载为什么要改
  
• 让你随时回到恣意汗青版本
  

在Git出现前，已经有CVS、Subversion如许的版本控制工具。但它们都有个共同标题：必须毗连中心折务器。这就像在图书馆借书——书只有一本，你得登记谁借走了，别人得等着。
Linus的“十日革命”

2005年，Linux内核开辟团队就面临如许的逆境。他们用的BitKeeper突然要收费，而现有的开源工具又满足不了需求。
Linux之父Linus Torvalds厥后在采访中说：“其时的环境是，要么我们继续用不符合的工具，要么我本身造一个符合的。”他选择了后者。
4月3日，Linus开始写Git。他在计划文档里写了三个目的：

• 速率要比其他工具快十倍
  
• 完全分布式，不必要中心折务器
  
• 能处理处罚像Linux内核如许的大项目
  

十天后，Git第一个版本发布。4月16日，Linus用Git管理Linux内核源码。4月20日，他公布Git已经能自我托管——用Git来管理Git本身的代码。
早期的Git很难用。下令复杂，概念抽象。有开辟者抱怨：“这玩意儿比Linux内核还难懂。”Linus的复兴很直接：“不爽不要用。”
但Git有两个计划太超前了：
第一，分布式架构。每个人的电脑上都有完备的堆栈汗青，不必要联网也能提交代码。这就像每个人都有一本完备的图书馆目次，不必要去总馆查资料。
第二，分支管理。分支是同时控制差异版本代码的绝佳工具。比方，你渴望在稳固版代码的底子上加点新功能，就可以基于主分支创建新分支，在新分支上随意更改，这让“实行性开辟”成为大概——想到什么点子，开个分支试试，不可就删掉。
GitHub：让Git飞入寻常百姓家

Git很强，但直到2008年，它紧张还是极客在用。直到三个年轻人创建了GitHub。
GitHub做了件简单但革命性的事：给Git套了个网页界面。
突然之间，事故变得直观了。代码堆栈酿成网页，提交汗青酿成时间轴，分支归并酿成可视化操纵。更紧张的是，他们创造了Pull Request（PR，拉取哀求）。这是GitHub最巨大的创新。你不再必要邮件发送补丁，而是：

• Fork（复制）别人的堆栈
  
• 在本身的副本上修改
  
• 发起Pull Request，哀求原作者归并你的修改
  
• 在PR中举行代码检察、讨论
  

这种模式极大地低沉了开源贡献的门槛。2015年，微软将.NET框架开源并放到GitHub上时，社区震惊了。这个曾经视开源为敌的公司，现在自动拥抱开源。
我清晰地记得第一次在GitHub上提交PR的场景。那是个朋侪的开源小项目，我发现文档内容有误。点了“Fork”按钮，把项目复制到我的账户。修改，提交，然后发起PR。项目维护者看到了，点了个“Merge”。两分钟后，我的修改成了项目的一部门。
那种感觉很难形容——好像突然之间，我也能为那些遥不可及的大项目做贡献了。
GitHub火了。到2012年，它已经有高出200万个堆栈。Ruby on Rails、jQuery、Node.js这些着名项目都搬了上去。微软也把.NET框架开源放到了GitHub，这在从前是不可想象的。
GitHub的乐成引来了竞争者。2011年，GitLab诞生。它的卖点是“可以本身摆设”。企业可以把GitLab装在本身的服务器上，代码不出内网。除了代码托管，它还集成了：

• CI/CD流水线：自动测试、构建、摆设
  
• 标题追踪：bug陈诉、功能哀求
  
• Wiki：项目文档
  
• 代码质量分析：自动化代码查抄
  

中国这边，2013年出现了Gitee（码云）。早先许多人以为“是盗窟GitHub”，但厥后发现了它的代价：国内访问快，符合中国法规，另有中文界面。
不但是代码

Git的影响远远超出了编程天下。

• 学术研究：学者用Git管理论文草稿，每次修改都有记载
  
• 法律文件：状师事件所用雷同Git的体系管理条约版本
  
• 图书出书：出书社用Git调和作者、编辑、校对的工作
  
• 当局文档：有些当局部门用Git追踪政策文件的修订
  

现实怎么用？

第一步：初始化与设置

先安装Git，安装步调略。
开始前，先告诉Git你是谁：

1. git config --global user.name ”你的名字“
2. git config --global user.email ”你的邮箱“

复制代码

这很紧张，由于Git的全部提交都会记载作者信息。
创建一个新堆栈：

1. mkdir my-project # 新建一个名为“my-project”的文件夹
2. cd my-project # 进入该文件夹
3. git init # Git仓库初始化

复制代码

实行git init后，当前目次会出现一个潜伏的.git文件夹。这就是Git的“大脑”，内里存储着全部的版本信息、设置和索引。
大概，你也可以直接下载云端堆栈：

1. git clone https://github.com/username/repo.git # 此处链接为你仓库的实际在线链接，clone就是“克隆”的意思，会把仓库下载到当前目录下
2. cd repo # 进入仓库文件夹，文件夹名称为仓库名

复制代码

检察堆栈状态：

1. git status

复制代码

这是你最常用的下令之一。它会告诉你：

• 哪些文件被修改了但还没暂存（赤色）
  
• 哪些文件已经暂存等待提交（绿色）
  
• 是否有未跟踪的新文件
  

第二步：底子工作流

假设你写了一个简单的Python脚本：

1. # hello.py
2. print(”Hello, World!“)

复制代码

把文件添加到暂存区：

1. git add hello.py # add后为你的实际文件名

复制代码

大概添加全部修改：

1. git add . # .表示所有文件

复制代码

暂存区（Staging Area）是Git的精妙计划。它就像购物车——你可以把多个改动放进去，末了一次性结账。这让你可以经心构造每次提交的内容。
正式提交：

1. git commit -m ”添加hello.py脚本“

复制代码

每次提交都应该有一个清晰的形貌。好的提交信息应该像消息标题：简明扼要地阐明做了什么。好比：

• ❌ 错误：”修复bug“、”更新代码“
  
• ✅ 正确：”修复用户登录时的空指针非常“、”添加用户头像上传功能“
  

现在业界公认度最高的提交信息标准是 Conventional Commits（约定式提交）。它最初源于 Angular 团队的规范，现在已成为许多开源项目（如 Vue、React、Babel 等）和大型团队的通用标准。
1. 焦点格式

遵照(): 的结构，比方：

• feat(auth): add OAuth2 login flow
  
• fix(ui): correct button alignment on dashboard
  

2. 关键规则

• 范例 (Type)：必须使用特定关键词，如 feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建/工具）等。
  
• 时态：使用现在时（如 ”add“ 而非 ”added“），且首字母不大写。
  
• 长度：标题行发起不高出 50 字符，正文行发起不高出 72 字符。
  
• 空行：标题与正文之间必须有一个空行。
  

3. 为什么用这个标准？

• 自动化工具：能自动天生 CHANGELOG（更新日志）。
  
• 语义化版本：能根据 feat 和 fix 自动决定版本号升级（如 1.0.0 → 1.1.0）。
  
• 可读性：让代码汗青像一本清晰的阐明书，便于团队协作。
  

检察提交汗青：

1. git log

复制代码

默认表现完备的提交信息。假如想要轻便视图：

1. git log --oneline --graph --all

复制代码

这会表现一个可视化的分支图，特别得当检察复杂的分支结构。
第三步：取消与回滚

写代码难免犯错，Git提供了多种“悔恨药”。
场景1：还没暂存就发现写错了

1. # 放弃某个文件的修改
2. git checkout -- hello.py
4. # 放弃所有修改（危险！请确认你真的不需要这些修改）
5. git checkout -- .

复制代码

场景2：已经暂存但想取消

1. # 把文件从暂存区移出，但保留修改
2. git reset HEAD hello.py
4. # 然后可以用checkout放弃修改
5. git checkout -- hello.py

复制代码

场景3：已经提交但想取消

1. # 查看提交历史，找到要回退的版本
2. git log --oneline
4. # 假设我们看到：
5. # a1b2c3d 添加新功能
6. # e4f5g6h 修复bug
7. # i7j8k9l 初始提交
9. # 回到修复bug的那个版本
10. git reset --hard e4f5g6h

复制代码

--hard参数会彻底抛弃之后的提交，慎用！假如你只是想取消某个提交但保存更改：

1. git revert e4f5g6h

复制代码

这会创建一个新的提交来取消指定提交的修改，更安全。
第四步：分支管理

分支是Git最强盛的功能之一。它让你可以：

• 同时开辟多个功能
  
• 安全地实行新想法
  
• 隔离bug修复和功能开辟
  

创建并切换到新分支：

1. git checkout -b new-feature

复制代码

这等价于：

1. git branch new-feature    # 创建分支
2. git checkout new-feature  # 切换分支

复制代码

在新分支上开辟完成后，切换回主分支并归并：

1. git checkout main
2. git merge new-feature

复制代码

假如归并顺遂，Git会实行“快进归并”（Fast-forward）。假如有辩说，Git会提示你办理。
删除已归并的分支：

1. git branch -d new-feature

复制代码

欺压删除未归并的分支：

1. git branch -D experimental

复制代码

检察全部门支：

1. git branch     # 本地分支
2. git branch -r  # 远程分支
3. git branch -a  # 所有分支

复制代码

第五步：长途协作

当地Git再强盛，也必要与团队协作。这就是长途堆栈的用武之地。
添加长途堆栈：

1. git remote add origin https://github.com/username/repo.git

复制代码

origin是长途堆栈的默认别名，你可以用其他名字。
检察长途堆栈：

1. git remote -v

复制代码

推送当地提交到长途：

1. git push origin main

复制代码

第一次推送时大概必要指定上游分支：

1. git push -u origin main

复制代码

-u参数设置上游关联，之后可以直接用git push
拉取长途更新：

1. git pull origin main

复制代码

这等价于：

1. git fetch origin   # 下载远程更新
2. git merge origin/main  # 合并到当前分支

复制代码

偶然间你只想检察长途有什么更新，而不想立即归并：

1. git fetch origin
2. git log origin/main --oneline  # 查看远程分支的提交

复制代码

第六步：处理处罚辩说

辩说是团队协作的必经之路。当两个人修改了同一文件的同一地区时，Git无法自动归并，必要人工办理。
发生辩说时，Git会在文件中标志辩说：

1. <<<<<<< HEAD
2. print(”Hello from Alice!“)
3. =======
4. print(”Hello from Bob!“)
5. >>>>>>> feature-branch

复制代码

你必要：

• 编辑文件，选择保存哪部门（或都保存）
  
• 删除辩说标志（）
  
• 添加办理后的文件：git add filename
  
• 完成归并：git commit
  

检察归并状态：

1. git merge --abort  # 取消合并，回到合并前状态
2. git status         # 查看当前冲突文件

复制代码

第七步：高级本领

蕴藏更改（Stashing）：

当你必要切换分支但当前工作还没完成时：

1. git stash          # 储藏当前修改
2. git stash list     # 查看储藏列表
3. git stash pop      # 应用最新的储藏并删除
4. git stash apply    # 应用储藏但不删除

复制代码

检察差异：

1. git diff                    # 工作区与暂存区的差异
2. git diff --staged          # 暂存区与最新提交的差异
3. git diff commit1 commit2   # 两个提交之间的差异

复制代码

重写汗青（审慎使用！）：

修改末了一次提交：

1. git commit --amend

复制代码

交互式变基（修改多个提交）：

1. git rebase -i HEAD~3  # 修改最近3个提交

复制代码

子模块（Submodules）：

用于在项目中包罗其他Git堆栈：

1. git submodule add https://github.com/other/repo.git
2. git submodule update --init --recursive

复制代码

现实工作流示例

让我分享一个真实的工作流。假设我们要开辟一个新功能：

• 从最新代码开始
  

1. git checkout main
2. git pull origin main

复制代码

• 创立功能分支
  

1. git checkout -b feature/user-profile   

复制代码

• 开辟、测试、提交
  

1. # 多次小提交，而不是一次大提交
2. git add user/profile.py
3. git commit -m ”添加用户基本信息模型“
4.    
5. git add user/views.py
6. git commit -m ”实现个人资料页面“
7.    
8. git add tests/test_profile.py
9. git commit -m ”添加个人资料功能测试“   

复制代码

• 推送到长途
  

1. git push -u origin feature/user-profile   

复制代码

• 创建Pull Request
  
  
  
  • 在GitHub/GitLab上发起PR
    
  • 同事检察代码，提出发起
    
  • 根据反馈修改，再次推送
    
  • 通过CI/CD流水线的自动化测试
    
  • 归并到主分支
    
  
  
• 清算分支
  

1. git checkout main
2. git pull origin maingit branch -d feature/user-profile

复制代码

改变了什么？

Git和它的衍平生台改变了三件事：
第一，低沉了协作门槛。从前贡献开源项目要发邮件、下源码包、打补丁。现在点个Fork，改完提交PR就行。这让开源从“精英游戏”酿成了“全民运动”。
第二，让工作流标准化。无论你在哪个公司，用的都是相似的Git工作流。新人入职，半天就能上手代码管理流程。
第三，创造了新的职业。DevOps工程师、平台开辟，这些岗位很大程度上是由于Git生态出现的。
但最深层的改变，是头脑方式的变化。
我现在写代码时的心态完全差异了。知道有Git托底，就敢实行激进的重构。知道分支是安全的，就敢同时开展多个实行性功能。知道每次提交都有记载，写commit message时会更认真。
尾声

偶然间我会想，假如2005年Linus没被逼到必须本身写工具，本日的天下会怎样？
大概我们还在用QQ传代码压缩包。大概开源不会这么繁荣。大概长途协作还是噩梦。
但汗青没有假如。一个性情急躁的步伐员，花了十天时间办理本身的标题，趁便办理了全天下步伐员的标题。
这就是技能的魅力——最好的工具通常诞生于详细的逆境，却办理了广泛的需求。
现在每次我开始新项目，都会风俗性地git init。这个简单的动作，毗连着从个人备份到环球协作的整个汗青。
而每次git commit时，我知道本身不但是在生存代码。我是在加入一场连续了快要二十年的革命——一场让创造变得更有序、更协作、更恒久的革命。