【Linux】聊聊程序员必备的两个工具：Git版本控制和GDB调试

欢迎各位佬进行交流，我们一起无限进步！！！！！！！！！！

文章目录

• • 一、先搞懂版本控制：你就是自己代码的“时光机”
  • 二、Git、Gitee、GitHub：别搞混了！
  • 三、Git的小历史：为啥会有Git？
  • 四、Git入门：学会“三板斧”，基本够用了
  • • 1. 第一步：安装Git，配置身份
    • 2. 核心概念：本地仓库和暂存区
    • 3. Git“三板斧”操作流程
    • • （1）初始化本地仓库
      • （2）第一斧：git add —— 把文件放到暂存区
      • （3）第二斧：git commit —— 把暂存区的文件提交到本地仓库
      • （4）第三斧：git push —— 把本地仓库的代码推到远端（Gitee/GitHub）
    • 4. 其他常用命令：解决“突发情况”
  • 五、遇到代码冲突？别慌，这样解决
  • 六、聊完版本控制，再说说调试：GDB调试器
  • • 1. 先搞懂：程序的两个版本——release和debug
    • 2. GDB基础命令：入门够用了
    • 3. GDB命令记不住？试试cgdb，界面更友好
    • • （1）安装cgdb
      • （2）用cgdb调试
  • 七、最后总结

平时写代码的时候，你有没有过这种困扰？改了好几版代码，最后发现还是第一版好用，结果旧版本早就被覆盖没了；或者跟同事一起写项目，两个人改了同一个文件，合并的时候一团乱麻；再或者代码跑不起来，不知道哪里错了，只能一遍遍加printf打印？

其实解决这些问题，就靠两个常用工具：Git（版本控制） 和 GDB（调试器）。今天就用大白话跟大家聊聊这俩工具，从基础概念到实际操作，新手也能看明白。

一、先搞懂版本控制：你就是自己代码的“时光机”

先从一个大家都经历过的场景说起——交作业。

比如老师让交论文，你改了4版：第一版写得中规中矩，第二版加了点内容，第三版删了些段落，第四版改到自己都看不下去。结果老师说“还是第一版好，用第一版吧”。这时候就分两种情况：

• 同学A：每次改都直接在原文件上改，改完就保存，现在想找第一版？早没了，只能哭着重写；
• 同学B：每次改完都新建一个文件夹，比如“论文V1”“论文V2”，清清楚楚，打开“论文V1”直接交就行。

同学B的做法，其实就是版本控制——把文件的每一次修改都记录下来，需要的时候能随时找回旧版本。

而Git，就是用来做这件事的专业工具，而且比“建文件夹”强太多了：它能记录每一次修改的内容、修改人、修改时间，还能多人协作不冲突。

二、Git、Gitee、GitHub：别搞混了！

很多新手刚接触会懵：Git、Gitee、GitHub到底啥关系？其实很简单，用一句话总结：
Git是“工具”，Gitee/GitHub是“存放代码的平台”。

就像你用Word（工具）写文档，写完可以存在百度云（平台）或者本地硬盘（本地仓库）里。Git就是那个“Word”，负责管理版本；Gitee（国内平台，访问快）和GitHub（国际平台，资源多）就是“百度云”，负责把你本地的代码存到网上，方便自己备份、或者跟别人共享协作。

放张关系图理解更清楚（对应你原文里的图）：
Git（本地版本控制工具）可以连接Gitee/GitHub（远端仓库），你本地改完代码，能传到远端；别人改了，你也能从远端拉取到自己电脑上，实现协作。

另外Git还有个特点：去中心化的分布式控制。不是说所有代码都存在一个中央服务器（比如只有Gitee上有），而是每个用Git的人，电脑上都有完整的代码仓库。比如你和同事协作，不用必须通过远端，直接从对方电脑拉取代码也能同步，灵活很多。

三、Git的小历史：为啥会有Git？

早年间，程序员用的版本控制工具（比如BitKeeper）很多是收费的，而且用着不自由。2005年的时候，Linux内核的开发者（比如Linus Torvalds，Linux的创始人）觉得 existing 工具不好用，干脆自己动手，花了一两周时间写了Git的雏形。

后来Git开源了，大家越用越觉得方便，慢慢就成了程序员圈子里的“标配”——现在不管是个人项目还是公司开发，基本都用Git做版本控制。

四、Git入门：学会“三板斧”，基本够用了

Git的命令不少，但新手先掌握“三板斧”（add、commit、push），再加上几个常用命令，日常管理代码就没问题了。先从最基础的操作说起：

1. 第一步：安装Git，配置身份

首先得在电脑上装Git：

• 如果你用的是CentOS/RHEL系统，打开终端输：yum install git
• 如果你用的是Ubuntu/Debian系统，输：apt install -y git
• 装完后验证一下：输git --version，能显示版本号就说明装好了。

第一次用Git，必须配置用户名和邮箱——因为Git要知道“谁改了代码”，不然提交的时候会报错。配置命令如下（把括号里的换成你自己的信息）：

git config --global user.name \"你的用户名\" # 比如 \"ZhangSan\"git config --global user.email \"你的邮箱\" # 比如 \"zhangsan@xxx.com\"

2. 核心概念：本地仓库和暂存区

用Git管理代码，会涉及两个关键地方：

• 本地仓库：就是你电脑上的.git文件夹（隐藏的，用tree .git能看到里面的结构），所有版本记录都存在这里；
• 暂存区：可以理解成“临时中转站”，你改了文件，不是直接进仓库，而是先放到暂存区，确认没问题了再提交到仓库。

为什么要暂存区？比如你改了3个文件，其中2个改完了，1个还没改好。这时候可以先把改好的2个放到暂存区，提交到仓库；没改好的那个先不放，等改完再单独提交，灵活很多。

3. Git“三板斧”操作流程

假设你新建了一个项目文件夹，想用法Git管理，步骤是这样的：

（1）初始化本地仓库

进入项目文件夹，输命令：git init
执行完会生成一个.git隐藏文件夹，说明这个文件夹已经被Git管理了。

（2）第一斧：git add —— 把文件放到暂存区

比如你新建了一个test.c文件，想把它加入版本控制，输：
git add test.c
如果想把当前文件夹里所有改了的文件都加入暂存区，输：git add .（注意后面有个点）。

想看看哪些文件在暂存区、哪些没在？输git status就行，终端会显示得明明白白（对应你原文里的status截图）：比如“已暂存的文件”会标绿色，“未暂存的文件”标红色。

如果不小心加错了文件到暂存区，想删掉？输git reset 文件名就能把这个文件从暂存区撤出来。

（3）第二斧：git commit —— 把暂存区的文件提交到本地仓库

暂存区确认没问题了，就可以提交到本地仓库，相当于“保存一个版本”。命令是：
git commit -m \"这里写版本说明\"
重点：-m后面的“版本说明”千万别瞎写！比如你改了什么，就写“新增test.c文件”“修复登录bug”“优化首页加载速度”，这样以后看日志的时候，能一眼知道这个版本改了啥。

提交完想看看历史版本？输git log，就能看到所有commit记录：每个版本的ID、提交人、时间、说明都有。

（4）第三斧：git push —— 把本地仓库的代码推到远端（Gitee/GitHub）

本地保存了版本，想传到Gitee/GitHub备份或协作，就用git push。不过第一次推之前，要先把本地仓库和远端仓库关联（比如在Gitee新建一个仓库，然后按Gitee的提示，用git remote add origin 仓库链接关联），关联好后再推，代码就到远端了。

4. 其他常用命令：解决“突发情况”

• 不小心删了本地仓库？ 别慌！如果之前推过远端，直接用git clone 远端仓库链接，就能把远端的代码完整拉取到本地，相当于重新恢复了仓库。
• Git只管理“源文件”：比如你用C语言编译生成的.obj文件、.exe文件，或者日志文件、缓存文件，这些不是代码本身，没必要加入版本控制。这时候就需要一个.gitignore文件——在项目根目录新建这个文件，里面写你想忽略的文件后缀（比如*.obj、*.exe、log/），Git就会自动过滤这些文件，不会让你提交它们（对应你原文里的.gitignore截图）。

五、遇到代码冲突？别慌，这样解决

多人协作的时候，最容易遇到的问题就是“冲突”：比如你和同事都改了同一个文件的同一行代码，你先把代码推到远端，同事再推的时候，Git就会提示“冲突”，推不上去。

这时候别慌，解决步骤很简单：

1. 先输git pull，把远端最新的代码（包括你刚推的）拉取到自己本地；
2. 拉取后，Git会在冲突的文件里标注出冲突的地方（比如用<<<<<<<、=======、>>>>>>> 分隔你的代码和远端的代码）；
3. 打开这个文件，手动修改冲突部分（比如保留正确的代码，删掉冲突标记）；
4. 修改完后，再用git add 冲突文件 → git commit -m \"解决xxx文件冲突\" → git push，就能推上去了。

核心原则：先拉取，再解决冲突，最后提交推送。

六、聊完版本控制，再说说调试：GDB调试器

写代码难免会遇到bug：比如程序崩溃、结果不对，但不知道问题出在哪。这时候总不能靠printf一遍遍试吧？效率太低了。GDB就是用来解决这个问题的——它是一个命令行调试器，能让程序“一步步跑”，还能看变量的值、设断点，帮你快速定位bug。

1. 先搞懂：程序的两个版本——release和debug

用GDB调试有个前提：你的程序必须是“debug版本”，不能是“release版本”。这俩有啥区别？

• release版本：是最终发布给用户用的版本，编译器（比如gcc/g++）会自动优化代码（比如删去无用的代码、压缩体积），而且不会保留调试信息。所以你用gcc默认编译的程序，就是release版本，比如gcc test.c -o test，这种程序没法用GDB调试（对应你原文里的release截图）。

• debug版本：是给开发者调试用的版本，编译的时候要加-g参数，编译器会保留调试信息（比如代码行号、变量信息），所以文件体积会比release大一点，但能被GDB识别。比如编译命令要写成：gcc test.c -o test -g（对应你原文里的debug截图）。

记住：想调试，编译时一定要加-g！

2. GDB基础命令：入门够用了

GDB是命令行工具，打开方式很简单：终端输gdb 你的程序名，比如gdb test，就能进入GDB调试环境。下面是几个最常用的命令（记不住可以先存着，用的时候查）：

命令 作用 例子 l（list） 查看代码（默认显示10行，再输l会继续往下显示） l 或 l 10（查看第10行附近的代码） r（run） 运行程序（如果没设断点，会直接跑完） r b（break） 设置断点（让程序在指定位置停下来） b 15（在第15行设断点）、b main（在main函数开头设断点） info b 查看所有断点（会显示断点编号、位置） info b d（delete） 删除断点 d 1（删除编号为1的断点） n（next） 单步执行（不进入函数内部，像“下一步”） n s（step） 单步执行（会进入函数内部，像“步入”） s p（print） 查看变量的值 p a（查看变量a的值） quit 退出GDB调试环境 quit

举个简单的调试例子：
你编译了debug版本的test程序，想在第20行设断点，查看变量sum的值：

1. 终端输gdb test → 进入GDB；
2. 输b 20 → 在第20行设断点；
3. 输r → 运行程序，程序会在第20行停下来；
4. 输p sum → 查看当前sum的值；
5. 输n → 执行下一行代码，再输p sum，看sum有没有变化；
6. 调试完输quit退出。

3. GDB命令记不住？试试cgdb，界面更友好

纯命令行的GDB，看代码的时候可能有点费劲——比如想一边看代码一边调试，得来回输l命令。这时候可以用cgdb，它是GDB的“增强版”，界面会分成两部分：上面显示代码，下面是GDB命令行，用起来更直观。

（1）安装cgdb

• Ubuntu/Debian：apt install cgdb
• CentOS/RHEL：可能需要先装epel源，再输yum install cgdb（对应你原文里的cgdb安装图）。

（2）用cgdb调试

打开方式：终端输cgdb 你的程序名，比如cgdb test。界面如下（对应你原文里的cgdb界面图）：
上半部分是代码，能直接看到行号；下半部分是命令行，输入的GDB命令（比如b 15、r、p sum）和GDB是完全兼容的，不用重新学新命令。

比如你在cgdb里输b 15设断点，上半部分的代码第15行会标红，提示“这里有个断点”；输r运行，程序停在断点处，光标会定位到对应的代码行，看变量、单步执行都很清楚。

七、最后总结

Git和GDB这两个工具，刚开始用可能觉得“命令多、记不住”，但其实不用追求一次性学会所有功能——新手先掌握“常用命令”，比如Git的add/commit/push，GDB的b/r/p/n，遇到问题再查资料，用多了自然就熟了。

毕竟工具是为了解决问题的：Git帮你管好代码版本，不用再担心“改崩了回不去”；GDB帮你快速找bug，不用再靠printf“盲试”。学会这俩，写代码能省不少事～

如果觉得这篇内容有用，可以收藏起来，以后遇到问题再翻一翻。有疑问的话也可以在评论区交流，一起进步～