【深入解析git和gdb：版本控制与调试利器的终极指南】_github debug版本

【本节目标】

• 1. 掌握简单gdb使用于调试

• 2. 学习 git 命令行的简单操作, 能够将代码上传到 Github 上

1.Linux调试器-gdb使用

1.1.背景

• 程序的发布方式有两种，debug模式和release模式
• release模式不可被调试，debug模式可被调试
• Linux gcc/g++出来的二进制程序，默认是release模式
• 要使用gdb调试，必须在源代码生成二进制程序的时候, 加上 -g 选项

为什么要有debug模式和release模式两种模式呢？这两种模式的存在是为了在不同阶段和用途下提供不同的编译和运行配置。

Debug 模式主要用于开发和调试阶段，以提供更好的可读性和调试能力，而 Release 模式则用于最终部署，面向用户的就是该版本，且该版本能提供更好的性能和减小可执行文件的体积。Debug 模式形成的可执行程序会添加调式信息，Release 模式形成的可执行程序会去掉调式信息。对于用户来说，用户不需要调式信息，用户只在乎下载速度和安装文件大小。对于程序员来说，程序员需要改bug，因此需要调式信息才能修正bug，于是就出现了两种模式。

1.2. 开始使用

我们首先写个程序，方便后面调试样例

#include<stdio.h>
int Sum(int n)
{
	int i = 1;
	int sum = 0;
	for (; i <= n; i++)
	{
		sum += i;
	}
	return sum;
}
int main()
{
	int result = Sum(100);
	printf("%d\n", result);
	return 0;
}

然后再将我们的makefile文件写好。

然后我们来编译一下我们上面的代码，上面的代码是求从1加到100的和，可以看到我们的程序是正确的。

接下来就开始我们的调试程序

但是我们发现此时我们不能进行调试，因为此时是release版本，是不可被调试滴。

为了区分两种模式下的可执行程序，将Debug版本下的可执行程序加上-d，此时经过修改之后。

我们可以清楚的看到两个模式下的可执行程序的文件大小，刚好可以验证我们上面的结论。通过文件大小能验证Debug确实增加了调式信息，但是我们想看到更详细的调试信息。

readelf 是一个用于读取 ELF（Executable and Linkable Format，可执行和可链接格式）文件的命令行工具。ELF 是一种用于在Unix和类Unix系统上执行程序的标准文件格式。readelf 工具允许用户查看 ELF 文件的内部结构、头部信息、节（sections）、程序头部、符号表等内容。

该工具通常在开发和调试过程中使用，以便分析可执行文件或共享库的细节，了解它们的结构和元数据。通过 readelf，用户可以获取关于 ELF 文件的各种信息，例如代码段和数据段的大小、链接地址、节头表、符号表等。

然后我们在删除刚刚两个版本的文件，重新make一个Debug模式的可执行程序mytest文件，然后开始调试mytest文件。

gdb调试相关指令学习 - 平替 - vs上的调试

gdb binFile 退出： ctrl + d 或 quit 调试命令：

2. 学习 git 命令行的简单操作, 能够将代码上传到 Github 上

2.1.什么是git？理解版本控制器

git是一个分布式版本控制系统，用于跟踪项目代码的变化。

版本控制器（Version Control System，VCS）是一种记录和管理文件或代码变更的系统。它追踪文件的历史变更，允许用户回溯到先前的状态，并支持多人协同开发。

2.2.什么是github/gitee？

GitHub：GitHub是一个基于Git的代码托管平台，提供了代码仓库的托管服务。开发者可以将他们的项目代码存储在GitHub上，并与团队成员协同工作。GitHub也提供了许多协作和社交功能，如问题跟踪、代码审查、项目管理等，使得团队协作更加便捷。

Gitee：Gitee（码云）是中国的一个类似GitHub的代码托管平台，同样基于Git。它提供了类似的代码仓库托管服务，并支持团队协作。Gitee也提供了一些特有的功能，以满足中国开发者的需求，如在线构建、镜像仓库等。

总的来说，Git是版本控制系统，而GitHub和Gitee是基于Git的代码托管平台，它们提供了一些额外的功能来帮助开发者更好地进行协同开发。

2.3.使用 git 命令行

安装git - 必须先安装指令

yum install -y git

由于github是国外的网站，我们访问起来速度较慢，于是这里使用gitee作为我们的样例。

在 Github 创建项目

• No.1：注册自己的gitee账号，然后进入自己的个人主页，点击右上角的+号，点击新建仓库

• No.2：在进入创建的仓库界面后，设置仓库的名称，如果我们想将该仓库分享给别人，就可以设置开源，初始化现在选择C语言，.gitignore 是在本地仓库上传到远端仓库的时候，不会上传不必要的或敏感的文件提交到代码仓库。例如，编译产生的临时文件、操作系统生成的文件、一些配置文件等，通常不应该包含在版本控制中，而 .gitignore 文件就是告诉 git 忽略这些文件的规则，这里也选择C。模板设置 Readme文件 是为了让其他开发者或用户更容易理解和使用你的项目而创建的。它可以包含项目的概述、依赖关系、配置信息、使用示例等。分支模型涉及到开发，目前这个仓库只有我们一个人用，所以我们这里就不需要设置了。

• No.3：进入到我们刚才创建的仓库，点击克隆，选择HTPPS，复制下面的链接。

• No.4：git clone [url]，这里的 url 就是刚刚复制好的 项目 的链接.

• No.5：第一招git add .，.代表当前目录下所有文件，第二招git commit -m "提交日志信息（必须好好写）"，如果是第一次，我们这里还需要输入以下两个指令：

git config --global user.name "gitee 用户名"
git config --global user.email "gitee邮箱地址"

第三招，git push需要填入用户名密码，然后就提交到我们的远端仓库了。

图解：

解释：

1. git clone:

   • 用途：从远程仓库克隆（复制）整个代码库到本地。
   • 示例：git clone https://github.com/example/repo.git

2. git add:

   • 用途：将工作目录中的修改添加到暂存区，为下一次提交做准备。
   • 示例：git add filename（将指定文件添加到暂存区）或 git add .（将所有修改添加到暂存区）。

3. git commit:

   • 用途：将暂存区中的修改提交到本地仓库，创建一个新的版本（commit）。
   • 示例：git commit -m "Commit message"

4. git push:

   • 用途：将本地仓库的提交推送到远程仓库。
   • 示例：git push origin master（将本地的 master 分支推送到远程仓库的 master 分支）。

• No.6：提交成功到远端仓库

上面就是本地仓库提交到远端仓库的步骤。现在我们来看一下我们刚刚的提交日志信息：git log

        上面的图片中commit后面跟的一串是commit的ID，每一次修改都有一次commit的ID，于是我们就可以通过用哪个commit的ID，就可以看到曾经修改的哪个版本。Author是我们刚才配置邮箱和用户名，这是为了标识你是代码的提交者。这信息会被包含在每次提交中，以记录是谁进行了代码的更改。这对于团队协作和代码贡献追踪非常重要。

  git status 是 Git 中用于查看工作区（working directory）和暂存区（staging area）状态的命令。运行这个命令可以告诉你当前工作目录中文件的状态以及是否有文件修改未提交。

此时会显示工作目录中未被 Git 跟踪的文件和已修改的文件，但不会显示任何文件已暂存（staged）或提交（committed）的状态。

这是已经通过 git add 添加到暂存区但尚未通过 git commit 提交到版本库的文件。

此时显示没有文件需要 commit ，当前暂存区干净。

通过 git add push 推送到远端仓库，下面是推送后的状态

删除仓库文件的步骤

此时我们还可以通过git log查看日志信息

在Git中，git branch是用来管理分支的命令。

查看分支： 使用git branch命令可以列出当前仓库中存在的所有分支。当前分支前会有一个星号(*)表示当前所在的分支。

git branch

通过合理使用分支，可以更方便地进行代码的管理和协同开发。分支允许多个开发者在同一时间内独立地开发不同的功能或修复不同的bug，而不会互相影响。每个分支都代表着一个特定的工作线，开发者可以在不干扰其他工作的情况下进行自己的修改和实验，最后合并到master分支，能保证此时出现极少的错误。

.gitignore 是一个用于指定在版本控制系统中忽略哪些文件或目录的配置文件。在一个Git仓库中，有些文件是不希望被纳入版本控制的，比如编译生成的文件、临时文件、日志文件等。.gitignore 文件告诉Git哪些文件或目录应该被忽略，从而不会被提交到版本库中。通过使用 .gitignore 文件，你可以确保不必要的文件不会被提交到版本库中，从而保持版本库的干净和有序。

现在我们来验证一下，我们想设置.txt文件不被提交到远端仓库。

此时我们修改了.gitignore文件，因为.gitignore也是工作区的文件，也要被上传到远端仓库，但是我们此时先不上传到远端仓库。

上传到远端仓库后，我们创立一些文件来验证一下

然后我们使用我们的三板斧上传到远端仓库

但是我们发现.txt后缀的文件被上传到远端仓库了，为什么呢？这是因为在.gitignore中被忽略的文件前面加上了*，这里的*就是通配符的意思，这里必须要带上*，表示所有后缀为.txt的文件。

我们现在才来创建文件试一试

此时我们就发现3.txt文件就没有同步到远端仓库

通过上面的样例，我们可以发现.gitignore我们没有立即同步到远端仓库，而也可以立即生效，它是在git add的时候已经将.gitignore加载到暂存区，并且此时就会过滤这些文件。当您在本地进行 git add 操作时，Git 会将已跟踪的文件和新添加的文件添加到暂存区。.gitignore 文件的规则在这个阶段就会生效，被指定忽略的文件将不会被包含在暂存区中。

总结：

git如何进行多人协作 - 并行开发，串行提交

多人协作是Git的一个强大功能，以下是一般的多人协作流程：

1. 创建远程仓库： 通常，多人协作的项目会有一个中央远程仓库，比如在GitHub、Gitee或Bitbucket上创建一个项目仓库。

2. 每个人克隆仓库： 每个团队成员将远程仓库克隆到本地，使用如下命令：

   git clone <远程仓库URL>
   

3. 创建分支： 为了避免直接在主分支上工作，每个人都应该在本地创建一个新的分支，用于开发特定的功能或修复问题。

   git checkout -b <新分支名称>
   

4. 进行开发： 每个人在自己的分支上进行开发工作。使用git add和git commit来保存更改。

   git add . git commit -m "描述提交的更改"
   

5. 推送到远程仓库： 当开发工作完成并且代码已经经过测试，将本地分支推送到远程仓库。

   git push origin <分支名称>
   

6. 合并分支： 使用 pull request（GitHub、GitLab等平台）或 merge 请求（Bitbucket），将特性分支合并到主分支。这样可以进行代码审查和确保代码质量。

7. 更新本地仓库： 每个人在开始新的工作前应该定期更新他们的本地仓库，以包含其他人的更改。

   git pull origin master
   

8. 解决冲突： 如果多人在同一部分修改了代码，可能会发生冲突。在这种情况下，Git 会提示您解决冲突。

        产生冲突的原因是：比如Windows用户此时上传了修改这个代码，此时远端仓库就和这个Windows用户同步了，然后Linux用户再对这个代码进行上传，此时就会因为远端仓库没有和Linux用户本地仓库同步发生冲突。

所以此时就要远端仓库和Linux用户本地仓库同步，git pull 用于将远程仓库的最新更改拉取到本地并合并，以保持本地仓库与远程仓库同步。

git pull

此时我们就可以上传到远端仓库了，我们不仅能看到Linux在本文件中修改的代码，还能看到Windows用户修改的代码。所以git仓库如果本地和远端不同步，此时如果想要其他用户上传到远端仓库，git会强制你进行同步，一旦提交成功后，对于任何人，此时你修改的代码会被所有人看到。   

上面我们每次git push的时候都需要输入用户和密码，比较麻烦，我们可以配置免密码提交

https://blog.csdn.net/camillezj/article/details/55103149