Git：原理浅析+工作流程+回退版本

csdn18117928061

已于 2023-12-14 10:52:05 修改

阅读量265

点赞数 1

分类专栏： gitee 文章标签： git github

于 2023-03-06 10:03:51 首次发布

本文链接：https://blog.csdn.net/csdn18117928061/article/details/127063097

版权

gitee 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、工作原理图

1、git pull

2、git push -u origin master

3.新建仓库合并项目仓库出现版本不复合（git log与远程仓库的log不一致）

一、工作原理图

1、git pull

= git fetch + git merge

        其实L本地分支和R远程分支从技术实现上根本没有任何交集，
        它们之间的关联全是通过T参照分支这个桥梁实现的。
        在L本地分支上执行了git fetch命令后，Git会把R远程分支上的改动下载到本地更新到T参照分支分支上，如果此后不执行git merge的话，那么你的feature(L)和feature(T)就会存在差异，只有执行了git merge命令后才会把feature(T)中的内容合并到feature(L)中。
fetch负责将R远程分支同步到T参照分支
        merge负责将T参照分支合并到L本地分支
pull就实现了直接R远程分支和并到L本地分支

通过git branch -a查看T参照分支与L本地分支

（红色的就是参考分支，绿色的是本地分支）

通过git remote -v查看R远程分支

2、git push -u origin master

= （git branch --set-upstream-to origin/master master） + （git push origin master）

上面命令将本地的master分支推送到origin主机，同时指定origin为默认主机，后面就可以不加任何参数使用git push了

二、简单使用

1.简单配置流程

1.设置用户名与密码与取消警告

git config --global user.name

git config --global user.email

2.设置账密的有效时间（可以不设置）

local（仓库级别）<gloal（用户级别）<system（系统级别）

3.设置分支模式（可以不设置，默认就是simple模式）

git config --global pull.default simple

simple模式：说白了就是从哪里来到哪里去。

        如果我的本地分支branchA是从origin端的branchA分支上pull下来的，那么在simple模式下，以后我再站在branchA这个本地分支上执行git push命令时，Git就会自动把我本地branchA上更新的内容推到origin端的branchA分支上去。

        现在就不难推断，为什么有时候，我们什么都没设置，上来就用git push就能够达到目的而没有被老大骂？因为你的Git版本的默认push.default是simple模式，而且在你来入职的时候，公司远程服务器上已经为你准备好了属于你的分支branchA，而当你把公司远程库给clone下来的时候，因为simple的模式设置，当你切(checkout)到你本地的branchA分支时，Git就已经知道你本地的这个branchA分支来自何方，而且它也知道该把你的数据推向何方了。这样就会导致很多用户上来就可以无脑地使用git pull和git push了。

matching模式：可能就是通过分支名称进行匹配。

        如果你的远程分支上有两个分支：branch1和branch2。你的本地分支上有三个分支branch1和branch2和branch3。那么再matching模式下，不管你站在哪个分支上执行git push时，Git都会寻找本地与远程分支名称相同的分支并且全部进行推送数据。不建议大家使用。

4.初始化仓库

git init

5、取消CRLF转化LF警告

git config core.autocrlf false

2.常用工作流程使用命令

先创建一个文件夹，然后git init

1.配置远程仓库（添加、查看、更换、删除）

git remote add origin https://xxx.git

git remote -v或者git remote show

git remote set-url origin https://xxx.git

ps：需要初始化master，初始化参考分支，最后关联分支

2.初始化master分支（init后没有master分支,手动提交后就会生成master分支）

touch a.txt

git add a.txt

git commit

3.初始化参考分支

git fetch（将远程分支代码同步到参考分支）

git branch -a

4.同步本地分支(创建分支+合并分支操作)

git branch --set-upstream-to=origin/参考分支(master) 本地分支的名字(master)

git merge --allow-unrelated-histories（忽略初始化master分支的提交信息）

ps：若不初始化参考分支也不进行将参考分支同步到本地分支则使用git pull origin master

5.以上步骤都多余，你可以直接使用git clone xxx，但是clone的本质就是提前帮你把这些都设置好了。

3.常用回退操作

git reflog（显示所有提交过的版本信息，不包括已经被删除的commit记录和 reset 的操作）

git log（显示所有的操作记录，包括提交，回退的操作。一般用来找出操作记录中的版本号，进行回退。）

git reset --回退模式版本

mixed：回退本地仓库+暂存区（默认：工作区代码变红、需要add添加至暂存区）
soft：回退本地仓库（暂存区、工作区代码变蓝、需要commit添加到本地仓库）
hard：回退本地仓库+暂存区+工作区（工作区代码会消失）

4.分支常用操作

1.创建分支

git branch 分支名称

2.切换分支

git checkout 分支名称

ps：快速创建于切换git checkout -b 分支名称

3.在分支上进行操作

.......

4.合并分支

git checkout master

git merge 分支名称

ps:合并分支前重新pull一下

5.删除分支

git branch -d 分支名称

5.开发流程

多人合作开发

1、首先项目经理初始化仓库建立好分支。一般会建立两个，一个master分支，一个develop分支。当然，也可能建立一个预发布版本的分支用于测试的 realse分支。

2、对个分支设置保护行为。

3、添加项目成员。

# 4.将项目克隆到本地。
>>> git clone 仓库地址
>>> git checkout develop
# 5.切换至开发分支
>>> git checkout -b feature-discuss
# 6.在开发分支上新建一个单独的功能分支，进行开发。
>>> touch discuss.java
# 7、在开发分支上新建一个单独的功能分支，进行开发，假装discuss.java就是我们要开发的功能
>>> git add .
>>> git commit -m 'finish discuss feature'
# 提交更改,多次测试以后，回到develop分支
>>> git checkout develop
# 8、开发完成，合并到开发分支，如果功能分支没用了，可以删除。
>>> git merge feature-discuss
# 删除功能性分支
>>> git branch -d feature-discuss
# 9、先拉取新代码（git pull）,其实就是合并，发生冲突，解决冲突。
>>> git push origin develop

10、解决完冲突，将代码推送至代码托管平台。

多团队合作开发

1、将代码fork到自己的仓库，同样可以进行相关的配置。

2、项目克隆到本地。

3、可以担任开发也可以多人开发。

4、开发完成后合并到自己的仓库

5、发起pull request请求给源仓库管理员

6、源仓库管理员进行code review（重新检查代码，审核代码），测试审核，通过则进行合并。

三、常用错误合集

1.master分支不存在

描述：fatal: not a valid object name: 'master'

原因：由于使用git init刚创建的git仓库默认的master分支要在第一次有效的commit之后才会真正建立，否则就像你声明了个对象但没初始化一样。

解决办法：提交一次本地仓库

git add .
git commit
git branch dev

ps:倘若git项目下没有任何文件可以commit，那么这样子执行也是没有用的，估计是初始的master对象为空无法根据master去创建新分支。

2.拉取远程仓库代码时代码丢失

描述：合并代码时发生了几次“不明确行为”，有时候发现自己的代码莫名的丢了，有时候发现合并后别人的代码静悄悄的丢了。

原因：参考分支出问题了，更直白点就是分支管理出现了混乱，导致了不明确行为（参考分支没有及时跟新）：local丢代码或者remote丢代码。

git merge-base local remote（查看base分支）

对于base（参考分支）来说，local和remote都是派生出来的分支，都可能会修改base的内容，这个意义上来说，local和remote是同优先级别的，也就是程序员A合并程序员B的代码（B先手提交了）和程序员B合并程序员A的代码（A先手提交了）行为是一样的。
如果local的file1/line370的内容和base一样，与remote却不一样，那么即可认为是remote对该内容进行了更新，合并时候以remote的file1/line370内容为准进行自动合并（pull时会丢失本地代码的原因）。反之亦然。
举一个场景小度修改了A文件第370行，并提交了。
此时小强也在A文件进行修改，在文件末尾添加了一些新方法。此时在pull。
于是小强发现自己新添加的代码消失，而370行会改变！！！
所以工作时一定要先pull在写代码
如果local和remote都对file1/line370进行了修改，那么这时候不知道要保留谁的修改了，就会提示合并冲突，让用户自己决定要保留哪个修改。

解决办法

分支管理方案

本地master分支链接远程分支，在本地新建一个dev分支，切换到dev分支在此分支上进行开发，最后切换到master分支（切换后先pull最新代码），在合并dev分支，最后进行commit与push。

代码找回

使用idea找回代码，在项目根目录上或者在文件上鼠标右键查找local history，show History，回退即可。