1、git基本内容

git即版本仓库。分为远程仓库和本地仓库，将某个远程仓库分支想象为1，则所有同事开发的本地仓库为n，那么，远程仓库和本地仓库为一对多的情况。

git的命令基本都是给本地仓库使用的，给远程仓库使用的命令，常用的就是，关联远程仓库、删除远程仓库、拉取远程仓库、推送到远程仓库。远程仓库需要保证问题，所以，不能跟本地仓库一样使用命令随意处理，出了问题删掉再新建一个，或者拉取远程分支覆盖本地分支。

git的实质就是，某些内容的分隔或聚合。即，将一些代码分割开来，或者将一些代码组合起来。所以，用好git的前提就是区分，什么东西需要聚合，什么东西需要区分开来，清晰了，那么，你就知道该怎么使用git了。

2、git基本使用

1、工作区

工作区即代表着，代码还没有提供给git版本管理，只是本地的保存，没有本版历史等信息，可以通过命令：git checkot . 放弃工作区更改

2、暂存区

命令： git add [ . | path ]

解释：将代码提交到暂存区，这只是一个中间状态，也不具备版本信息，只是在git记录了，工作区丢失了，还是可以通过暂存区获取到的，相当于备份了。

其他：可以通过git status查看更改的信息，可以通过git reset放弃暂存区更改

3、本地仓库

命令： git commit -m "备注信息"

解释： 将代码提交到本地仓库，可以进行本地的版本管理，也可以结合svn，本地使用git，代码提交则使用svn。这个时候，代码被版本所控制，每个版本的更改都能查找出来。

其他： 可以通过git reflog 查看提交的历史版本，会提供一个id和备注信息，所以备注信息很重要。可以通过git reset --hard HEAD 等命令重置版本，会舍弃掉该版本后的版本，也可以通过git checkout 版本id，切换到该版本，则不会删掉之后的版本，类似新建了一个同名的分支（团队开发中过于复杂，不建议使用）。

4、 远程仓库

命令：git pull、git push

解释：将本地选中的分支仓库和线上分支仓库同步

5、其他

查看还未版本控制的内容：git status

查看分支情况：git branch --l

删除分支：git branch -D 分支

新建分支：git checkout -b 分支

存储：git stash save "备注"

查看存储情况：git stash list

获取存储内容：git stash pop

……

备注：存储功能慎重使用，存储功能是指代写的代码还不适合提交版本，那么，就可以用存储，会将工作区和暂存区的所有更改另外存储，切换分支去处理其他东西，切换回来将存储的内容拿出来就可以继续开发了。但是，会存在代码丢失的情况，不建议使用。

3、git常见问题处理

1、与远程仓库同步时，版本混乱

莫名会多出很多更改：

原因：多次不规范使用git，导致版本混乱

处理：放弃更改，重新获取代码，git checkout . 或者可视化操作工具

2、远程分支冲突

两个远程分支冲突：

原因：代码处理提交的分支没有严格执行，在不同人处理的时候，重复处理到了同一段代码或者其他。

处理：

1、分别从本地切换到对应的远程分支，

2、如果不能切换，那么，就新建一个分支，关联远程分支即可（pull），

3、再从这两个分支分别切一个新分支，原本有也可以用，

4、切出来的分支发起合并操作，

5、处理冲突，

6、处理冲突后，被合并的分支合并合并到对应的远程分支即可

3、生产环境有紧急bug修复

从该环境分支切一个新分支，修复后直接合并到该分支，并且同步到其他分支。

原因：

1、其他分支有可能存在同事不小心错删代码了，导致整个分支崩溃了，或者合并代码的时候没有跑一次再合，导致崩溃等等……

2、保证该分支的代码是最接近测试的，保证代码尽可能的安全

3、这个时候，修改的bug，所有分支都有，新开发的功能该分支没有。

4、其他分支也是一样的，一版作用与uat和prd

4、如果在不合适的分支开发了不合适的代码

这个时候就需要采用最强大的方法了：将代码本地备份，reset分支代码，将本地代码拷贝过去。该方法运用很多场景，十分强大，无副作用，优先考虑。

5、遇到git版本混乱，很多更改，不小心提交上去了（十分严重，十分耗时）

截肢。任何合并，reset分支合并也没用

处理：

1、找到这次提交的版本，

2、将代码拉到本地，执行reset命令，将版本回退到该版本前一个版本，

3、删除远程分支，再将当前分支关联到远程分支，设为版本分支，

4、其他代码通过本地备份，或者线上切出来的预备分支，进行还原，

5、其他分支也一样，如果都同步了，那就删掉所有的分支，从该分支切出来

6、其他

百度。

4、git团队开发模式

1、整体

1、一般项目中都会分为：dev、test、uat、prd

2、其中，dev、test为A组，uat、prd为B组

3、正常的新功能开发以feat关键字开头的，已经上线的bug修复以hotfix关键字开头

4、hotfix分支可以随时合并到A组以及更新的功能分支

5、hotfix合并如果要合并到B组，则需要先合并到test，经过测试后能合并到B组

6、每次uat更新，hotfix分支都需要同步各个分支，并且更新hotfix分支为最新uat代码

2、解析(根据1)

uat和prd是实际客户、用户使用，所以得保证稳定，隔离一切还未进入的风险，所以，修复uat、prd的bug，需要再hotfix分支开发，如果紧急的，还可以直接从uat切分支，直接合并到uat（uat和prd代码应当是一样的，建议是先合并到test，验证没问题再由该分支直接合并到uat，而不是再由test合并到uat，test可能有新模块功能），经过测试大量测试，所以，uat代码应该是比较稳定，而新增模块有些条件必须改一些之前的代码和逻辑，可能导致问题，所以新功能模块不能直接合并到uat。

简单一个例子：

1、从dev切出a分支，a分支写了文字“aa”，

2、提交上dev，那么现在dev是“aa”，

3、这个时候，再从dev分支切出b分支，这时候b分支是“aa”，

4、b分支将“aa”删掉，提交到dev，

5、那么，最终结果，dev是空，a是“aa”，b是空。

如果不进行隔离，所有人都共用dev，合并到uat，那么，这个时候，提交的时候，就会少了a分支的内容

再来一个例子：

1、从dev切出a分支，a分支写了文字“aa”，

2、提交上dev，那么现在dev是“aa”，

3、这个时候，再从uat分支切出b分支，这时候b分支是空，

4、b分支添加“bb”，合并到dev

5、那么，现在dev有“aa”、“bb”

6、检验没问题，b分支合并到uat，那么，这个时候，uat只有“bb”

现在uat与dev是隔离的，新改动的uat有，dev也有，dev中新功能“aa”，却没有提交到uat，从而实现隔离