页面

分类

最平凡日子 最卑微梦想

git使用笔记

  • C++
  • 435 次阅读

git使用规范

在软件开发过程中，规范的分支管理能够有效提高团队协作和项目稳定性。下面是一种常见的分支管理策略——Git Flow，适用于大多数项目的版本管理。具体步骤如下：

Git Flow 分支管理模型

1. 主分支（Main or Master）

主要分支用于保存发布的正式版本。任何提交到主分支的代码都应该是稳定且准备发布的代码。

2. 开发分支（Develop）

开发分支是所有开发动作的基础分支。这个分支包含最新的开发代码，能够稳定运行但可能未经过全面测试。

3. 功能分支（Feature Branches）

这些分支用于开发新功能，每个新功能创建一个独立的功能分支。这些分支从开发分支中派生，完成后合并回开发分支。

  • 命名规范： feature/功能名称
  • 创建：从开发分支创建 git checkout -b feature/功能名称 develop
  • 合并回开发分支：功能完成后合并回开发分支 git checkout develop 然后 git merge --no-ff feature/功能名称
  • 删除：合并完成后删除 git branch -d feature/功能名称

4. 发布分支（Release Branches）

当准备发布一个新的版本时，从开发分支创建一个发布分支。这些分支用于修正Bug和准备发布，包括更新版本号、文档等。完成后合并到主分支和开发分支。

  • 命名规范： release/版本号
  • 创建：从开发分支创建 git checkout -b release/版本号 develop
  • 合并到主分支：发布完成并合并到主分支 git checkout main 然后 git merge --no-ff release/版本号
  • 合并回开发分支：然后将这些改动合并回开发分支 git checkout develop 然后 git merge --no-ff release/版本号
  • 删除：合并完成后删除 git branch -d release/版本号

5. 热修复分支（Hotfix Branches）

这些分支用于修复生产环境中的紧急问题。它们直接从主分支创建，修复完成后合并回主分支和开发分支。

  • 命名规范： hotfix/修复描述
  • 创建：从主分支创建 git checkout -b hotfix/修复描述 main
  • 合并到主分支：修复完成并合并到主分支 git checkout main 然后 git merge --no-ff hotfix/修复描述
  • 合并回开发分支：然后将这些改动合并回开发分支 git checkout develop 然后 git merge --no-ff hotfix/修复描述
  • 删除：合并完成后删除 git branch -d hotfix/修复描述

示例工作流程

  1. 创建开发分支：

    git checkout -b develop main

  2. 创建功能分支进行开发：

    git checkout -b feature/add-new-feature develop
[进行开发...]
git checkout develop
git merge --no-ff feature/add-new-feature
git branch -d feature/add-new-feature

  3. 准备发布：

    git checkout -b release/v1.0 develop
[修正Bug，准备发布...]
git checkout main
git merge --no-ff release/v1.0
git checkout develop
git merge --no-ff release/v1.0
git branch -d release/v1.0

  4. 紧急修复：

    git checkout -b hotfix/fix-critical-bug main
[进行修复...]
git checkout main
git merge --no-ff hotfix/fix-critical-bug
git checkout develop
git merge --no-ff hotfix/fix-critical-bug
git branch -d hotfix/fix-critical-bug

通过使用Git Flow模型，你可以清晰地管理不同类型的工作并确保代码质量，减少合并冲突，同时保证主分支的稳定。

功能分支（Feature Branch）命名一般遵循一定的规范，从名称中可以清楚地知道该分支的目的或正在进行的功能。常见的命名惯例是在分支名称前加上「feature/」，后接简要描述功能的关键词或JIRA号、任务编号等。下面是一些具体示例：

  1. 基于功能描述：

    • feature/user-login
    • feature/payment-integration
    • feature/update-profile-page
    • feature/shopping-cart

  2. 基于任务编号或JIRA号：

    • feature/JIRA-1234-user-login
    • feature/issue-5678-payment-integration

  3. 结合功能描述和任务编号：

    • feature/JIRA-2345-update-profile-page
    • feature/TASK-7890-shopping-cart

示例说明

  1. feature/user-login：

    • 这个分支名称清晰地表明该分支用于开发“用户登录”功能。任何需要实现用户登录功能的代码更改都在该分支中进行。

  2. feature/payment-integration：

    • 该分支用于支付集成功能的开发，包括与第三方支付服务的对接、支付流程的实现等。

  3. feature/JIRA-1234-user-login：

    • 这里的分支名称结合了JIRA任务号和功能描述，便于追踪任务进度和了解分支的目标。

  4. feature/issue-5678-payment-integration：

    • 该分支创建用于处理编号为5678的任务，目标是实现支付集成功能。

  5. feature/JIRA-2345-update-profile-page：

    • 分支名称表明它与JIRA上编号为2345的任务相关，主要用于用户个人资料页面的更新功能开发。

举例的实际操作

假设项目开发中新添加用户登录功能，开发人员Alice收到任务并创建功能分支：

# 从develop分支创建功能分支
git checkout -b feature/user-login develop

# Alice在feature/user-login中进行开发
[开发用户登录功能...]

# 将功能开发完成后合并回开发分支
git checkout develop
git merge --no-ff feature/user-login

# 删除功能分支
git branch -d feature/user-login

通过遵循这样的分支命名和使用规范，团队成员可以轻松地识别每个分支的用途，方便协作和代码管理。

合并分支时，不同的策略可以影响代码库的历史记录、可读性以及维护性。常用的合并策略包括创建合并提交（merge commit）、压缩合并（squash and merge）和变基（rebase）。下面分别介绍它们的特点及使用场景。

创建合并提交（Merge Commit）

特点

  • 保留所有历史记录：原分支的所有提交记录都保留，且生成一个新的合并提交。
  • 显示分支结构：可以直观查看分支合并情况、来源以及合并点。

适用场景

  • 团队协作：需要保留详细的开发历史，以便追踪每次更改的详细过程。
  • 复杂项目：多分支并行开发，清楚显示合并结构有助于理解完整的开发流程。

操作

git checkout target-branch
git merge source-branch

压缩合并（Squash and Merge）

特点

  • 简化历史记录：将源分支的所有提交压缩成一个提交，合并到目标分支。
  • 减少噪音：适用于源分支中有很多小而琐碎的提交，需要简化提交历史。

适用场景

  • 单个功能：功能分支包含很多中间提交（例如小修复、调试输出等），希望在目标分支中只保留一个清晰的功能完成记录。
  • 代码审查后：代码审查过程中产生了多个小提交，最终合并希望保留简洁、易读的历史记录。

操作

通过GitHub或GitLab等平台的Web UI操作，通常有一个 Squash and Merge 选项，或者在命令行中：

git checkout target-branch
git merge --squash source-branch
git commit -m "合并源分支并压缩：source-branch"

变基（Rebase）

特点

  • 重写历史：将源分支的提交重新应用在目标分支基础上，形成线性的提交历史。
  • 干净历史：避免了合并提交，使得提交历史更加线性和直观。

适用场景

  • 个人项目：你是唯一的开发者或有极少数人参与，重写历史的风险低。
  • 代码整理：希望在合并前整理和清理提交历史，形成干净的线性提交史。

注意事项

  • 禁止在公共分支上变基：非必要时，避免在已推送和多人协作的公共分支上使用变基，否则会导致其他人仓库的历史记录冲突。

操作

# 切到源分支进行变基
git checkout source-branch
git rebase target-branch

# 解决冲突后，继续变基
git rebase --continue

# 切回目标分支并快速前推（保证目标分支是最新的）
git checkout target-branch
git merge source-branch

总结

  • 创建合并提交：适用于需要保留完整详细的历史记录，适合团队协作、复杂项目。
  • 压缩合并：适用于简化历史记录，功能开发中产生了很多中间提交的情况。
  • 变基：适用于整理提交史，形成线性历史，但要谨慎使用，不要在公共分支上重写历史。

选择哪种合并策略，需根据项目的具体需求和团队协作方式综合考虑。

标签： git