Git基本使用

文章目录

Git基础概念

1. 什么是git：目前最主流的版本控制器，可以控制我们电脑上所有格式的文件，即可以维护所有文件的版本。 - 什么是版本控制器：能让我们了解到所有文件的修改历史，记录了每次的修改以及版本迭代的一个管理系统- 对使用场景的理解： - 无法版本管理：反复修改同一个文件，只拥有最新版本的内容，无法知道和使用之前版本的内容(无法进行版本管理)- 可以版本管理：复制上个版本的文件，在新文件的基础上修改成新版本，每个版本都有一份，能对版本进行管理
2. git对于开发人员的意义：帮我们管理开发项目中的源代码文件
3. git如何管理文件： - 文本文件：可以记录出【每次修改的内容是什么】。如我们在第二行新写了一些文本内容，Git里就会记录“第二行新增xxx”- 二进制文件：图片、视频等都是二进制文件，对于二进制来说，Git是无法跟进文件的具体变化的。它只能把每次该的内容串起来，比如说，图片从100kb变成了200kb，但是具体内容上修改了什么并不知道

安装Git

.Git基本操作

创建本地仓库.git

1. 为什么要创建本地仓库：只有在Git的仓库里的文件，才能被Git追踪和管理
2. 哪个是仓库：创建出来的【.git】目录，仓库又可以被称为【版本库】
3. 如何创建：

配置本地仓库

1. 为什么要配置：当我们成功创建了一个本地仓库后，需要为仓库新增【用户的名称】和【用户的email地址】这两个配置项。如果没有配置，可能会影响我们对本地仓库的操作。
2. 如何去配置：

认识工作区、暂存区、版本库

1. 工作区：是我们在电脑/服务器上，放代码/文件的一个目录。此处是【gitcode目录】
2. 版本库：也就是仓库。此处是【.git目录】
3. 暂存区：暂时存放git对象索引的区域

添加文件

1. 如何让git帮我们管理工作区的文件：
2. Git是如何实现版本控制的：
3. git文件： - git add .：这个点表示把当前目录的工作区上所有的修改全都加到暂存区上
4. git后本地仓库发生的变化：

打印git的日志

修改文件

1. Git追踪管理的到底是什么：是修改的内容(新增，修改，删除)，而不是文件。修改的内容会写入objects中一个新的Git对象。
2. 查看修改的情况： - 查看仓库的状态：git status- 查看某个文件内容的差异：git differ 文件名(暂存区VS工作区) 或 git differ HEAD 文件名(版本库VS工作区)
3. 添加修改后的文件：此时ReadMe文件已经被修改了

版本回退

1. 使用场景：回退某个版本，如把 v5版本 回退到 v1版本
2. 回退版本：git reset [–soft | --mixed | --hard] [HEAD] - soft：只回退版本库里的内容- mixed：回退版本库 + 暂存区 - 当不带任何选项时，默认用mixed- hard：回退所有 - 慎用，因为如果此时其他人在工作区开发，那么正在写的东西也会被回退，就无了

1. 恢复被删掉的版本
2. 为什么版本回退执行的速度很快：因为只是更改了master里的值

撤销修改

1. 撤销场景：在工作区开发后，觉得开发的内容不好，想要撤销修改回到最初的版本，重新写
2. 分为三种情况：- 情况一：没有add：只撤销工作区内容- 情况二：add了：撤销工作区 + 暂存区内容- 情况三：add + commit了：撤销工作区 + 暂存区 + 版本库内容
3. 情况一：没有add的解决方式：
4. 情况二：已经add了：
5. 情况三：add + commit的情况：git reset --hard HEAD^

删除文件

1. **删除工作区的文件(文件没有add过)**：使用rm
2. **将工作区的变动提交至暂存区(文件add过)**：
3. **将暂存区的变动提交至版本库(文件add+commit过)**：在【2】的基础上，把删除的文件commit一下

Git分支管理

什么是分支

1. 分支的作用：当出现一个需求/任务时，创建一个分支，由分支去完成，等完成后把分支合并到master主分支上
2. master分支：里面存的是最新一次提交的commit的id
3. 关于HEAD：HEAD可以指向分支，被HEAD指向的分支，是我们当前的工作的分支(决定了commit操作会被提交到那个分支上)

分支的使用

1. 查看当前仓库中，有哪些本地分支：git branch- * master：星号表示当前在那个分支上工作
2. 创建分支：git branch dev
3. 切换分支：
4. 创建并切换分支：
5. 合并分支：
6. 删除分支- 场景：把dev分支上的内容合并到master主分支后，该分支的使命就结束了，此时就可以删除该分支了- 删除方法：在其他分支下，使用git branch -d 命令
7. 强制删除分支

合并冲突

1. 是什么冲突：当dev分支和master分支都修改了某个文件，此时如果执行合并操作，Git不知道要保留哪个故而会产生冲突。此时需要我们人为手工决定要保留哪个版本
2. 处理方法：

以图示的方式打印日志

合并模式

分支管理要遵循的基本原则

bug分支

1. 为什么会出现 bug 分支：虽然我们说master上的分支是稳定的，但有时候也会遇到出错的情况，此时是因为测试人员没有测出全部的bug。但又因为【master分支是稳定的原则】，我们不能直接在 master分支上直接修改，所以要专门创建一个分支来解决bug
2. 情况一：分支上还没完成开发，就发现master上面有bug：开发一个新分支解决bug - 处理dev分支上的修改影响到工作区的问题：- 处理master分支上的bug：新建bug分支+修改后合并- 重新进行分支上的开发：- 重新开发后，关于冲突问题的处理：

Git 远程操作

理解分布式版本控制系统

1. 版本控制系统：Git能够帮助我们追踪管理文件的版本
2. 分布式：Git给我们提供了一个中央服务器，并且保持24小时开机(可以确保始终可以推送自己的修改) - 所有要进行的多人协作，都是在和这台服务器打交道：每个人都可以克隆一份中央服务器的仓库到自己的服务器上。而我们在本地仓库修改后，可以把修改的内容再推送到中央服务器上，如果其他人想看到这个修改，从中央服务器中拉取即可
3. 关于gittee和github：我们可以自己搭建Git服务器，然后在该服务器上创建仓库，又因为该仓库不是在本地上存在，所以叫做中央服务器仓库/远程仓库。但手动建服务器较麻烦，我们可以通过github/gitee网站，免费获取Git远程仓库

创建远程仓库

1. 创建仓库时的设置： - 仓库名称：一般来说，一个仓库对应的是一个项目系统，项目系统的名字对应的就是仓库的名字- 仓库介绍：这个仓库是用来干什么的- 仓库地址：我们可以使用该链接来访问到这个远程仓库- 设置语言：该仓库主要是什么语言的代码- 设置模版： - Readme文件：我们创建好这个仓库之后会自动生成一个Readme文件，别人一进来首先会看到这个文件。这个文件主要写了该仓库的详细介绍- Issue 模板文件 和 Pull Request 模板文件：
2. 当前仓库上文件的介绍：
3. 关于Issues：让发现bug的用户和当前该仓库的成员交流的一个地方 - 我们可以根据选择的模板文件进行问题的编写
4. Pull Requests：我们并不在master分支上开发，是在其他分支上开发的，在分支上开发完后，我们需要有一个把分支合并到master上的操作的。但这个操作十分危险，因为当前分支上我们开发的代码可能会有bug，不确定是否会影响到master分支上代码的运行。故实际开发中，我们是不能直接merge的，开发人员要写一个PR，即合并申请单，管理员同意后，再merge。
5. 设置成员：在【管理】里可以设置成员（报告者、观察者、开发者、管理员）

克隆远程仓库

1. 关于下载的方式
2. 使用HTTPS克隆
3. 使用SSH克隆

向远程仓库推送

拉取远程仓库

1. 场景： - 使用pull的场景：当另一个服务器也克隆了远程仓库，并且推送了修改的内容。此时本地仓库如果想要看到远程仓库中最新的一个代码，此时就要进行一个pull(拉取)操作- 关于在Gittee上直接编辑：实际开发中，我们不建议在Gittee上直接编辑
2. 拉取方法（指定了目标仓库和分支）：
3. 对于直接用git pull/push简写的理解：简写需要建立连接，如果是指定目标仓库和分支是不需要去建立连接的

忽略特殊文件

1. 场景：如果我们有些文件不想或者不应该提交到远端仓库，此时就需要把要把忽略的文件名填到【.gitignore】里，此时，Git就会自动忽略这些文件，不帮我们去追踪管理了
2. .gitignore：Git给我们提供的配置文件，创建仓库时可以勾选创建【.gitignore模版】
3. 编写.gitignore文件：
4. 如果.gitignore文件已经表示忽略.so结尾的文件，但我们又想专门去提交某个.so文件怎么办：
5. 查看文件被忽略的原因：check-ignore -v [文件名] - 如 check-ignore -v d.so：查看 d.so文件 被忽略的原因

配置命令别名

1. 场景：一个命令太长，专门配置了一个别名来表示这个长命令。注意，尽管取了别名，原命令依旧是可以用的。
2. 使用方法：git config [–global] alias.[别名] [命令] - git config --global alias.st status：在全局范围内，把status取别名为st - alias：别名- st：取成 st- status：给 status取别名- 注意，此时status也是能用的- git config --global alias.lpa ‘log --pretty=oneline --abbrey-commit’：把【log --pretty=oneline --abbrey-commit】取别名为【lpa】

操作标签

1. 什么是标签：给一个重要的提交打了一个标签，直接查标签就可以查到对应的commit的id，这可以帮助我们更容易记住 commit id，当我们需要回退到某个重要版本时，直接使用标签就能很快定位。 - 比如，在项目发布某个版本的时候，针对最后一次 commit 起一个【v1.0】这样的标签来标识里程碑的意义
2. 对于标签的操作：

推送标签

示例 – 多人协作

示例1 ：同一分支下进行多人协作

1. 目标：远程master分支下file.txt文件新增aaa(由开发者1新增)，bbb(由开发者2新增)- 注意，要求在一个分支下协作完成
2. 步骤说明：同一分支下进行多人协作其实是不常见的，因为修改冲突十分麻烦。一般多人协作是在不同分支下去操作的- 首先，可以用git push试图推送自己的修改 - 如果推送失败，是因为远程分支比你本地的分支更新，我们需要先用git pull合并一下- 如果合并有冲突，则解决冲突，并在本地提交。如果没有冲突或者解决冲突后，在用git push推送，此时能够推送成功- 最后，功能开发完毕后，将分支合并进master分支，最后删除分支
3. 创建一个新的分支：- 方法一：在远程创建分支，推荐。因为可以保证基于master创建的这个新分支是最新的 - 后续需要本地上创建一个分支，如果需要简写操作，需要在这两个分支之间建立联系（可在checkout的时候关联/使用–set）- 方法二：master分支先pull(保证本地master分支是最新的)，然后本地创建分支 + push
4. 克隆远程仓库：
5. 修改对应文件，add + commit + push，此时push是到了远程仓库的dev分支(如果还在本地的dev分支上的话)
6. 如果出现冲突，需要拉取并手动修改冲突：
7. 进行合并操作- 方法一：本地合并后，再推送- 本地的合并，推荐先让dev去合并master，再让master去合并dev，这样可以让冲突在dev分支下去解决，保证master分支的稳定性- 方法二：在远程仓库上操作，使用Pull Request(合并申请单)，由管理员决定是否要合并- 合并的步骤，也是推荐上面的，先dev，再master，保障master分支的稳定性
8. 删除dev分支：- 方法一：本地删除，然后push- 方法二：在gittee上面删除

示例2 ：不同分支下进行多人协作

1. 目标：远程仓库master分支分别新增2个文件，要求在不同分支下协作完成，- 我们一般让某一个功能私有一个分支
2. 实现：创建分支+推送修改
3. 如何帮别人开发：此时本地没有对应分支，但远程仓库有
4. 合并分支：将用户1开发的 function1 分支和用户2开发的 function2 分支都合并到 master分支 上- 使用Pull Request将function2分支合并起来- 本地合并分支，再推送

企业级开发模型

1. 企业开发流程：

1. 系统开发环境：
2. Git分支设计模型： - 为什么会有分支模型：环境有了概念后，针对不同的人员、工作性质，我们需要不同的分支，这些分支组合起来就是【分支模型】 - 线上环境：要求部署的是稳定的代码，而master也要求是个稳定的分支- 开发人员：对于开发人员来说，代码管理十分重要，我们需要一个能记录所有开发人员提交的分支，有迹可查- 测试人员：需要能把对应的功能专门给过来测试的分支- 常用的Git分支设计规范：Git Flow模型 - master分支：主分支，用于生产环境 - 唯一的，稳定不适合修改，一般由合并releases分支得到- release分支：预发布分支，用于预发布/测试环境，给测试人员使用 - 要基于develop分支去创建才能提供给测试人员去使用，要保证最新最全的分支- 命名以release/开头，建议的命名规则是【release/version_publishtime】- develop分支：开发分支，用于开发环境，记录了开发人员所有的提交 - 基于master分支创建的，始终保持最新完成已经bug修复后的代码。一般由feature分支合并得到，不建议在上面直接开发- feature分支：需求开发分支，用于本地，通常为新功能或新特性开发分支 - 以develop分支为基础创建，开发完后需要合并到develop分支上- 命名以feature/开头，建议的命名规则是【feature/user_createtime_feature】- hotfix分支：紧急修复分支，用于本地，master分支上出现了bug，需要我们尽快修复 - 基于master分支创建，修复完成后，需要合并到master分支和develop并推送远程- 命名以hotfix/开头，建议的命名规则是【hotfix/user_createtime_hotfix】