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

CamusWon_drink
79 阅读10分钟

版本控制的最佳实践

版本控制的最佳实践是一些通用的规则和原则，可以帮助团队更好地管理代码、保持整洁的代码库，并提高协作效率。

  1. 使用合适的版本控制工具：

    • 选择适合你项目需求的版本控制工具，如Git、SVN等。
    • 学习并熟练掌握所选工具的基本命令和特性。

  2. 小而频繁的提交：

    • 将更改分成小的逻辑单元，并频繁地提交代码。
    • 每次提交应该只包含一个完整的、可测试的更改。
    • 这样做有助于追溯和回滚特定的更改，并减少解决冲突的可能性。

  3. 原子性提交：

    • 每个提交应该只包含相关的更改。
    • 避免将无关的更改混在同一个提交中，以降低代码审查和版本回滚的复杂性。

  4. 有意义的提交信息：

    • 提供有意义和简明的主题描述，准确说明本次提交的目的或内容。
    • 可以在提交信息中提供额外的说明，例如上下文、解决问题的方法、涉及的依赖等。

  5. 定期拉取更新：

    • 在开始工作之前，定期从远程仓库拉取最新的更新。
    • 这样可以避免与他人的更改产生冲突，并保持代码库的同步性。

  6. 分支管理：

    • 基于功能、任务、修复等创建合适的分支来隔离不同的开发工作。
    • 对于长期存在的功能分支，定期进行合并和测试，以减少冲突和集成的复杂性。

  7. 代码审查：

    • 进行定期的代码审查，以确保代码质量、合理性和一致性。
    • 使用版本控制工具提供的协作功能，例如Pull Request或Patch等，来支持代码审查流程。

  8. 标签管理：

    • 使用版本标签来标识重要的里程碑、发布版本或修订版本。
    • 按照规范的版本号命名约定来创建标签，例如"v1.0.0"表示第一个稳定版本。

  9. 文档化和注释：

    • 对代码进行良好的文档化，包括函数、类、模块等的说明。
    • 添加有意义的注释，解释代码的目的、意图和特殊处理等。

  10. 持续集成和自动化测试：

    • 使用持续集成工具（如Jenkins、Travis CI等）来自动化构建、测试和部署流程。
    • 编写自动化测试用例，确保新的更改不会破坏已有的功能。

这些最佳实践有助于提高代码的可读性、维护性和可追溯性，减少错误、冲突和问题的发生。在团队协作中，它们可以帮助成员更高效地合作、管理代码库，并确保项目的整体质量和可持续性发展.

下面简单介绍版本控制系统之一的Git在团队协作中的使用。

Git简介

Git是一种由c语言开发的分布式版本控制系统

  • 集中式版本控制系统，版本库集中存放在中央服务器，进行文件处理时需要从中央服务器中取出最新版本到本地电脑中，处理完成后再将处理过的文件推送给中央服务器。（就像从图书馆借书回家自己修改然后再把书放回图书馆）
  • 分布式版本控制系统，每台电脑都是一个完整的版本库，无需联网进行工作。（每台电脑都是一个图书馆）

创建版本库

版本库即repository，也称仓库。里面所有文件都可以被Git管理，也包括每个文件的修改、删除。

进行创建

mkdir day //创建一个空目录 我这个示例名叫day
cd day //进入该目录
git init //初始化该目录为Git可以管理的repository

随便什么文件，txt、py、js都行，放入day目录。 这里以nj.txt进行举例,其内容为：

you got me looking for attention

我们用命令git add nj.txt告诉Git将此文件添加到repository。
然后git commit -m "updatenow"将文件提交到repository。
需要简单解释一下的是-m "xx"是在提交文件时附带的注释信息，自己编写，可以简单解释修改的内容也可以帮助我们在诸多版本中更快找到需要的历史版本。
命令执行成功之后git会提示被改动的文件数目和有几处修改。最后git push就可以push到远程repository中（如果你有的话）。

分支

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。

简单介绍

Git里面默认一个主分支叫master，当Git创建一个新分支时，增加一个dev指针，改变默认指向master分支的指针HEAD的方向be like：

image.png 在新分支上提交的新修改就是针对dev指针指向的记录了，master部分不变。由上图可以很好理解。


分支在团队协作中的作用

分支为团队提供了灵活性和可靠性，使得团队能够更高效、更协调地协同工作，并最大限度地提高软件开发过程的质量和效率。

主要作用
并行操作分支允许团队成员同时在不同的分支上进行开发工作，而不会相互干扰。不同的功能特性或修复可以在各自的分支上进行独立的开发，使团队能够并行推进多个任务，提高整体开发效率。
版本控制版本控制：分支为团队提供了对代码的版本控制能力。每个分支都代表了一个特定的状态或功能，可以根据需要创建、切换和合并分支，以保留和追溯不同时间点的代码快照。这为团队在开发过程中实现功能迭代、Bug修复和发布准备等提供了灵活性和可靠性。
独立测试通过使用分支，团队成员可以在自己的分支上进行测试和验证，而不会对其他人的工作产生不良影响。每个分支都可以拥有独立的测试环境，团队成员可以自由地进行单元测试、集成测试和验收测试，从而更好地保证软件质量。
Bug修复与热修复分支使得团队能够快速响应并修复潜在的问题。当团队发现生产环境中的Bug时，可以创建一个新的分支来修复问题，而不会影响正在进行的其他开发工作。这允许团队在最短的时间内修复Bug并快速部署修复版本。
代码审查分支为团队提供了进行代码审查的理想环境。每个成员可以在自己的分支上提交代码，并邀请其他团队成员对其代码进行审核。通过分支，团队能够实施有效的代码审查流程，以确保代码质量、减少潜在的错误和提高整体代码可维护性。

创建以及合并分支

创建

git checkout -b dev //表示创建并切换到dev分支
git branch// 查看当前分支，该命令会列出所有分支，当前分支前面会标一个*号。

确认后我们对nj.txt文件的修改就会提交到dev这个分支上。（提交步骤same）
当我们切换到其他分支（git checkout master），就会发现刚才修改的内容不见了——因为那个提交是在dev分支上，而master分支此刻的提交点并没有变。

合并

git merge dev//用于合并指定分支到当前分支，这里指合并dev分支到master分支上

合并后，就可以看到，master和dev分支的最新提交是完全一样的。如果不需要dev分支，就可以使用git branch -d dev命令删除分支dev。

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

当其他人从远程库clone时，默认情况下只能看到master分支，如果要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

git checkout -b dev origin/dev

然后就可以在dev分支上修改并提交。

解决冲突

当多个团队成员在不同的分支上修改同一个文件的相同部分时，就会发生冲突。Git 无法自动解决这些冲突，需要开发人员手动解决。

以下是一个简单的例子来说明 Git 分支中的冲突以及如何解决冲突的过程：

假设团队成员A和B在同一个项目的不同分支上进行开发，并且都对文件nj.txt作了修改。

  • 当A（分支dev）尝试将他自己在nj.txt的更改合并到master分支时
  • B（分支master）在nj.txt的同一位置提交了他的更改，并将其也推送到master分支。
  • Git 检测到冲突并提示冲突的文件。

Git 会将冲突的文件标记为包含冲突标记，如：

you got me looking for attention
<<<<<<< HEAD
cause i know what you like//这是A的更改
=======
drop the question//这是B的更改
>>>>>>> branch_B

解决冲突

A需要手动编辑冲突文件，决定如何解决冲突。

  • 可以根据需要保留、修改或删除特定部分。

在上面的例子中，A可以决定保留"A的更改"或者"B的更改"，或者将二者结合成一个新的更改。


最后提交解决：A在解决冲突后，更新文件并将其提交到主分支。
需要注意的是，在解决冲突之前，最好先将自己当前分支与目标分支保持同步，以便基于最新的代码进行冲突解决。此外，如果使用版本控制工具或IDE，它们通常都提供了可视化的界面来帮助解决冲突，简化了手动编辑文件的过程。

标签

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起

创建标签

git checkout master//切换到要打标签的分支
git tag xxx//打上标签xxx
git tag yyy commit_id//也可以通过对应的commit id进行创建标签

注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息，可以用命令git tag查看所有标签。还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字。

值得注意的是：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

commit同时出现在不同分支的情况：在合并完成后，master 分支将包含提交 B 的更改，它们会成为 master 分支的一部分。这意味着 master 分支和 dev 分支将指向同一个提交，从而使它们拥有相同的提交历史。 不过，合并分支并不会复制提交，而是将分支指针移动到合并后的提交上。所以在合并后的结果中只有一个实际的提交对象，它会被多个分支引用。

avatar
文章
阅读
粉丝