gitee将代码上传到远程分支仓库
- 1.关于gitee的心声
- 2.关于gitee的基本使用
- 2.1新建git仓库
- 2.2创建git连接
- 2.3 git仓库分支的切换
- 3 将代码上传到远程分支
- 4.提交pull Request请求的原因
- 5.其他方法
1.关于gitee的心声
首先，如果你是一位正在急忙将代码传到远程仓库的“打工人”的话。我猜，这个时候你应该疯狂百度搜索如何 将代码上传到远程分支。当时你看到了我的博文，说明咱两有缘，江湖救急请看标题3，可快速解决问题。
我真心希望你现在不要急躁，不要急于将代码上传到远程仓库然后长舒一口气。因为，我也是过来人，我曾经也吐槽过gitee的难以理解，gitee搞人心态，我也曾体会过写bug的 2 小时里面至少有 1 小时被用来上传代码。在那些众多一个小时里面，是我写代码最难受的时候。我承认我曾因为坐热了板凳，这个汗都快滴下来了。今天，我决定必须正视这个问题。
其实，gitee很简单，是一个很好用的代码管理工具。但是不幸的是，往往由于我们技术有限，公司对于代码催得紧，因此每到时间快截止的时候，我们代码才改好，更多的是也许是延期。这时当gitee一系列报错会让我们更加难受。后来，我发现，其实不光是我，很多初接触者也是这样，传个代码搞了半天满头大汗。
为什么呢？原因有以下两点：
（1）它是代码的最后一段旅程，往往很急；
（2）gitee很多时候只有指令，因为它是面向应用的，代码写法多种多样，每个人有每个人的使用习惯。今天张三说这样可以，三下两下帮你传好了，明天你又遇到奇奇怪怪的bug，于是你去找李四，李四用不同的方法弄好了，当你问他为什么，他可能会告诉你很简单，反正代码传上去了，对呀，反正代码传上去了……周而复始，这样一天就来了，张三的方法不对、李四的方法也不行，一堆奇奇怪怪的bug,网上的博文都不对，很少又通俗易懂的。
其实，究其原始：还是没静下来，代码push上去了还会有bug,今天不会gitee明天上工还得用。因此，我更希望你不是一个为了早早提交代码下班的打工人，更希望你是一个初学者。与其面对gitee时满头大汗，不如传完之后好好反思，总结出一套自己的代码上传方法。
出了N多次汗之后，我总结了一些内容，珍惜希望能帮到你。
2.关于gitee的基本使用
2.1新建git仓库
创建仓库部分比较好理解，毕竟不是英文的github。相信你随便点点就能熟悉基本的仓库属性和创建时的附加权限。为了测试，我们创建如下所示的开源仓库：
2.2创建git连接
首先，需要下载git工具，官网下载可能比较慢，你也可以使用我上传的（里面的小乌龟其实没什么用处，下载git就行，因为我现在自己也没用小乌龟了）git工具资源。
如下图所示,在桌面上新建一个“用于git仓库的测试”文件夹，然后在文件夹里面鼠标右键，找到git bash,运行打开，输入git clone 加仓库链接，http和ssh两种方式都可以。
如上图所示，使用 git clone 之后，git能够将远程test仓库与当前本地文件夹建立连接，并将远程仓库下载到当前文件夹目录下。
2.3 git仓库分支的切换
你也许会好奇，文件是通过什么连接的呢，这个时候你可以打开电脑的查看隐藏文件夹权限。你会发现如下图所示的.git文件，正是这个文件使得远程仓库和本地仓库能够建立连接。
这时，你可以进入test文件夹里面，右键打开git bash here,输入git branch -r,也就是通常所说的查看分支命令，你就能看到刚才设置的分支了，如下图所示：
接下来，再使用git checkout test-dev2可以跳转到第二个分支了，如下图所示：
3 将代码上传到远程分支
为了帮助到可能时间比较紧急的你，我特地在这里写一个实际常用的场景。只要你能够静下心来看肯定5分钟内把代码传到你的远程分支。
（1）第一步，使用 git clone “远程仓库地址”；
（2）第二步，点击进入仓库文件（也就是目录里面有.git 文件的那个文件夹）；
（3）第三步，将你写好的代码复制进去，覆盖重复的文件，注意最好不要剪切，做好文件备份，毕竟这些代码来之不易，要是出了岔子重写岂不心态爆炸；
（4）第四步，在上述.含有git的文件夹里面，鼠标右键，使用git bash here，使用git checkout 切换到远程自己的分支，例如你的远程分支是test-dev3,那么你要使用的指令如下：
git checkout test-dev3;
git add .
git commit -m '你想要加的更新描述'
git push
如下图所示：
没错，就是这么简单，至于其他的，很多时候是你记混了方法，然后急躁的乱传。当遇到这些问题的时候你有如下方法解决：
（1）百度，找一些强制方法处理，记得使用之前备份写好的代码；
（2）将远程分支手动删除，然后新建一个一样的，一般项目的参与者这个权限还是有的，不过要是你们项目不是以 master 分支作为核心那就别这么做了。
（3）问问熟悉一些的同事，但注意总结一套完整的方法，最好固定下来，不要频繁的修改方法，它只是工具，不是你要看懂的框架。
4.提交pull Request请求的原因
通常提交Pull Request请求简称“提交pr”,为了说明这样做的缘由，接下来我们思考如下场景：
master 下面有A分支和B分支，现在，新代码都被传到了各自的分支。如果同时上传的master分支的话，那么A分支可能把B分支的代码给还原了，或者B分支把A分支的代码还原了。
如何解决这个冲突呢？通常情况下，代码管理者会将master分支设置成保护分支，每次向 master 分支合并代码都需要使用pull request发起合并请求。这样代码管理者可以依次查看A分支和B分支的修改内容，友好的合并两分支仓库的代码。
5.其他方法
嗯，看看了网上的其他方法，其实主要的还不是我上面使用的方法，而是下面这种，我也简单写一下我的理解吧：
对于推master的话，这个方法比较直接。首先使用git init 初始化，（补充说明上面不需要初始化是因为.git在仓库目录下有），然后使用git remote add origin "远程仓库地址"建立连接。接下来再使用git pull origin master 拉取远程master分支上的代码，修改代码之后依次使用如下方法：
git add .
git commit -m '你想要加的更新描述'
//首次提交需要使用 -u 参数
git push -u origin master
//之后不需要使用 -u 参数
git push origin master
对于上传分支，可能稍微麻烦些，主要是因为上传的远程分支看不见，一般容易出现如下报错信息:
先看看英文报错提示，我英语不太好，大概说的是这么一个意思，你现在的分支和master的代码有差异，但是你没有向你得先解决这个问题。构建如下情景：
今天星期六，你提交代码到你的个人分支；
明天星期日，你拉master，再次提交代码到你的个人分支，但是你上次提交的代码忘了提交 pr 合并到主分支；
这……，都是你写的代码，星期日的代码要是交上去了，你这星期六就白写了，所以也不要使用什么代码强推方法了，待我细细说来。
回归情景模拟，我们以master和下面的test-dev2为例，test-dev2现在就是你的分支了。
首先，为了保持master和你的个人分支一致，使用git init初始化，git pull origin master拉取远程分支，使用git push origin master:test-dev2,将代码推送到远程你的个人分支，由于master分支的权限为上下级，故而可以传成功。
接下来，我们遵循一个规则每次先拉master分支，然后再修改代码（这个规则为了确保每次修改前都是最新代码，防止别人提交了pr被接受了，修改了master分支）假设你今天写了代码day6.txt,第一次上传代码到你的test-dev2仓库，上传结果如下：
时间过得真快，转眼间来到了星期日，你还是遵循那个规则，先拉master，然后提交到你的个人分支，嘿嘿，果然报错如下：
不要问我为什么如此开心，因为知道了错误是怎么产生的，我们离成功就更进一步了。
现在，对于你的个人仓库而言，你就是pr管理者了，你需要友好处理这两天不一样的pr。
我们在使用git pull时，有的时候忘了设置分支，直接用git pull,出现如下报错：
你要是信的话，这个其实是一个提示，不是报错。说的是：没有为分支主机配置跟踪分支，或者分支不存在。要使分支跟踪远程分支调用，例如，git branch–将upstream设置为=origin/master。我们发现远程的分支其实都在可选参数里面，那我也就是说我们可以去拉test-dev2分支的代码，使用git pull origin test-dev2即可
接下来，手动合并星期六和星期天的代码，再次提交，果不其然上传成功。
最后，咱们再来反思一下，比较上述两种方法，git clone是将仓库下载下来了，.git是远程master分支里面的，拥有的权限更高，也就是不会出现上述reject报错了，而本地的init 得到的.git文件权限比较小，故而会报错，还是git clone 方法容易一些。学了第二种方法，下次别人报错，你就能给别人细细说来了，从原理上来教会别人，而不再是一句“我只会git clone,我就是这么用的”了。
好啦，现在，你删除先前没有被接受的pr,再提交一个新的pr就能下班了。芜湖起飞~ ^_^！
更多推荐
gitee将代码上传到远程分支仓库
发布评论