系列文章目录
文章目录
- 系列文章目录
- 前言
- 一、Gitee下载，连接
- 二、接下来我们回到软件内看看如何开发
- 1.发生甚么事情了
- 2.Pull&&Pull Request
- 4.debug
- 5.版本回溯
- 总结
前言
提示：以下是本篇文章正文内容，下面案例可供参考
一、Gitee下载，连接
1.新建project，这时的VCS是这样的，没有git的选项
2.然后，我们需要在Gitee上面创建这个项目的仓库，其实很简单，在软件内就可以添加到项目
3
.需要给仓库命名remote表示远程名，一般为origin（也可以取自己项目的名称）
4.创建完成后这里显示红色的都是未提交到本地仓库的代码
显示如下为成功
5.检查gitee是否有该仓库
6.这里显然已经有了，但是仓库都是只有一个master分支，现在我们给仓库新增分支吧
进入仓库
新增分支，这里dev代表开发的意思，因为android 开发中并不直接将开发内容推送到master上，而是先在dev上面开发，然后在本地开发，每开发到一定程度push到dev分支，然后到一个小阶段，就可以向仓库的主人发送pullrequest请求来将自己的dev分支合并到master。
这里添加两个分支吧，另一个分支代表我的开发队友(给不同队友不同的dev使用权限，防止开发时提交到错误位置)
二、接下来我们回到软件内看看如何开发
1.发生甚么事情了
1.大家可以看见下面的log中显示了local和remote代表本地仓库和远程仓库，大家在本地仓库开发，然后commit到本地仓库，然后定期的push到dev开发分支中。
大家看看图中的remote中，怎么没有我们新创建的分支？
这是因为软件无法自己感应到在远程仓库的操作，这里需要点击刷新按钮（fetch all remotes）,dev开发分支就显示了
2.现在我们开始开发了！！
这里我们不需要立刻对remote仓库进行任何操作，因为remote仓库和我们local内容相同，只有当local内容修改时，才需要push到dev分支上面去。
下面我们添加了一个新按钮作为例子。
3.下面我们来commit到本地(实战中稍微多写点代码再commit)
在旁边填上自己的名字和邮箱(当你已经使用命令行设置了身份后，这里写入name首字母就可以提示，并且有尖括号内带邮箱的提示才是有效的)
假如你时第一次commit，使用名字<邮箱>可方便的提交commite message中写入信息，一般实战中要规范一下commitemessage的格式
4.提交后的界面就是如下，大家可以看见local中出现了新的内容，一共有两个阶段。
旁边还有标签显示，黄色是HEAD标签，绿色是local的master的标签(鼠标点击标签旁边的文字就显示有哪些标签)
接下来看下面的阶段，代表的master和两个dev标签内容相同
5.commit后只是在本地中有新的内容，但是内容并没有体现在自己的dev开发分支上面。我们需要push操作来将自己的dev开发分支push到仓库中
这里要注意的是不能提交到master上面，而是改成自己的开发分支名字，并选中下方出现的版本，再提交
6.到这里，仓库的dev已经有我们的开发内容了，假如还想开发，就继续在本地开发，然后push到dev开发分支上面，如果觉得此阶段的开发已经达到一定阶段了，就在gitee仓库中提出pullrequest请求将自己的dev开发并入master。
7.pullrequest
进入仓库
这里我貌似刚才开发时提交到错误的dev开发分支上面了（在实际的开发分支上面人员对不同分支需要设置管理权限以防提交到错误的位置）
这里出现了一点小差错
我刚才将开发内容提交到了dev_friends上，所有这里将dev_ggzx合并时，下面显示两个版本相同
这里才是正确的，当pullrequest时，会向仓库主人发送请求，在这里编辑请求和内容，然后主人就可以在通知中接受请求，然后代码就会自动合并
提交后显示如下，仓库主人和测试人员可以看见此条消息，然后可以将队友提交内容clone下来测试，测试完成后，仓库主人和测试人员通过后，仓库中代码才会合并
同意后这里显示源目标和目标分支没有冲突（因为我刚才开发时只有新增代码，没有修改代码，若修改代码，源分支和目标分支中原本相同的代码发送了变化，仓库会提示代码冲突，让你手动解决冲突）
合并后，我们进入软件查看，点击下方左侧刷新按钮（fetch all remotes）,发现原本空荡荡的master分支有了新内容。为什么会有三个版本？
第一个初始化时的版本，第二个我们没有直接提交到master中哇？为什么会显示？这是这个版本我们push到dev开发分支中，然后又进行了pullrequest操作，但本质上还是我们的这个最新开发版本和仓库的master进行了合并，而旁边的两条线段表示的就是这样的一个合并过程
2.Pull&&Pull Request
刚才我们只是简单讲了Android Studio的Gitee插件的简单使用，而真正的开发过程还在后面，征途才刚刚开始。
我们这里只完成了自己的一次提交，那么当队友完成了提交，并且合并到了master上面了，我该怎么办？？？下来来讲关于团队开发长期开发的问题
当多人共同开发时，仓库的代码会经常发生变化，那么如何保证每个队友的开发代码都保存在仓库而不发生冲突呢?
这里我进入了仓库，在activity中增加了第13 行，此时我软件内并没有更新，怎么办,，这里我要求每次开发时都从仓库中pull下来最新的代码。注意软件内会更新出仓库中新增代码。
假如本地和仓库都有新改动，则会将master的新改动pull下来合并,假如仓库没有新代码（即dev版本高于master版本），pull之后本地也不会回溯到master版本（也就是说本地的新代码不会消失）
pull最新代码，这里pull master分支还是dev分支呢，这里一般看master最近有没有接受pull request请求，假如接受了，就需要从仓库master中pull最新的在这里我pull了仓库中全部分支,master分支,，然后该分支的修改代码会更新到本地的local的master中。
这里我们pull操作也完成了，pullrequest操作也可以在软件内
4.debug
关于在local中建立debug分支
右键local的master分支，建立debug分支
)然后看看版本控制，发现debug分支在master前面，这就满足了我们debug的需求，在debug分支中修复bug，防止影响到master分支。
现在我们默认我们debug完成了
然后就需要将debug合并进入master中
我们需要右键master标签的版本，右键checkout，使得HEAD回到master版本，然后
打开VCS选项，进入Git-merge change，选择本地的debug分支，然后本地的master分支就会与debug合并
5.版本回溯
现在我们新更改一行内容
然后我们要commit到local的debug分支，大家要注意下面显示的分支名，注意不要提交到master上面了。
假如你不清楚现在处在上面分支上可以看下栏的Branch，这里显示当前处在哪一个分支上
现在我们提交
接下来我们模拟实战中提交过代码，但是遇到问题想要版本回溯的问题
这里以debug分支为例子，将debug分支版本回溯
记住在回溯之前，要保证当前的HEAD处于debug分支上面
确保在debug分支上，右击需要回溯的版本,选择
从下面的箭头可以看出来，版本回溯 的方向
这里我们选择了Hard模式，所有文件会回到这个版本时的状态
下一篇Gitee操作我会讲Gitee push commit在实战中如何规范
总结
系列文章：Android Studio之gitee插件使用
