一)git的介绍:
1)假设现在有一个文档，你的老板要求你针对于这份文件进行修改，进行完成的修改的版本是版本1，接下来是文档2，修改完文档2以后，接下来老板还不同意，于是又有了文档三，文档四，但是此时老板说第一个版本的文档是最好的，但是此时最终文档保存的内容是文档四最终的内容，此时想要拿到第一次文档修改的内容是无法拿到的，此时这一份工作就无法完成了，这种情况是针对于一份文档做多次的修改，我们无法针对于不同的文档进行管理，我无法拿到第一次修改的内容，也无法拿到第二次，第三次修改的内容；
2)此时第二次的时候，我的老板有要求再来修改一份文档，此时我们将第一次修改完成的文档是设计文档V1，此时设计文档V1完成以后，老板说你的文档不靠谱，此时你再去给我修改，但是此时我会把文档V1复制一份，此时就得到了另一款设计文档，就是设计文档V2，此时我们手里面就有了两个版本的文档，此时无论是第一个版本的文档还是第二个版本的文档我都有，此时果然当文档2上传的时候老板此时还不满意，我就针对于这个文档反反复复的进行修改，此时已经把设计文档更新到了文档V5，此时老板说你修改的这些文档还不如你当初修改的第一份文档，此时我就把第一份文档开开心心的交给他了，对一个文档进行多个版本的管理，这是仅仅在文档内容比较少的情况下，但是如果文档升级版本过多，此时维护的成本也越来越高，是很有挑战的，各自的版本的修改的内容还是什么还知道吗？
3)版本控制器就由此诞生了， 可以记录每一次代码的改动和版本的迭代都可以记录起来，记录每一次的修改的内容以及版本迭代的一个管理系统，git就是目前最主流的版本控制器，git可以帮助我们控制电脑上所有格式的文件或者是文档，对于开发人员来说，可以管理软件开发中的源代码文件
版本控制器就是能让我们了解到一个文件的历史，以及他的发展过程，通俗的来讲就是一个可以进行记录工程的每一次改动和版本迭代的一个管理系统，同时也方便很多人协同作业
二)安装git
1)查看git是否已经被安装:git --version
2)卸载git:sudo yum remove git -y
3)安装git:sudo yum install git -y
三)创建git的本地仓库:
1)git是一个版本控制系统也是一个版本控制器，如果记录每一次修改的内容和版本迭代的一些内容，虽然可以使用git追踪管理，但是这些文件内容不可以存放在电脑上面的任意位置，如果这样的话git就不能追踪管理了，如果想要管理这些文件，就需要把这些文件放到仓库中
2)只有在仓库中的文件才能被git追踪并且管理，所以先创建一个文件目录，然后尝试使用命令来创建仓库，git init命令就可以在当前文件目录下创建一个本地仓库，点击回车即可
3)由此可以看出当前目录gitcode下面有叫做.git的目录，这是执行git init命令以后新增的
4)使用tree命令，可以看到在.git/隐藏目录下面有很多东西，这个隐藏目录是用来追踪和管理仓库的，注意不要修改这个隐藏下面的内容，否则会把这个git仓库给破坏掉
5)最后在gitcode目录下面配置name选项和email选项，如果不配置这两个属性，那么将来再进行操作本地文件的时候就会出现问题，下面是命令
git config:git config user.name+"自己的自定义字符串"
查看所有已经被设置过的键值对:git config -l
删除已经的键值对:git config --unset user.name，想把name删除掉
我们在服务器上面不止可以配置一个本地仓库，可以创建多个本地仓库
git config --global user.name "XX"，这里面的global表示在当前的服务器上的所有本地git仓库都进行设置生效
git config --global unset --set
四)认识工作区，暂缓区，版本库
在当前的情况下，在gitcode目录下创建一个readMe目录，但是Git是不能管理readMe文件的
.git是仓库，也就是版本库(仓库)，但是readMe文件本身并没有存在于本地仓库里面，真正的本地仓库是.git而不是我们创建的gitcode目录，那能不能直接将文件放到.git目录吗？
执行tree .git下面的目录如下:是不可以在.git下直接添加文件的，不允许在.git文件下面进行新增文件，删除文件，否则会导致本地文件无法使用了，所以只能将ReadMe文件直接写在gitCode目录下面；
工作区:就是在电脑上或者是服务器写代码或者文件的目录，咱们的git本地仓库是不可以直接管理工作区的文件的
.git目录:版本库，虽然.git文件是在gitCode目录下面的，但是它并不属于版本库
先将工作区的内容存放到暂存区中，最后再将暂存区中的内容存放到版本库中
1)add命令:执行add命令以后会将工作区中的新增修改删除的内容保存到版本库的暂存区中，git add .，就是将当前目录下面的所有的修改存放到暂存区中或者是git add 文件名
2)commit命令:将暂存区的内容存放到master分支下里面也是存放的是修改文件的内容的索引，只有执行commit操作以后才算真正的写入了一个版本库git commit -m "本次提交的细节"
3)对象库objects:每一次执行add命令以后，修改的工作区的内容会写入到对象库中的一个新的git对象中，这就相当于是维护了工作区的版本，就做好了对于一个文件版本的管理，对应的是.git目录下面的objects目录；
从head指针开始，就可以拿到所有文件修改的内容，就可以拿到master的分支，对应的是.git目录下面的head目录
4)暂缓区:英⽂index，⼀般存放在.git⽬录下的/index⽂件.git/index中把暂存区有时也叫作索引
5)版本库:也被称之为是仓库，工作区有一个隐藏目录.git，他不算作是工作区，而是git的版本库这个版本库里面的所有文件都是可以被git管理起来的，每一个文件的修改删除，git都是可以追踪的，以便任何时候都是可以追踪历史，或者在将来某一个时刻可以被还原
在进行创建Git版本库的时候，Git会为我们创建一个唯一的master分支，以及指向master分支的一个指针叫做HEAD，我们还可以多次add不同的文件，而只是commit便可以一次性的提交所有文件，是因为需要提交的文件统统被add到暂存区中，然后一次性的commit暂存区中的所有修改
五)commit add命令
git add readMe
如果要是针对于readMe文件进行了修改，就把readMe文件的修改放在暂缓区中
git add .如果要是针对于工作区中的任意文件进行了修改，暂存区的⽬录树被更新，同时⼯作区修改（或新增）的⽂件内容被写⼊到对象库中的⼀个新的对象中就位于.git/objects⽬录下
git commit -m "描述信息"，可以写添加了第一个文件
git log的作用就是看出最近的提交的信息，每一次提交都是随机生成一个ID
或者使用git log --pretty=oneline
1)查看.git目录下面的HEAD目录下面的内容
在gitCode目录下面，cat ./.git/HEAD可以直接看到HEAD指针直接指向MASTER的分支
2)下面来看一下master中的内容，这里存放的就是最新的提交的修改ID，就是git中的对象
3)现在左边执行 cat ./.git/refs/heads/master，然后根据打印出来的ID来找到objects中的git对象，最后通过git cat-file -p+上一步查询出来的ID
可以在最底层看到提交版本时候的描述信息，这个是自己添加的，parent是包括上一次提交的commitID，还包括是谁修改的版本信息，最上面的tree后面的ID很奇怪，我们打印一下:
这里面的打印出来的内容就是我们在此次版本中新增的文件
继续打印一下blob后面的ID的内容:打印出来就是此次对于文件的修改操作，比如说新增加的文件内容，这都会被git记录下来，objects中存放的就是工作区已经被修改的对象的内容中；
总结:index中存放的就是add后新增的内容(针对于文件来说)，head指向的是master，master存放的就是最新提交的commitID，commitID就是一个git对象，维护在了对象库中；
其实学到这里也知道了，git其实本质上追踪管理的是修改，而不是文件，因为修改的工作区中的内容会写入到对象库中的一个新的git对象中
git status
上一次提交过后到现在有没有针对于文件做修改，比如说将暂存区中的内容进行提交，还有比如说针对于此文件做了修改，但是还没有完成添加和提交
但是目前我们只是知道了文件被修改了，但是能知道具体哪些地方被修改了，就更好了，可能您会说修改的我知道了呀，但是确实无法知道三天之前修改了什么或者有哪些差别
git diff显示git中暂存区和工作区之间的差异的，看看版本库和工作区的文件的差别
git log能够查看历史提交记录
---和a是改动前，+++和b是改动后，第三行，-代表改动前是第一行内容，+1，2表示改动前的第一行到两行的内容
1)在创建Git版本库时，Git会为我们⾃动创建⼀个唯⼀的master分⽀，以及指向master分支的⼀个指针叫HEAD，当针对于工作区新增或者修改的文件执行git add命令的时候，暂存区中的目录树的文件索引会做更新，当在执行git commit操作的时候，master分支会做对应的更新，可以简单地理解成暂存区的目录树会被真正的写入到版本库中，通过新建或者是粘贴进入到目录的文件，并不能称之为是向仓库中新增文件，而是只是在工作区中新增了文件，必须要通过使用git add或者是git commit命令才可以将文件添加到仓库里面
2)我们还可以多次add不同的文件，而只是commit一次便可以提交所有文件，是因为需要提交的文件统统被add到暂缓区中，然后一次性commit暂缓区中的所有修改
3)objects是git的对象库，里面包含了创建了各种对象的版本库以及内容，当执行git add命令的时候，暂存区的目录树被更新，同时工作区中修改的内容或者是新增的文件内容对写入到对象库中的一个新的对象中，就位于".git/objects"目录下面
六)版本回退:
git log --pretty=oneline可以找到历史提交版本的commitID
之前我们也说过，Git能够进行管理文件的历史版本，这也是版本控制器非常重要的能力，如果有一天你发现了之前做的工作出现了极大的问题，需要在某一个特定的历史版本重新开始，这个时候就需要版本回退的功能了，git rest命令用于回退版本，可以指定为退回到某一次提交的版本，要解释一下回退是根据要将版本库中的内容进行回退，工作区和暂存区中的内容是否进行回退有参数决定
现在我们的readMe文件有两个版本，一个是现在的版本，但是之前还有一个只有hello的版本
git reset [--soft | --mixed | --hard] [HEAD]
1)--soft:只是将版本库回退到某一个版本，对于工作区和暂存区中的内容是保持不变的
2)--mixed:默认选项，将版本库和暂存区中的内容进行回退，但是不会回退工作区中的内容是默认选项
3)--hard:工作区，暂存区，版本库都会进行回退，但是这个hrad要慎用，因为可能在工作区中写了很多代码，不小心使用了一个hard就把工作区中的内容全部进行回退了
HEAD说明:可以直接写成commitID，表示指定回退的版本，HEAD表示当前版本，HEAD^表示上一个版本，HEAD^^表示上上版本
git reset --hard c6a71a7d66186d0691ad354928f6a851bf003b40
如何后悔了进行撤销操作，就找到对应的CommitID进行版本的回退
git reflog记录本地每一次的提交命令，也可以找到短的commitID进行回退
git中有一个HEAD指针，HEAD指针指向master，master指向CommitID，commitID本身就是一个git对象，里面存放的就是文件修改的内容，如果想要进行版本回退
七)撤销修改:
如果说我们在工作区中写了很长时间代码，越写越写不下去，觉得自己开发代码的质量实在是太差了，于是就想恢复到上一个版本，这就被称之为是撤销操作，有的兄弟可能会说直接
手动撤销:通过git diff命令来查看老版本和新版本的一个改动
1)只是将工作区中的内容进行了修改，暂存区和版本库没有发生变化:
自动撤销:git checkout --文件名表示要将此文件回退到最新的commit或者add时候的状态
git checkout --[file]命令可以让工作区的文件回到最近一次add或者是commit的时候的状态，要注意--不能省略，否则就变成其他意思了
2)将工作区和暂存区中的内容进行了修改，版本库没有发生变化
2.1)git reset --hard +对应的版本库的版本ID，直接将版本库，暂存区和工作区中的内容全部进行回退，或者使用git reset --hard HEAD
2.2)git reset --mixed+对应版本库的版本ID，直接将版本库，暂存区中的内容进行回退，然后直接使用第一种方法直接将工作区的内容进行回退，更推荐使用git reset HEAD+回退对应的文件，默认是mixed选项，不加尖括号表示回退到当前版本，加上两个尖表示回退到上两个版本，最后使用 git checkout --(文件名)回退工作区的内容
将来在版本库还要向远程仓库中使用push命令进行推送，但是上面撤销的目的就是为了不影响远程仓库的代码，真正意义上称之为是撤销前提是远程仓库没有这一份代码
3)将工作区和暂存区和版本库中的内容都进行了修改，但是没有push到远程仓库
git reset --hard HEAD^
八)删除文件
在git中，删除也是一个修改操作，如果直接将工作区的内容删除了，此时工作区和版本库此时就不一致了，要删除一个文件，不光要删除工作区的文件，还要进行清除版本库中的文件
一般走到这里面有两种可能:确实要从版本库中删除文件，第二种就是不小心删错了，对于第二种情况这种误删除的操作，我们要使用git来进行恢复，也就是git checkout --文件名字
但是对于第一种情况，明显是没有删除完成，我们只是删除了工作区中的文件，这个时候就需要使用git commit -m来进行提交了，也可以使用git rm file名字，将工作区和暂存区中的文件都进行了删除，最后使用git commit -m "已经删除此文件"
九)理解分支:
HEAD不仅仅可以指向主分支还可以指向其他分支，master所指向的分支其实本质上就是工作分支，之前在我们每一次进行提交的时候，master分支都会向前移动一步，随着不断的提交，master分支的线也越来越长，而且HEAD只要一直指向master分支即可指向当前分支
git branch:查看有哪些分支，当git本地仓库创建的时候git就会给我们创建出一个主分支
创建分支:git branch 分支的名字
切换分支:git checkout 分支的名字
在dev分支上进行了commit
合并分支:
1)首先切换master分支:
2)合并分支:git merge 分支名字
fastword表示快进模式，也就是说直接将master分支指向dev的当前提交，所以说合并速度非常快，当然也并不是每一次合并都能fast-forword
十)删除分支:
合并完成以后，dev分支对于我们来说就没有什么用了，那么dev分支就可以删除掉，注意如果是说当前处于某一个分支下面，就不能直接删除该分支 git branch -d +分支名字
因为本身创建合并删除分支都非常快，所以Git鼓励使用分支来完成某一个任务，合并以后在删除分支，这和直接在master分支上工作效果是一样的，但是过程更安全
切换到一个新创建的分支:git checkout -b 你要创建的分支
十一)合并冲突:merge冲突需要手动解决，并且需要进行一次提交操作
那么现在发生冲突的时候，git会自动将冲突的代码展现出来，然后最后由我们程序员来进行决定保留那一部分的代码，然后其他的全部进行删除，最后使用git add .和git commit命令提交到版本库中，但是此时dev还是指向自己的提交，最后将dev分支删除
git log --graph --pretty=oneline --abbrev-commit
git merge - -no-ff -m "merge dev" dev，更好的区分是master模式和no fatser模式
所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾经做过合并，⽽ fast forward 合并就看不出来曾经做过合并
faster分支:
十二)BUG分支:
1)假设此时我们正在dev分支上进行开发，开发到一半的时候发现master分支上面有bug，需要进行解决，在git中，每一个bug都是可以通过一个新的临时分支来进行修复，修复完成以后合并分支，然后将临时分支删除
2)初心是现在先进行修改master分支上面出现bug的代码，可是现在在dev上的代码在工作区中开发了一半，但是还没有进行提交，但是我们的目标是不想在master分支上面看到dev上写的代码不用怕，git为我们提供了git stash命令，可以将当前dev工作区的信息进行保存
被存储的内容可以将来在某一个时间被恢复出来，此时使用git status查看工作区，此时就是干净的，除非有(没有被git管理过的文件)否则都是可以存储在stash里面，可以放心地创建分支来修复bug，由于我们要基于master分支来修复bug，所以要切回master分支，再来新创建临时分支来修复bug，修复bug完成add和commit，最后再来合并分支(master和修复bug的分支,git merge --no-ff -m "merge bug")，最后删除这个修复的bug的分支；
3)到了现在bug的修复工作已经全部完成了，我们还是要继续回到dev分支进行开发，此时发现工作区是干净的，刚才的工作现场到哪里去了，使用git stash list命令进行查看当前stash区里面存放了那些东西，工作现场还在，Git把stash内容存到了某一个地方了，但是也是需要恢复一下，在dev中可以使用git stash pop命令，恢复的同时也会把stash给删了，再次查看的时候发现已经没有现场可以恢复
4)虽然此时的master主分支已经成功修复bug了，但是dev还没有成功修复，是因为dev分支创建的时候是基于master分支有bug的时候创建出来的，dev是看不到这个master分支下面的已经修复的bug，此时合并的时候解决冲突可能会发生报错，导致master报错会出现报错，是因为在合并分⽀时可能会有冲突
⽽代码冲突需要我们⼿动解决在 master上解决可能⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上，此时的状态为：此时head指针指向dev2，但是master分支相比于dev2分支是多了一次提交的，master分支是比dev2分支多一段的；
5)解决这个问题一个比较好的方案就是最好在自己的分dev支下面合并一下master，再让master去合并dev，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master，此时的状态为
分⽀在实际中有什么⽤呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50%的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了，如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
现在有了分⽀，就不⽤怕了，你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈⼯作，并且Git⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件强制删除:git branch -D 分支名字，注意不能再当前分支删除当前分支
十三)远程仓库也叫做中央服务器的仓库
master主分支跑的都是稳定的代码，每一个人都可以创建一下分支然后最后合并分支就可以
十四)gitee的使用:
1)将来在工作的时候，新建仓库的时候，仓库名称就是项目的名字,当我们填写成功以后，最终会生成一个仓库地址，创建好仓库以后，就可以根据仓库地址来访问仓库
Readme文件写的是这个仓库里面详细的文件信息是什么，当我们创建好文件以后，会在这个仓库里面新增一个ReadMe文件，就是一个介绍的作用
2)创建以后点击管理，基本信息，最下边就可以设置成开源
点击管理，我的，仓库成员管理
3)Issue:让发现问题的人员和仓库的一些管理者进行交流的地方，还可以选择处理的人
4)Pull Request:想要进行merge代码的时候需要先向管理员申请一个证书
克隆远程仓库:git clone 对应的url地址
点击头像，设置，添加SSH公钥
但是对于SSHclone来说，直接 git clone [email protected]:data_json/remote-code.git 会直接报错没有权限
1)配置SSH公钥:如果家目录下面没有id_rsa和id_rsa.pub那么首先要执行命令
ssh-keygen -t rsa -C "自己最真实的邮箱"
2)在这里面就可以配置公钥了，还可以配置多个公钥
现在在家目录下面进行将远程仓库中的代码克隆到本地上
1)尝试将@后面的字段配置成name属性
其实本质上本地和远程就是相当于是分支和分支之间的操作
2) git push origin master:master，一旦推送成功就可以立马看到本地仓库中的一些修改了
拉区到本地:拉取+合并 git pull origin master:master
十五)配置git:
在日常开发中，我们有些文件是不想或者是不应该提交到远端，比如说保存了数据库密码的配置文件，那如何让git知道呢，在git工作区的根目录下面创建一个特殊的.gitignore文件，然会把要忽略的文件名字填写进去，git就会自动忽略这些文件了，不需要从头写 .gitignore ⽂件，gitee?在创建仓库时就可以为我们⽣成，不过需要我们主动勾选⼀下
此时如果新增了一个so文件，git也不会进行管理的
如果非要管理:git add -f b.so，强制管理，或者直接在特殊的文件下面加上一个!b.so
git check -ignore -v 文件名字检查当前文件是否被忽略
标签tag，可以简单地理解成是针对于某一次commit操作的标识，相当于是说起了一个别名，例如说在项目发布某一个版本的时候，针对于最后一次commit起一个v1.0这样的标签有里程碑的意义，这有什么⽤呢？相较于难以记住的 commit id ， tag 很好的解决这个问题，因为 tag ⼀定要给⼀个让⼈容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使⽤标签就能很快定位到；
敲命令 git tag [name]就可以打⼀个新标签gittagname默认标签是打在最新提交的commitID的
可以⽤命令 git tag 查看所有标签
那如何在指定的commit上打标签呢？⽅法是找到历史提交的commitid，然后打上就可以了
git tag v0.9，创建标签
git tag查看所有标签，是根据英文排序进行展示的
git tag -a v0.8 -m "描述信息" commitID，给特定的版本打标签
git show v0.8可以看到相关的详细信息
删除标签:git tag -d 标签名字
创建对应标签:git tag -a [name] -m "XXX" [commit_id]，因为创建的标签都只存储在本地，不会⾃动推送到远程，所以，打错的标签可以在本地安全删除
如果要推送某个标签到远程，使⽤命令 git push origin <tagname>(标签名字)
推送所有标签到远程仓库:git push origin --tags
删除远程仓库的标签:git push origin :refs/tags/v1.0但是不建议将远程仓库中的标签进行删除
如果想要删除标签，需要先从本地删除，然后选择从远程删除
十六)git多人协作开发1:
之前来说，远程仓库和远程仓库之间的分支要进行建立连接，但是远程仓库中的master分支和本地的master分支是在clone仓库完成的时候自动进行构建的
git branch -r查看本地仓库在远程分支存储的内容
git pull 直接拉取远程分支
git branch -a查看所有分支
现在在远程仓库，分支，管理，新增dev分支
1)在windows上面进行协作开发:
选择git clone
此时我们虽然新创建了一个分支，但是没有打印本地的dev分支和远程的dev分支建立了联系
git checkout -b dev origin/dev
git -branch -vv查看本地分支和远程分支建立了链接
需要重新建立连接:git branch --set-upstream-to=origin/dev dev
接下来我们就可以正常进行一些操作的:针对于file文件进行新增bbb操作，最后进行远程已提交操作:如果发生冲突可以先进行pull到本地，然后再来进行解决冲突
1)git checkout -b dev在本地linux中创建一个dev分支并且切换过去
2)git checkout -b dev origin/dev在本地创建了一个dev分支并并且成功切换和远程的dev分支建立了链接
3)git branch -vv，查看本地分支和远程分支建立的联系
将远程仓库中的内容合并到master分支下面
1)PR操作:提一个申请单，现在我们新创建一个申请单，下面的东西就是写为什么将源分支下面的内容合并到新分支中，如果管理员发现你写的代码没有问题，就同意将dev分支合并到master分支里面了(推荐，因为老板和项目经理来进行审查)
2)在本地重是存在着dev分支和master分支，我们可以将dev分支合并到master分支上面，然后再来进行push操作，但是此时的一个解决办法就是先进行将dev分支和master分支进行合并，这样就可以在dev分支上面解决冲突，最后再切换到master，最后将master和dev进行合并(但是此时在这个过程保证master是最新的master，所以就需要pull操作，先将远程仓库中的代码pull到mater上面)
2.1)首先将master pull到本地，将远程仓库中的mater更新到本地的master里面
2.2)然后将master分支合并到dev分支上面
2.3)最后将dev分支合并到master上面
2.4)直接将本地的masterpush到远程的mater
删除dev分支
• ⾸先，可以试图⽤ git push origin branch-name 推送⾃⼰的修改； • 如果推送失败，则因为远程分⽀⽐你的本地更新，需要先⽤git pull试图合并 • 如果合并有冲突，则解决冲突，并在本地提交； • 没有冲突或者解决掉冲突后，再⽤git push origin branch-name推送就能成功 • 功能开发完毕，将分⽀merge合并master，最后删除分⽀
十八)git多人协作开发2:
条件:开发者各自私有分支，各自让某一个功能私有某一个分支创建远程分支和创建本地分支(本地master不是最新的远程仓库的master，除非要进行pull操作)，所以建议直接在远程创建pull分支
开发者1:
git branch --set-upstream-to=origin/dev dev这种方式还不太行因为远端没有对应的分支
1)使用git push origin feature-1，此时执行了这个命令以后，在码云上就创建成功了这个分支
2)git branch -a 就可以查看到本地仓库中远程仓库分支的情况
开发者2:
1)首先将mater分支pull到本地，保证master分支是最新的
直接提交即可
最终就可以看到分支上面有master1分支master2分支和master3分支
git pull拉取分支中的文件里面的内容，必须建立连接
git pull拉取远程仓库中的分支，拉取的是仓库的内容，就可以不需要建立连接了
此时出现了一个问题
git log --pretty=oneline 查看git的历史提交记录