慧见

Git-使用指南

—

由

慧见
于

简介

Git 是一个分布式版本控制系统，广泛用于代码管理和团队协作。本文将介绍 Git 的基本概念和常见操作，帮助新手快速上手。

基本概念

  • 版本控制：跟踪文件的修改历史，方便回滚和协作。
  • 仓库 (Repository)：存储代码的地方，分为本地仓库和远程仓库。
  • 分支 (Branch)：代码开发的分支路径，便于多人并行开发。
  • 提交 (Commit)：保存代码的快照，每次提交记录一次文件的改动。
  • 远程仓库 (Remote Repository)：存储在服务器上的仓库，便于团队协作。

安装与配置

下载 Git 并根据操作系统安装。

Git官网

查看版本

git --version

配置用户名和邮箱

Git 会使用这些信息标记提交记录。

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

查看配置

git config --list

基本操作

1. 初始化仓库

在本地创建一个新的 Git 仓库：

git init

2. 克隆远程仓库

将远程仓库复制到本地：

git clone <repository-url>

3. 检查状态

查看工作目录的状态：

git status

4. 添加文件到暂存区

将文件从工作区添加到暂存区：

git add <file>

添加所有文件：

git add .

5. 提交代码

将暂存区的更改保存到本地仓库：

git commit -m "Commit message"

6. 查看日志

查看提交历史：

git log

简洁版日志：

git log --oneline

7. 推送代码到远程仓库

git push origin <branch-name>

8. 拉取远程更新

从远程仓库获取最新代码并合并到当前分支：

git pull

9. 分支管理

查看分支：

git branch

创建分支：

git branch <branch-name>

切换分支：

git checkout <branch-name>

创建并切换分支：

git checkout -b <branch-name>

合并分支：

git merge <branch-name>

删除分支：

git branch -d <branch-name>

10. 查看差异

查看文件更改：

git diff

11. 恢复更改

撤销暂存区的文件：

git reset <file>

恢复工作区的文件：

git checkout -- <file>

远程仓库操作

添加远程仓库

git remote add origin <repository-url>

查看远程仓库

git remote -v

删除远程仓库

git remote remove <name>

高级功能

打标签

创建一个标签：

git tag <tag-name>

推送标签到远程：

git push origin <tag-name>

代码暂存

保存当前工作进度：

git stash

恢复暂存的更改：

git stash pop

常见问题

问题 1: 提交后发现漏掉文件

解决：将漏掉的文件添加并使用 --amend 修改提交。

git add <file>
git commit --amend --no-edit

问题 2: 合并冲突

解决：手动解决冲突后，添加文件并提交。

git add <file>
git commit

问题 3: 回滚到之前的版本

回滚到某次提交：

git reset --hard <commit-hash>

Git 使用的最佳实践

  • 提交要对应修改：
    • 每次提交应对应一个相关的改动，便于理解和回滚。
    • 使用暂存区（git add）精准选择要提交的内容。
  • 经常性的提交修改：
    • 频繁提交改动，确保注释与改动保持一致性。
    • 快速提交减少代码整合时的冲突。
  • 不要提交不完整的改动：
    • 将大功能拆分成小的逻辑模块进行提交。
    • 使用 git stash 存储未完成的改动，而非提交。
  • 提交前进行代码测试：
    • 确保提交的代码已经通过完整的测试。
    • 确认无误后再推送到远程仓库。
  • 高质量的提交注释：
    • 提交信息应包括少于 50 字的标题和详细改动说明。
    • 使用现在时态的祈使句（如 “Add feature” 而非 “Added feature”）。
  • 版本控制不是备份：
    • 仅提交有意义的改动，避免将版本控制系统作为文件存储工具。
  • 使用分支功能：
    • 为新功能或修复创建分支。
    • 分支隔离可减少冲突，方便开发协作。
  • 合理的工作流程：
    • 根据团队和项目选择适合的流程（如 Git Flow）。
    • 一致遵循选定的工作流程。
  • 合并策略：
    • 使用 git rebase 清理提交历史。
    • 通过 Pull Request 审查代码，保证质量。
  • 解决冲突：
    • 尽早解决冲突，避免积累。
    • 仔细检查冲突后的代码，确保正确合并。
  • 做好忽略配置：
    • 使用 .gitignore 文件避免提交临时文件或编译产物。
  • 定期清理分支：
    • 删除无用的本地和远程分支，保持仓库整洁。
  • 备份重要分支：
    • 确保远程仓库有最新的代码备份。

Git工作流

你的本地仓库由 git 维护的三棵“树”组成。第一个是你的 工作目录，它持有实际文件；第二个是 缓存区（Index），它像个缓存区域，临时保存你的改动；最后是 HEAD，指向你最近一次提交后的结果。

分支管理的最佳实践

分支是用来将特性开发绝缘开来的。在你创建仓库的时候，Main 是“默认的”。在其他分支上进行开发，完成后再将它们合并到主分支上。

Main分支与Develop分支

这种工作流程不是使用单一的主分支(Main)，而是使用两个分支来记录项目的历史。主分支(Main)存储正式的发布历史，而开发分支(Develop)则作为功能的集成分支。同时，在主分支上的所有提交中标记版本号会更加方便。

第一步是为默认的主分支(Main)补充一个开发分支(Develop)。一种简单的方法是由一名开发者在本地创建一个空的开发分支，并将其推送到服务器

git branch develop
git push -u origin develop

这个分支将包含项目的完整历史，而主分支将包含一个精简版本。其他开发者现在应该克隆中央仓库，并为开发分支创建一个跟踪分支。

Feature分支

每个新功能都应存在于其独立的分支中，可以将其推送到中央仓库以便备份或协作。但功能分支不是从主分支派生，而是以开发分支为其父分支。当一个功能完成后，它会被合并回开发分支。功能分支(Feature)不应直接与主分支(Main)交互。

git checkout develop
git checkout -b feature_branch

当功能的开发工作完成后，下一步是将功能分支（feature_branch）合并到开发分支（develop）中。

git checkout develop
git merge feature_branch

Release分支

当开发分支（develop）积累了足够多的功能用于发布（或一个预定的发布日期临近）时，需要从开发分支中分叉出一个发布分支（release branch）。创建这个分支标志着下一个发布周期的开始，因此在此之后不能再添加新功能——此分支中只能进行错误修复、文档生成以及其他与发布相关的任务。当发布分支准备好后，它会被合并到主分支（main）并标记版本号。此外，该分支还应被合并回开发分支（develop），因为自发布分支创建以来，开发分支可能已经有了新的进展。

使用专门的分支来准备发布可以让一个团队专注于打磨当前的发布版本，而另一个团队继续为下一个版本开发新功能。这种方式还明确划分了开发阶段（例如，可以轻松地说“本周我们正在为版本 4.0 做准备”，并且可以在仓库结构中清晰地看到这些阶段）。

创建发布分支是另一个简单的分支操作。与功能分支类似，发布分支是基于开发分支的。可以通过以下方法创建一个新的发布分支。

git checkout develop
git checkout -b release/0.1.0

当发布版本准备好交付时，应将其合并到主分支（main）和开发分支（develop），然后删除发布分支。将发布分支的更改合并回开发分支非常重要，因为发布分支中可能加入了关键更新，而这些更新需要为后续的新功能开发所用。如果您的组织强调代码审查，这是一个发起拉取请求（pull request）的理想时机。

git checkout main
git merge release/0.1.0

Hotfix分支

维护分支或“热修复”（hotfix）分支用于快速修补生产环境的发布版本。热修复分支与发布分支和功能分支非常相似，但它们是基于主分支（main）而不是开发分支（develop）。这是唯一一个应该直接从主分支派生的分支。一旦修复完成，应将其合并到主分支和开发分支（或当前的发布分支）中，并在主分支上标记一个更新的版本号。

设置专门的修复分支可以让团队在不打断其他工作流程或等待下一个发布周期的情况下快速解决问题。可以将维护分支视为直接与主分支协作的临时发布分支。热修复分支可以通过以下方法创建：

git checkout main
git checkout -b hotfix_branch

与Release发布分支类似，热修复分支需要合并到主分支（main）和开发分支（develop）。

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

以下是一个展示功能分支流程（Feature Branch Flow）的完整示例。假设我们已经设置了一个包含主分支（main）的仓库。

git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branch

除了功能分支和发布分支流程外，热修复流程的示例如下：

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch

总结

  • 从主分支（master）创建一个开发分支（develop）。
    • 主分支（master）： 主要用于版本发布，存储生产环境的最终代码。
    • 开发分支（develop）： 用于日常开发，保存最新的开发代码。
  • 从开发分支（develop）创建一个发布分支（release）。
    • 发布分支（release）： 可以视为主分支的未测试版。当某一期功能开发完成后，将开发分支合并到发布分支，进行测试。如果测试通过且到了发布时机，就合并到主分支进行发布。
  • 从开发分支（develop）创建功能分支（feature）。
    • 功能分支（feature）： 由团队成员或个人创建，用于具体功能的开发。功能分支只与开发分支交互，不直接影响主分支。
  • 当一个功能完成后，将其合并回开发分支（develop）。
  • 当发布分支（release）准备就绪后，将其分别合并到开发分支（develop）和主分支（master），完成发布。
  • 如果在主分支（master）中检测到问题，从主分支创建一个热修复分支（hotfix）。
    • 热修复分支（hotfix）： 用于快速修复生产环境中的问题，是唯一直接从主分支派生的分支。
  • 热修复完成后，将热修复分支合并回开发分支（develop）和主分支（master）。
    • 这种流程确保了修复后的代码可以被后续开发使用，同时保持主分支的代码稳定性。

通过以上分支模型，每个分支都承担了明确的职责，促进团队协作和代码管理效率，同时确保开发、测试和发布流程的规范性和有序性。

资源推荐