自学内容网 自学内容网
自学内容网 > 正文

git使用教程(超详细)-透彻理解git

🕗 发布于 2024-12-10 00:36 git  

一.核心基础

首先请把与svn有关的一切概念暂时从你的脑海中移除掉，我们要重新认识本文所讲述的所有概念。

核心概念有六个

1.worktree

worktree是一个目录，你在这里对文件进行增加、删除、修改。也就是我们常说的工作区。在git中worktree必须要与一个branch(分支)关联。在常规情使用的况下，我们感知不到有这样一个关系存在，因为当我们clone一个git仓库时，默认的就已经把worktree关联到head指向的分支上了。请看下图

4debbaca904d44a486d5f8aecea3ef97.png

我在master分支的时候worktree是关联到master上的，我在wtr分支上的时候它就关联到wtr上了。

2.stage

这里我们先来看一下stage这个单词的根本含义，是指一个可以展现、进行或体验某些事件或活动的场所或状态。说白了就是舞台，供一些演员在上面表演用的。基于这层意思，worktree就是台下，stage就是台上，worktree里面的文件就是演员了，我们对演员的塑造就相当于我们对文件的增、删、改。我们对一个文件修改满意了，就可以把它丢到台上去。然而我们还可以继续在台下对这个文件进行修改，而不影响台上的文件，直到我们再次把这个文件丢到台上去。

使用  git add .     将台下所有修改丢到台上去

使用  git add xxxx   将某一个具体的文件的修改丢到台上去

3.commit

commit是一次交付，只有台上(stage)的内容才有资格交付。所有的commit都保存在git仓库中。这里有一个非常重要的观念需要明确一下，千万不要把commit的归属与branch(分支)联系在一起，commit不属于任何分支，在git中，分支的概念的基础是commit，没有commit就没有分支。现在我们来看一下commit中都包含了哪些内容，你就明白了。

commit的内容如下：

  1. commitID:在整个的git仓库中唯一标识一个commit。
  2. 父commitID: 在进行commit的时候，它的上一个commit的ID，就像区块链一样，每一个commit都有一个基础的commit。
  3. changes:本次commit的修改，也就是在进行commit时stage中的内容，说的再深入点就是本次commit与其父commit对比产生的变化的内容。
  4. 描述：包括作者、时间以及在commit时你通过-m 输入的描述信息。等等吧。

综上所述，一个commit就是一个完整的交付链或者是叫做提交历史，因为每一个commit都可以通过其父commitID往前追溯。这样来看，在某种意义上，是否每一个commit都可以成为一个分支呢？下面我们来说一下branch。

4.branch(分支)

分支，我们对分支最直观的感受就是，一个时间线上分布着这个分支的所有commit。而究其根本，在git中分支就两个作用。

一.   维护一个本分支当前最新的commit的ID，因为我通过一个commit就完全可以确定一个时间线了。这样我就只需要用一个分支文件记录当前最新的commitID即可。

bb21008efbdb428d94b86bcd60b45c8b.png

看看我的wtr分支上的最新提交是95e5137afceffdbf172dbcc8ce590695bba8e3d3

而分支文件refs/heads/wtr里记录的也是这个commit。

二.   当进行一次commit时，把分支文件中记录的commitID作为本次commit的父commitID。然后把本次commit的ID更新的分支文件中去。

这就是分支，他是我们维护交付链的工具。而不是commit的载体。

5.head

当前分支指针，它指向的是一个具体的分支文件。git永远把head指向的分支作为当前分支。

c56b3c9aa5294315b421b0620878afd8.png

HEAD文件里只记录了一个分支文件的地址。

6.git仓库

弄明白了上面5个概念，那么git仓库就很容易理解了。就是用于存储stage、commit、branch、head等等这些数据的地方。

二.git的基础行为

1. git init 仓库初始化

将一个目录初始化为一个git仓库，通常用于创建本地仓库。例如：

6e98f7f45d1041f39b0490cd1df4fed0.png

我将/d/workspace/gitdoc/gitrepos这个目录初始化成了一个git仓库，这个目录可以是个空目录也可以是一个有内容的目录(如果你想把目录下的内容都纳入到git仓库中去管理)。

我们也可以使用  git init --bare 来创建一个不带工作区和stage的仓库，这一般用来在服务器上创建一个共享仓库，因为不需要在这个仓库里工作，所以不带工作区和stage，它只是用来共享用的。如下

82d1c073bde740dc959b8f3f5207cc44.png

我把我的私服上的/home/gitdoc/reps.git  这个目录初始化成了一个共享仓库。我就可以在我本地使用git clone命令将其克隆下来了。

2. git clone 克隆

把一个远程仓库克隆到本地。一般是初次下载仓库时用这个命令。如下：

b18f89f9e4a54936a22c04aaeb83c95b.png

我从我的私服上克隆一个空的仓库。

3. git add  加入stage

现在我们在刚才克隆的空仓库中创建三个文件file1、file2、file3.然后执行git status看一下效果。

52dd1608582748b69fc1135963ba4b10.png

git status命令是显示git仓库当前的状态信息的。

我们可以看到3个文件是红色的，并且明确告诉你没有被git跟踪，这里我们就可以理解为这三个文件都在台下呢。现在我们先执行  git  add  file1  来看看效果。

0acbfb2af90d49608492f7ce5479bed6.png

可以看到file1已经被丢到台上了，现在如果执行git commit命令，就只会把file1打包交付。

好现在我们再执行   git add  .   看看有什么效果。

289462d39c29482bb0e3d1b1ffdcc6be.png

我们可以看到file1  和file2 都被丢到台上了。这个命令就是把台下的所有内容都丢到台上去。

这里需要说明一下台上的内容到底是什么，台上的内容就是，台上的文件与本分支当前的commit做对比产生的变化的内容。它并不是整个文件的内容，这里需要注意一下。

4. git commit  交付

就是把当前的stage中的内容打包成一个commit，存储到git仓库中去。也就是存放到 .git/objects目录下。我们现在执行   git commit  -m "本次提交的描述"  看看什么效果。

405db5ee78794cdeb5ce63161030dec9.png

使用git log 查看交付记录。这里我们看到成功创建了一个commitID为e94210ba5933b364d12f35b7841d1cbad3d963b8的commit。

f3dcd0cab98748f3906fad51651222a6.png

我们可以看到.git/objects/e9/4210ba5933b364d12f35b7841d1cbad3d963b8,这个文件也被创建出来了。

5. git branch 分支管理

git branch可以列出本地仓库的分支列表，我们执行一下看看有什么效果。

beec917de3064369a3e1a8211ddf3343.png

可以看到，我目前只有一个分支master。现在我们再创建一个dev分支，执行命令git branch dev

7e52388696644c3287a210fb61777176.png

可以看到我们的分支列表中多了一个dev分支，但是我们当前还是再master分支上。我们可以执行git checkout dev来切换到dev分支。

c5e60d073b634b708254bce49f8f992f.png

可以看到我们的分支已经切换了，并且当前分支head指针的内容也更新了。

然后我们再dev分支上把file1文件修改一下再次提交。

f6d4f6523c644172b9fc414743320cdc.png

我们可以看到master分支还指向e94210ba5933b364d12f35b7841d1cbad3d963b8这个commit上。dev已经指向新的commit了。

6.git push 推送

推送就是向远程仓库推送一些东西，都可以是什么东西呢？

1. 推送commit，这是我们最经常推送的东西，我们现在切换回master分支，然后执行git push

663b9db1b9d74f06b98a34dcfc44bb6f.png

这里我们实际上只把第一次提交的commit(e94210ba5933b364d12f35b7841d1cbad3d963b8)推送到了远程仓库了。

2. 推送分支，当我们想把本地分支推送到远程库上时使用的，下面我们来把dev分支推送到远程库里，执行 git push origin dev。这里的origin先不要管，下面会有讲解。

06534eed67b840f791f4e8e1426e250b.png

git branch -r 是查看远程仓库的分支列表，可以看到，我们推送分支之前，远程库只有一个分支，推送后有两个分支了。

上面那个origin是远程仓库的名字，使用git clone的仓库会默认把你克隆的远程库命名为origin。然而在git中，一个本地仓库是可以关联n多个远程库的，每一个远程库都是一个名字对应一个url。

使用 git remote -v  查看本地仓库关联的所有远程库

497d9dd909c34d1b94d8c91184c61005.png

使用 git remote add 远程库名字  url  可以关联一个远程库。

6850b410b5954fd9b89f0e1fe38703a4.png

当然，如果你想要往指定的远程库上推送东西的话，git push 后面就要加 远程库的名字了。

7.git merge 合并

我们对合并传统的理解是把两个分支合并到一起，但在git中，我们不能简单的这么去理解merge。上文中我们说过，在git里的一个commit就是一个完整的交付历史，甚至一个commit就可以代表一个分支。

那么在git中，merge的作用其实就是把两个commit的内容合并到一起（注意，在合并中，commit代表的是一段交付链）。现在我们假设有两个commit，A 和 B，我们当前分支指向的是commit A，我们要合并commit B。那么会产生两个情况。

第一种情况，commit B可以通过其父commit直接追溯到commit A，如下图

64d48c669cc84208ab6f258c8ca4730e.png

这种情况下的merge有两个选择，一选择是直接把当前分支的commitID更新为commitB，这就是merge的fast-forward模式。第二个选择是为这次merge创建一个新的commit。

第二种情况，commit B无法追溯到 commitA的情况，如下

a6f6dab2c5cc4ed883e41db2e514c94d.png

commitB的交付链条里无法找到 commit A，也就是无法追溯到当前分支的最新commit。但是他们两个继续往前追溯，一定只能找到一个共同的祖先的，如下

f287d8a51ab94c6a84f2af3891245900.png

这时merge的任务就是，把自这个共同祖先往上的两个交付链合并到一起，并为这次合并创建一个新的commit，这种情况下是无法进行fast-forward模式合并的。合并后的效果如下

cba904f7459240f497afff0815e85a2a.png

命令使用：git merge  分支名称 或者 commitID，

c0c89b85acb24f60a21877f728f59622.png

f4c5ad943924448bbb111b792fb4c127.png

8.git fetc  获取

从远程仓库获取更新，如果有的话，获取到的新内容不会应用到本地仓库上。

现在我们切换到一个新的目录里，重新克隆一下我们的远程仓库。然后我们修改file1，然后创建一个commit，并push到远程仓库，然后回到原先的本地仓库里执行git fetch看看是什么效果。

3107a04ddb4b48a293f506b38dbdc877.png

可以看到有内容被取下来了，但是我本地仓库的commit历史没有变化。现在我们执行一下git merge看看效果。

3e785de29e384e40bb419ebe2f78ff72.png

可以看到，我们本地的提交历史发生了变化。这里的merge并没有加任何参数，不加参数的merge实际上是默认的把fetch到的最新的commitID作为目标commit进行合并了，如果没有冲突的话，那就是一次fast-forward的合并，如果有冲突的话，解决冲突后会创建一个新的commit。

9.git pull 拉取

就是git fetch 加 git merge的组合。明白了上面的merge 和fetch，这个行为就没有什么好讲解的了。

三.git的多人协作

在一个项目中多人协作的基础是共享与交流。git通过分支管理、远程仓库操作、commit来支持这两个基础，然而原生的git对其支持也就仅限于此，对于一个小型团队也足够用了。然后对于大型团队的多人协作就有些力不从心了。大型团队意味着大型项目，它主要面临一下几个问题。

1.团队人员多

团队人员众多就意味着人员分散、沟通成本高、工作成果的管理成本高。

2.项目复杂

功能模块多，版本的迭代管理面困难。

3.文档管理

对于大型项目来讲，文档是非常重要的内容，他是这个项目能正常运作的重要基础。

4.交流

在大型项目中我们经常要对一些议题、功能模块进行讨论

 

所以在大型项目中我们还要求git至少具备人员管理、文档管理的支持。还要对人员交流、版本迭代有更强大的支持。原生的git还无法做到这一点，所以就有了github、gitcode、gitee、gitea、gitlab这些产品出现。下面我们会分别介绍Gitflow、Githubflow、Gitlabflow。

四.Gitflow  工作流

Gitflow 是一种流行的 Git 分支管理工作流程，由 Vincent Driessen 提出，专门为团队协作开发而设计，特别适合拥有较长开发周期的项目。它通过明确的分支策略，使开发、发布和维护的过程更加清晰和规范。

Gitflow 的核心概念

Gitflow 主要依赖以下几个分支来组织代码：

  1. 主分支（main）：

    • 存储的是已经发布到生产环境的稳定代码。
    • 每个版本的发布都在此分支打标签（tag）。

  2. 开发分支（develop）：

    • 用于开发的主分支，团队成员日常开发的代码最终都会合并到这个分支。
    • 此分支上的代码反映当前的最新开发状态。

  3. 功能分支（feature/*）：

    • 每个新功能都有一个独立的分支，从 develop 分支创建。
    • 功能开发完成后，合并回 develop 分支。
    • 命名通常以 feature/功能名称 命名。

  4. 发布分支（release/*）：

    • 从 develop 分支创建，用于准备即将发布的版本。
    • 可以在此分支上进行最后的测试、修复 bug、完善文档等。
    • 完成后合并到 main 和 develop，并打上版本标签。

  5. 热修复分支（hotfix/*）：

    • 用于修复生产环境中的紧急问题，从 main 分支创建。
    • 修复完成后，合并到 main 和 develop，并打上版本标签。

Gitflow 的工作流程

  1. 初始化仓库：

    • 主分支和开发分支初始化：main 和 develop。

  2. 开发新功能：

    • 从 develop 创建 feature/功能名称 分支。
    • 在 feature 分支上完成开发后，合并回 develop。

  3. 准备发布：

    • 当 develop 上的功能足够多并且稳定时，从 develop 创建 release 分支。
    • 在 release 分支上完成必要的修复和优化，最后合并到 main 和 develop。

  4. 生产环境问题修复：

    • 当 main 上的代码发现问题时，从 main 创建 hotfix 分支。
    • 修复完成后，合并到 main 和 develop。

Gitflow 的优点

  • 清晰的分支管理：每种任务都有明确的分支，减少了代码冲突的风险。
  • 支持并行开发：多个功能可以在各自的分支上独立开发。
  • 易于追踪版本历史：版本管理有条理，通过标签标记版本。

Gitflow 的缺点

  • 操作复杂：分支和合并的数量较多，增加了操作成本。
  • 不适合持续交付：如果需要频繁发布，Gitflow 可能显得繁琐。
  • 对小型项目过于重型：小型团队或短开发周期可能不需要如此复杂的分支策略。

适用场景

Gitflow 非常适合如下场景：

  • 团队开发的大型软件项目。
  • 具有固定的发布周期。
  • 需要严格版本控制的项目。

五.Github Flow  github工作流

GitHub Flow 是一种简单、轻量的工作流，旨在帮助开发团队高效地协作和发布高质量的软件。它特别适用于持续部署和发布的项目，以下是 GitHub Flow 的关键步骤和特点：

核心步骤

  1. 创建分支（Branching）

    • 每个新功能、修复或改进都从主分支（main 或 master）创建一个新的分支。
    • 分支命名通常清晰描述工作内容，例如 feature/user-authentication 或 fix/login-bug。

  2. 提交更改（Committing Changes）

    • 在分支上开发时，将小而独立的更改提交到分支。
    • 提交信息应简洁且有意义，便于追踪。

  3. 创建拉取请求（Pull Request, PR）

    • 当工作完成后，提交代码并在 GitHub 上发起一个拉取请求。
    • 拉取请求描述应包含代码更改的背景、目的以及测试细节。

  4. 代码审查（Code Review）

    • 团队成员可以在拉取请求中提供反馈，确保代码质量和一致性。
    • 如果需要，可以多次更新分支来响应反馈。

  5. 合并分支（Merging）

    • 拉取请求通过审查并经过自动化测试后，可以将分支合并回主分支。
    • 在合并前，通常会运行所有必要的 CI/CD 测试。

  6. 部署（Deploying）

    • 每次合并到主分支后，代码应该是可以部署到生产环境的。
    • GitHub Flow 鼓励频繁的小规模部署，以减少风险。

关键原则

  • 保持主分支稳定： 主分支始终是可部署的，因此任何工作都应在分支上完成。
  • 频繁部署： GitHub Flow 的设计支持持续集成和持续部署（CI/CD）。
  • 小而快速的迭代： 小的、更频繁的更改降低了回滚的风险并提高了团队效率。

六.GitLab Flow  gitlab工作流

GitLab Flow 是一种灵活的工作流模型，结合了 GitHub Flow 和 Git Flow 的优点，适合复杂的开发场景，例如包含多环境部署的项目。GitLab Flow 更加强调环境管理（如开发、测试、生产）和持续集成/持续部署（CI/CD）的最佳实践。

以下是 GitLab Flow 的核心内容和工作步骤：

核心概念

  1. 环境驱动开发：
    支持多环境（如开发、测试、生产），代码通过分支或标签逐步推进到不同的环境。

  2. 简单分支模型：
    避免复杂的分支设计，通常使用少量分支，比如 main（或 master）、feature 分支、release 分支和 production 分支。

  3. 持续集成和部署（CI/CD）：
    每次代码提交后触发自动化测试和部署，确保高效交付和生产环境稳定。

  4. 合并请求（Merge Request）：
    所有更改都通过合并请求进行协作和代码审查，确保代码质量。

  5. 基于需求的分支策略：
    根据项目需求选择不同的分支模型，例如：

    • 单环境项目：简单分支策略。
    • 多环境项目：分支对应环境。

核心步骤

  1. 创建分支：
    根据工作任务，从主分支（main 或 master）创建一个新的分支。常见分支类型包括：

    • Feature 分支： 用于开发新功能，命名如 feature/add-authentication。
    • Bugfix 分支： 用于修复问题，命名如 bugfix/fix-login-error。

  2. 开发和提交更改：
    在分支上完成开发，每次提交（commit）都应与单一变更对应，确保改动清晰可追踪。

  3. 发起合并请求（Merge Request）：
    当分支开发完成后，发起合并请求将分支合并到目标分支（如 main 或 develop），在请求中描述改动内容和测试方法。

  4. 代码审查和测试：
    团队成员审查代码并运行 CI 测试，确保代码符合质量标准并不会破坏现有功能。

  5. 合并到主分支：
    通过审查后，分支合并到主分支或目标分支。

    • 对于多环境项目，可将代码从 main 分支逐步合并到 staging 和 production 分支。

  6. 部署：

    • 单环境项目： 合并到主分支后直接部署到生产环境。
    • 多环境项目： 使用 CI/CD 管道部署到不同环境（如 staging 测试，production 发布）。

分支模型类型

  1. 简单分支模型（适合单环境项目）：

    • 主分支（main 或 master）：生产环境代码。
    • 功能分支（feature）：用于开发。

  2. 多环境分支模型（适合复杂项目）：

    • Main 分支： 稳定代码，用于最终发布。
    • Production 分支： 与生产环境同步。
    • Staging 分支： 用于测试环境。
    • Feature/Bugfix 分支： 用于开发。

  3. 版本发布模型：

    • 使用 release-x.y.z 分支管理版本发布。
    • 通过标签（Tag）标记版本号。

本文完结。欢迎点赞受收藏留言讨论。

 


原文地址：https://blog.csdn.net/yjy000/article/details/144249129

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

相关文章

自学内容网
Copyright © 2015-2024