8.1 工程的配置管理

8.1.1 创建与管理不同的工程配置（如 Debug、Release）

在 IAR EWARM 中，工程配置允许我们针对不同的需求（如调试和发布）设置不同的编译和链接参数。

创建 Debug 配置：

1. 打开 IAR EWARM 并加载你的工程。
2. 在菜单栏中选择 Project -> Options。
3. 在弹出的 Options for Project 对话框中，在 General Options -> Target 下，你可以看到当前的配置，通常默认是 Debug。如果没有，点击 Add 按钮。
4. 在 Add Configuration 对话框中，输入配置名称为 Debug，然后点击 OK。

创建 Release 配置：

1. 重复上述步骤 1 - 2。
2. 在 Options for Project 对话框中，点击 Add 按钮。
3. 在 Add Configuration 对话框中，输入配置名称为 Release，然后点击 OK。

管理不同配置：

• 设置配置特定参数：
  • 在 Options for Project 对话框中，不同的配置选项卡（如 C/C++ Compiler、Linker 等）下的设置会根据当前选择的配置而应用。例如，在 Debug 配置下，你可能希望启用更多的调试信息，而在 Release 配置下，更注重优化代码大小和速度。
  • 在 C/C++ Compiler -> Optimization 中，对于 Debug 配置，你可以选择较低的优化级别（如 None）以便于调试，而对于 Release 配置，选择较高的优化级别（如 High）来减小代码体积和提高执行效率。
• 切换配置：
  • 在 IAR EWARM 的工具栏中，有一个配置选择下拉框，你可以通过它快速切换不同的工程配置，如从 Debug 切换到 Release，反之亦然。

8.1.2 根据不同配置进行编译与调试

编译：

• Debug 配置编译：
  • 确保在工具栏的配置选择下拉框中选择了 Debug 配置。
  • 点击菜单栏中的 Project -> Make 或者使用快捷键 F7。IAR EWARM 将根据 Debug 配置下的编译和链接参数进行编译。编译过程中，编译器会生成包含调试信息的目标文件，这有助于后续的调试工作。例如，调试信息可以让你在调试时查看变量的值、函数调用栈等。
• Release 配置编译：
  • 将工具栏中的配置切换为 Release。
  • 同样点击 Project -> Make 或按 F7。此时，编译器会根据 Release 配置下的参数进行编译，通常会应用更高的优化级别，生成的代码体积更小、执行速度更快，但可能会牺牲一些调试信息。

调试：

• Debug 配置调试：
  • 编译完成后，确保当前配置为 Debug。
  • 点击菜单栏中的 Debug -> Go 或者使用快捷键 F5 启动调试会话。在调试过程中，由于编译时包含了丰富的调试信息，你可以使用各种调试工具，如设置断点、单步执行、查看寄存器和变量值等。例如，在代码中设置断点后，程序运行到断点处会暂停，你可以查看此时各个变量的值，检查程序逻辑是否正确。
• Release 配置调试：
  • 虽然 Release 配置主要用于生成最终发布的代码，但也可以进行一定程度的调试。切换到 Release 配置并编译后，启动调试。然而，由于优化可能会改变代码的执行顺序和变量的存储方式，调试可能会变得相对困难。例如，某些变量可能在优化后被优化掉，导致无法在调试时查看其值。但在一些情况下，仍然可以通过设置断点和观察程序行为来排查问题。

8.2 工程的版本控制

8.2.1 版本控制的概念与重要性

版本控制的概念：
版本控制是一种记录文件（如代码文件、文档等）变化历史的系统。它允许你跟踪文件的每一次修改，记录修改者、修改时间、修改内容等信息。例如，在软件开发中，随着代码的不断开发和修改，版本控制系统可以记录每一行代码的变化，就像一个时间机器，让你可以随时回到某个特定的版本状态。

版本控制的重要性：

• 历史记录与追溯：当出现问题时，可以通过查看历史版本，找到问题出现前的代码状态，从而快速定位和解决问题。例如，如果新功能引入了一个 bug，通过查看版本历史，可以确定是从哪个版本开始出现问题的，进而分析相关的代码修改。
• 多人协作：在团队开发中，版本控制是必不可少的。多个开发者可以同时在自己的工作副本上进行开发，然后通过版本控制系统将各自的修改合并到共享的代码库中。它可以避免代码冲突，确保每个开发者的工作都能被正确整合。例如，两个开发者同时修改了同一文件的不同部分，版本控制系统可以自动合并这些修改；如果修改了同一部分，它会提示冲突，让开发者手动解决。
• 实验与分支：可以创建不同的分支进行实验性开发，而不影响主代码的稳定性。例如，在开发新功能时，可以创建一个新的分支，在这个分支上进行开发和测试，当功能稳定后，再将分支合并到主分支。

8.2.2 使用 Git 进行 IAR 工程版本控制

安装 Git：
从 Git 官方网站（https://git-scm.com/downloads）下载并安装适合你操作系统的 Git 版本。安装过程中可以选择默认设置，安装完成后，你可以在命令行中使用 git 命令。

初始化 Git 仓库：

1. 打开命令行，导航到你的 IAR 工程所在的目录。例如，如果你的工程位于 C:\Projects\MyIARProject，则在命令行中输入 cd C:\Projects\MyIARProject。
2. 初始化一个新的 Git 仓库，输入命令 git init。这会在当前目录下创建一个隐藏的 .git 文件夹，用于存储版本控制的相关数据。

添加文件到版本控制：

1. 查看当前文件状态，输入命令 git status。此时会显示哪些文件是新的（未跟踪的），哪些文件已被修改等信息。
2. 添加所有文件到暂存区，输入命令 git add.（注意 . 表示当前目录下的所有文件）。这会将所有文件标记为准备提交到版本库。
3. 再次查看文件状态，输入 git status，会看到文件已被添加到暂存区，等待提交。

提交更改：

1. 提交暂存区的文件到版本库，输入命令 git commit -m "Initial commit"。这里的 -m 选项用于添加提交信息，描述本次提交的内容，“Initial commit” 表示这是初始提交。
2. 每次对工程文件进行修改后，重复上述添加文件到暂存区（git add.）和提交更改（git commit -m "描述修改内容"）的步骤，以记录每一次修改。

创建与切换分支：

• 创建分支：假设要创建一个名为 feature - new - function 的分支，用于开发新功能，输入命令 git branch feature - new - function。
• 切换分支：要切换到新创建的分支，输入命令 git checkout feature - new - function。此时，你在该分支上进行的修改不会影响主分支（通常是 master 分支）。

合并分支：
当在 feature - new - function 分支上完成新功能开发并测试通过后，需要将其合并到主分支。

1. 切换回主分支，输入命令 git checkout master。
2. 合并 feature - new - function 分支到主分支，输入命令 git merge feature - new - function。如果没有冲突，Git 会自动将分支合并。如果有冲突，需要手动解决冲突后再提交。

8.2.3 协同开发中的版本控制流程与实践

克隆仓库：
当团队成员加入项目时，需要从共享的代码仓库克隆项目到本地。假设共享仓库的地址是 https://github.com/your - team/your - project.git，在命令行中输入 git clone https://github.com/your - team/your - project.git。这会在本地创建一个与远程仓库相同的副本，包括所有的文件和版本历史。

拉取更新：
在开始工作前，团队成员应该先拉取远程仓库的最新更新，以确保本地代码是最新的。在本地项目目录的命令行中输入 git pull。这会将远程仓库的最新更改下载并合并到本地分支。

开发与提交：

1. 团队成员在自己的本地分支上进行开发工作，完成一部分功能或修复一个问题后，按照前面提到的添加文件（git add.）和提交更改（git commit -m "描述修改内容"）的步骤，将自己的修改提交到本地仓库。
2. 例如，开发者 Alice 在 feature - user - login 分支上开发用户登录功能，完成一部分代码后，她提交了自己的修改：

git add.
git commit -m "Implement basic user login functionality"

推送更改：
当团队成员完成一个功能模块的开发并在本地测试通过后，需要将本地分支的更改推送到远程仓库。假设 Alice 完成了 feature - user - login 分支的开发，她输入命令 git push origin feature - user - login。这里的 origin 是远程仓库的默认名称，feature - user - login 是要推送的分支名称。

合并请求与代码审查：

1. 在远程仓库平台（如 GitHub）上，团队成员创建一个合并请求（Pull Request，简称 PR），请求将自己的分支合并到主分支或其他目标分支。例如，Alice 在 GitHub 上创建一个将 feature - user - login 分支合并到 master 分支的 PR。
2. 其他团队成员（通常是项目负责人或相关的代码审查者）对 PR 进行代码审查。他们会检查代码的质量、是否符合编码规范、功能是否正确等。如果有问题，会在 PR 中提出评论，要求开发者进行修改。
3. 开发者根据评论进行修改，然后再次提交并推送更改，直到代码审查通过。

解决冲突：
在合并过程中，如果不同开发者对同一文件的同一部分进行了修改，就会产生冲突。例如，Alice 和 Bob 都修改了 main.c 文件的同一函数。

1. 当 Alice 尝试合并她的分支时，Git 会提示冲突。她需要打开产生冲突的文件（main.c），会看到类似以下的标记：

<<<<<<< HEAD
// 这是主分支上的代码
int oldFunction() {
    return 0;
}
=======
// 这是 Alice 修改后的代码
int oldFunction() {
    return 1;
}
>>>>>>> feature - user - login

2. Alice 需要根据实际情况手动解决冲突，删除冲突标记，并保留正确的代码。例如，她决定采用自己修改后的代码，删除冲突标记和主分支上的旧代码：

int oldFunction() {
    return 1;
}

3. 解决冲突后，Alice 再次添加文件（git add main.c）并提交更改（git commit -m "Resolve conflict in main.c"），然后重新推送更改到远程仓库，完成合并。