Git 的正确使用姿势与最佳实践：团队协作和版本控制的最佳实践 | 青训营

用户76596709022
65 阅读4分钟

在大型项目团队中使用 Git 进行协作是非常常见的做法。以下是一个大型项目团队协作的基本步骤示例：

  1. 项目规划和初始化：

    • 定义项目目标、范围和需求。
    • 选择合适的 Git 仓库托管平台（如 GitHub、GitLab、Bitbucket）。
    • 初始化主仓库，设置权限和分支保护规则。

  2. 分支策略：

    • 使用主分支（通常是 main 或 master）作为稳定版本的基础。
    • 使用特性分支（如 feature/ 前缀）来开发新功能，每个特性分支对应一个任务或需求。
    • 使用发布分支（如 release/ 前缀）来准备发布，进行测试和修复。
    • 使用热修复分支（如 hotfix/ 前缀）来处理紧急修复。
    • 使用开发分支（如 develop）来整合特性分支，保持最新开发状态。

  3. 团队协作：

    • 每个开发者从主仓库克隆项目到本地。
    • 在本地创建和切换到适当的分支进行开发。
    • 定期进行提交并推送到远程仓库，以便其他团队成员可以查看和审阅。
    • 使用 Pull Request（PR）或 Merge Request（MR）机制发起代码审查，确保代码质量。
    • 在代码审查通过后，将代码合并到开发分支或发布分支。

  4. 持续集成和部署：

    • 配置持续集成（CI）系统，如 Jenkins、Travis CI、CircleCI 等。
    • 在每次代码提交时自动运行测试套件，确保代码质量和稳定性。
    • 根据发布分支或主分支的状态，自动构建和部署到预定的环境中。

  5. 问题追踪和沟通：

    • 使用问题追踪工具（如 JIRA、GitHub Issues）来记录、分配和跟踪任务、缺陷等。
    • 通过团队聊天工具（如 Slack、Microsoft Teams）进行实时沟通和协作。

示例：

  1. 小明和小红是开发团队的成员，他们要合作开发一个新功能。他们遵循以下步骤：

    • 小明从主仓库克隆项目，创建一个名为 feature/user-auth 的特性分支，实现用户认证功能。
    • 小明进行了多次提交，然后推送到远程仓库，发起了一个 PR 请求。
    • 小红收到通知，审阅了代码，提出了一些修改意见，小明对代码进行了修改并再次提交。
    • 小红认可了修改后的代码，将 PR 合并到开发分支。

  2. 在项目准备发布时，团队遵循以下步骤：

    • 创建一个名为 release/1.0 的发布分支，用于准备发布版本 1.0。
    • 在发布分支上进行测试和修复，确保稳定性。
    • 如果发现重要的漏洞，团队会创建热修复分支，修复问题后合并到主分支和开发分支。

这些步骤和示例展示了在大型项目团队中使用 Git 进行协作的基本流程。实际项目中，还会根据团队的具体需求和流程进行调整和定制。

实践：记录一下我的git配置过程： 1024配置中的codespace配置过程： 创建go项目

删除main.go   和gomod

git clone git@github.com:RaymondCode/simple-demo.git

不行的话多试几遍

进入simple_demo，删除它自带的.git             rm -rf .git*     ls -a    保证simple_demo下不会存在.git了

git init

git remote add origin git@github.com:*/*.git

git add .

git commit -m "first commit"                                                             -->

git push

git pull --rebase origin master

在团队协作的软件开发过程中，多人同时修改同一个文件可能会引发代码冲突。Git是一个版本控制系统，提供了解决冲突的工具和流程。下面是解决Git冲突的一般步骤：

  1. 拉取更新： 在开始工作之前，先拉取远程仓库的最新代码，以确保你的本地代码是最新的。可以使用命令 git pull origin <branch-name>，其中 <branch-name> 是你当前工作的分支。
  2. 发现冲突： 如果多人修改了同一个文件的相同部分，Git 会标记出冲突的地方，通常在代码中会有类似以下的标记：在冲突标记处，手动编辑代码以保留需要的修改。你可以选择保留你的修改、保留远程仓库的修改，或者在两者之间进行调整。删除冲突标记后，将代码修改为你期望的最终状态。
    1. 添加和提交： 解决冲突后，使用 git add <conflicted-file> 将解决后的文件标记为已解决。然后使用 git commit 提交这些修改，可以在提交信息中描述解决了哪些冲突。
  4. 推送更改： 如果你的解决冲突是在一个分支中完成的，最后使用 git push origin <branch-name> 将解决冲突后的分支推送到远程仓库。
  5. Code Review（可选）： 如果你的团队进行代码审查，确保其他开发人员能够检查你的解决冲突方式是否合适。
avatar
文章
阅读
粉丝