Git的基本操作以及原理介绍

如何解决冲突？手动解决，在master分支中的冲突文件中保留想要的代码。解决冲突后执行add和commit，此时合并操作才算完成

查看当前日志

使用以下命令，可以以图表的形式看到master分支与dev分支之间的关系

git log --graph --abbrev-commit
1

分支的合并模式

如果执行命令

git merge 分支名
1

调试信息中有"fast-forward"字段时，说明这次的提交为ff模式
该模式的合并无法通过git log --graph --abbrev-commit查看，图中不会出现两个分支合并成一个分支的信息，因此我们无法得知master合并了哪个分支

ff模式的本质是将被合并分支的最近一次提交对象指针写入到master分支的最近一次提交对象指针中

当合并没有发生冲突时，git默认使用ff模式
此外，还有一种模式： no-ff，这种模式的合并可以通过git log --graph --abbrev-commit知道两哪个分支发生了合并
使用no-ff模式的合并：

git merge -no-ff -m "此次合并的目的" 被合并的分支名
1

由于合并完分支后，还需要进行commit操作，所以需要-m提交信息

分支策略

master主分支对应着线上环境，必须是十分稳定的，所以提交的代码需要能稳定运行，没有重大的bug
而其他分支则是不稳定，存在bug的。开发人员在这些分支上进行开发，进行一系列测试验证后，就能将其他分支上的代码合并到master分支中
基于分支，我们就能进行同一项目的多人同时开发，同时也演变出了多种分支策略

git stash

如果在其他分支中修改了文件，未进行add和commit，此时的操作将不受到git的版本控制，只是单纯的对工作区的修改。切回master分支后，可以在本地看见其他分支对文件的修改

若其他分支修改文件后，进行了add和commit，此时的操作将受到git的版本控制。切回master分支后，无法看见其他分支对文件的修改

如果不进行add和commit，又不想让master分支看见其他分支对文件的修改，可以使用命令

git stash
1

该命令将保存分支对文件的修改到一个特殊文件中，也就是将修改后的文件添加到git的版本控制中，此时master分支无法看见其他分支对于文件的修改

此时.git的目录树中，多了一个stash文件，用来保存分支中的修改

执行命令，打印stash中保存的修改

git stash list
1

如果在dev分支中修改了文件，并执行git stash，切出该分支，再切回dev分支
此时分支中的数据和master分支相同，要想恢复之前所做的修改，就需要执行命令，将stash中的修改恢复到分支中

git stash pop
1

不要在master分支上解决冲突

项目上线后可能遇到的场景：存在一个小bug，此时基于master分支创建分支fix_bug进行bug修复，修复成功后在master分支中合并fix_bug分支，项目再次上线
同时，项目的开发也在不断进行中，在发现bug之前，创建了一个分支dev开发新的功能。等到功能开发好时，项目已经不再是当时创建分支时的项目，而是修改了bug后的项目。此时在master分支中合并dev分支将产生冲突

我们不能直接合并dev分支，并在master分支上手动修改文件，这可能导致使修改后的文件出现bug
正确做法应该是：在dev分支上合并master分支并且手动修改冲突，测试没有问题后，再到master分支中合并dev分支

git的远程操作

git的全程叫做分布式版本控制系统，版本控制很好理解，如何理解分布式？

一个项目的开发往往需要多人的分工协作，之前所说的git仓库：工作区、暂存区以及版本库都是在本地运行的。一个开发人员对项目进行了修改，另一个开发人员要如何获取到他的修改呢？或者说如何让其他人看到我对项目的修改？

显然只使用本地的git无法解决这个问题。git为我们提供了一个解决方案，使用中央服务器存储git仓库，我们也叫它远程仓库

每个开发人员都能访问到远程仓库，需要开发项目时，从远端仓库将整个仓库拉取下来进行开发。开发完成后，将本地的修改提交到远程仓库中。那么其他开发人员就能通过远程仓库看到你对项目的开发，并且也能拉取你对项目的修改，进一步进行开发

用https克隆远程仓库，注意：不能在拥有.git目录的路径下（已经初始化过本地仓库的地方）克隆仓库！
克隆也能理解为第一次拉取

在远程仓库中可以找到该仓库的链接，通常有https和ssh协议，先演示https协议的克隆，将URL复制下来，执行命令

git clone URL
1

查看远程仓库的信息

git remote [-v]
1

直接使用git remote将打印本地仓库中已经配置的远程仓库名字，通常是origin

而git remote -v将查看已经配置的远程仓库列表，以及它们的URL。fetch表示本地拥有远程仓库的拉取权限，push则表示提交权限

用ssh克隆远程仓库：
需要先将本地服务器的公钥放到远端的git服务器中

如何配置git服务器的公钥？
找到个人设置中的相关配置项

点击添加公钥：

在本地服务器中生成公钥与私钥：
进入/~/.ssh目录，如果没有则创建目录
如果目录中没有id_rsa 和id_rsa.pub文件，则执行以下命令

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
1

其中-C选项表示添加注释信息，用来表示生成的密钥对的用途，将这个信息设置为自己的邮箱即可
输入命令后一直回车直到能够输入其他命令为止

此时目录下新增两个文件：id_rsa 和id_rsa.pub

生成后，将公钥（id_rsa.pub中的字符）写入git服务器中

此时执行命令，即可克隆仓库

git clone ssh链接
1

将修改提交到远程仓库

注意：不是将整个本地仓库的修改提交到远程仓库，而是将某个分支的修改提交到远程仓库
克隆完远程仓库后，需要配置user.name和user.email，这两个信息要和git服务器中的信息一致

首先在工作区中修改文件，并add与commit，最后执行push，将版本库中的修改提交到远程仓库

git push 仓库名 本地仓库的分支:远程仓库的分支
1

push其实做了两步操作：将本地仓库某个分支的修改提交到远程仓库中，将指定分支与远端分支进行合并

其中，仓库名是本地服务器配置的远程仓库的名字，一般是origin
同时指定要push哪个本地分支中的修改到远程仓库中的哪个分支，这两个分支名一般用:隔开，当两者相同时，可以只写一次分支名（github的master分支现在叫做main分支）

此时远程仓库中出现了分支的修改，新增了ReadMe文件

push操作的本质是本地分支与远端分支的交互，交互之前需要先建立连接。一般在克隆仓库时，本地仓库的master分支与远程仓库的master分支就自动建立了连接，可以直接使用git push。而其他分支没有建立连接，需要使用上面的长命令进行push操作

当本地仓库的版本领先于远程仓库的版本，此时进行push操作以推送更新
当远程仓库的版本领先于本地仓库的版本，此时要进行pull操作以同步与远程仓库的版本

假设远程仓库的hello.txt被其他人修改了并且push了，这是修改后的内容

此时我要进行下一步的开发，就必须与远程仓库的版本保持同步
使用pull命令完成同步

git pull 仓库名 本地仓库的分支:远程仓库的分支
1

pull和push的使用相同，pull其实也进行了两步操作：将远程仓库中指定分支的修改拉取到本地，与本地分支进行合并

push时忽略特殊文件

创建远程仓库中，可以勾选添加.gitignore文件的选项：指定一些不想被push的文件，这些文件的修改就不会被add到暂存区中，更不会被push到远程仓库中了
在.gitignore文件中的文件不会被git追踪管理，即忽略这些文件，.gitignore文件需要位于git工作区的根目录下

若新建仓库时没有勾选添加.gitignore文件的选项，后续想要添加该文件时，可以直接添加

该文件在工作区的根目录下

此时创建一个以so结尾的文件，并将当前目录下的所有文件add到工作区中，执行git status命令，查看哪些文件的修改需要被commit到版本库中

发现调试信息中，没有a.so文件只有.gitignore文件，说明.gitignore文件生效了

如何强制添加文件到暂存区中，就算该文件在.gitignore中出现？
为add添加-f选项，强制提交修改到暂存区中

git add -f filename
1

也可以在.gitignore文件中添加规则，使git不要不略某个文件的提交

!表示不忽略该文件的提交

如何判定某一文件是否被忽略？

git check-ignore -v filename
1

打印信息说，该文件被第三行的规则忽略了

配置命令的别名

git config --global alias.别名 '原名（不需要加git）'
1

给status起别名

git的标签管理

使用标签可以方便的查看信息，以及记录一些有意义的信息
执行命令，为最近的一次commit将被打上指定的标签

git tag 标签名
1

查看所有标签

git tag
1

.git的目录树中也出现了相应的目录，查看该文件

发现该文件存储了最近一次的commit id

为指定的commit打标签，先通过git log --pretty=oneline --abbrev-commit，列出所有commit id，找到想要打标签的commit id

执行

git tag 标签名 commitid 
1

执行命令，为commit打标签并添加注释：

git tag -a 标签名 -m "注释内容" commit id
1

执行命令，查看标签的注释：

git show 标签名
1

git show将显示对应commit的详细信息，如果该commit的标签有注释，那么也将一起展示，如果没有则只显示其他信息

删除标签：

git tag -d 标签名
1

推送标签

git push 仓库名 标签名
1

推送所有标签：

git push 仓库名 --tags
1

删除远端仓库的标签（首先要先删除本地仓库的标签）

git push 仓库名 :标签名
1

git实战

同一分支下的多人协作（不推荐）

开发者1在dev分支下的hello.txt文件中添加"111"，开发者2在dev分支下的test文件中添加"222"

先在远端仓库中添加新的分支

接着在两个开发者的机器上执行git pull，获取最新的仓库版本（新的分支）
但是执行git branch后，无法看到新的分支。这是因为远端的分支与本地的分支没有关系，所以就算拉取了，也不会执行分支合并的操作。使用git branch -r选项就能看到远端的分支

此时我们要在本地手动创建名字相同的分支，并将本地分支与远端分支建立连接
执行命令建立连接

git checkout -b 本地分支名 仓库名/远端分支名
1

除此之外，使用其他命令也能达到同样效果（前提是dev分支不存在）

git branch 本地分支名 仓库名/远端分支名v
git checkout 本地分支名
1
2

若dev分支存在，则执行

git branch --set-upstream-to=仓库名/远端分支名 本地分支名
git checkout 本地分支名
1
2

执行git branch -vv可以查看本地仓库与远端仓库的连接
为什么要建立连接？这样可以直接使用git push与git pull这样的短命令，而不使用git push origin main这样的长命令

开发者1完成操作，修改文件后add、commit、push三板斧

开发者2执行相同的操作

而开发者2修改完hello.txt却无法提交，原因是此时的远端仓库中hello.txt和开发者2本地仓库最近一次pull的版本不同（开发者1的提交导致版本的不同），此时提交将产生冲突
解决方法是：执行git pull，此时hello.txt文件产生冲突，手动修改冲突并重新add、commit、push即可

最后一步：将dev分支合并到master分支中
有两种方法：

1. 将本地的dev分支合并到master分支中，再将master分支push到远端
2. 在git服务器上提交pr（pull request）申请，由管理员审批后，合并将被执行

如何提交pr申请？

选择选项，将dev分支合并到main分支中，添加标题和内容后选择reviewers和addignees，点击新建pr
关于reviewers和addignees的区别，可以看这篇博客Git GitHub上的Reviewers和Assignees之间有什么区别|极客笔记 (deepinout.com)
相关人员审查没问题后，就会进行合并操作了

另一种方法是在本地执行merge操作，推荐使用pr合并方式，经过审查员的审查，合并操作会更加安全

首先，执行合并操作的开发人员的本地仓库中，dev分支可能不是最新，此时需要先pull拉取最新版本

git checkout dev
git pull
1
2

由于无法保证main分支也是最新的，所以也需要pull

git checkout main
git pull
1
2

由于无法保证将dev分支合并到main分支是否会发生冲突，所以先到dev分支下，将main分支合并到dev分支。若发生冲突则手动解决冲突

git checkout dev
git merge main
1
2

解决完冲突后，再回到main分支下，合并dev分支

git checkout main
git merge dev
1
2

最后进行push操作即可

git push
1

删除dev分支（可选）

git branch -d dev
1

可以看到同一分支下的多人协作非常麻烦，产生冲突的概率极大，需要不停的pull解决冲突
所以开发中的多人协作一般是在不同分支下进行的

不同分支下的多人协作

每个开发者（开发项目的不同功能）对应不同分支，在属于自己的分支上提交自己开发的代码
最后这些代码将合并到main分支下
如：开发者1在feature-1分支下提交file1文件，开发者2在feature-2分支下提交file2文件
开发者1：首先pull更新本地的master分支，然后在本地master分支下，创建feature-1分支，编辑文件file1并进行add和commit操作

git pull
git checkout -b feature-1
1
2

此时的push操作比较特殊，不能直接git push，而要执行

git push 远端仓库名 本地分支名
1

因为此时的远端仓库中没有feature-1分支，我们只是在本地创建了feature-1分支，所以这次的提交需要将整个分支进行提交
总结下：可以在本地创建新分支，也可以在远端创建新分支

1. 在本地创建新分支后，需要将整个分支进行提交
2. 而在远端创建新分支后，需要先pull获取远端的分支，再创建本地的同名分支并建立连接
   
   此时远程仓库下已经存在feature-1分支了
   

开发者2执行与开发者1相同的操作：基于master分支创建新的分支feature-2，在该分支上编写文件file2，并执行add、commit以及push操作，在执行push操作之前需要先pull获取最新的远程仓库

开发过程中可能遇到的场景：开发者1需要帮助开发者2完成后续开发
此时开发者1的本地仓库中没有featrue-2分支，所以需要将该分支拉取下来

解释一下这时的pull为什么只需要使用短链接？
pull操作其实有两种：1. 拉取某一分支下的内容，此时需要使用长连接，如果本地分支与远端分支建立连接后即可使用短连接 2. 拉取仓库中的内容，如新的分支，此时使用短连接即可，但是拉取到的新分支不会和本地分支建立连接

但是拉取操作只是将远端的分支拉取下来，本地没有相应的分支，打印的信息提示我们要在本地创建相同的分支并与其链接

git checkout -b feature-2 origin/feature-2
1

此时处于feature-2分支下，继续编写该分支下的文件，完成开发者2未完成的代码

最后：将feature-1分支和feature-2分支合并到main分支下
在git服务端分别提交两次pr申请即可
在提交pr申请前，推荐先用其他分支合并main分支，解决可能存在的冲突，再用main分支合并其他分支，此时将不会产生冲突

为什么本地依然能看到远端已经删除的分支？

将远端分支删除后，本地使用git branch -a依然能看到远端分支，如何解决？

使用命令清理远端无用分支即可

git remote prune origin
1

此时远端分支只有main分支，剩下的本地分支用git branch -d删除即可

git flow模型

git flow模型是企业级常用的一种git分支设置规范，这只是一种常用的开发模型，并不适合于所有的开发团队。了解它有助于我们理解软件开发的流程

• master为主分支，该分支唯一且只读，用于部署正式发布环境，一般由合并release分支得到
• master分支为稳定的代码库，任何时候都不能直接在master分支上修改代码
• 产品的功能全部实现后，最终在master分支上对外发布。并且master分支上的所有提交都应该打标签（tag）做记录，方便追溯
• master分支不可删除

feature分支

• feature为新功能或新特性的开发分支，以develop分支为基础创建feature分支
• 命名通常为feature/user_createtime_feature，表示开发人员，开发时间以及所开发的特性
• 新特性开发完成后需要将feature分支合并到develop分支中，且删除feature分支

develop分支

• develop为开发分支，基于master分支创建的唯一且只读分支，始终保持最新完成以及bug修复后的代码。可部署到对应开发集群
• 通常用来合并feature分支，也可直接在develop分支上开发

release分支

• release分支为预发布分支，基于develop分支创建，可以部署到测试或者预发布集群
• 通常的命名规则：release/version_publishtime，表示发布的版本以及发布时间
• release分支通常用于提交给测试人员进行测试，若出现问题则需要验证develop是否出现问题，测试完成后可以删除release分支

hotfix分支

• hotfix为bug修复分支或补丁分支，主要用于线上版本的bug修复
• 命名规则通常为hotfix/user_createtime_hotfix，表示相关人员，创建时间以及具体的bug
• 问题修复完成，将其合并到master分支后删除