萌新(我)的Git备忘录

又是喜闻乐见的背景时间--最近也开始接触面试了，发现不少童鞋对git十分陌生，甚至听到git有点恐慌，不过这样无可厚非，毕竟若是是本身单干的话确实可能接触不到协做层面的情境。对的，好比说我

本文只适合我等萌新，大佬可能就不须要继续看下去啦，若是是帮忙纠正错误的话就十分欢迎~

本文会涉及到的内容--

• 刚进入新的工做群该用git干啥
• 开始接客接活以后改用git干啥
• 一块儿接客接活时该怎么保证安全(?)
• 小结

写在前头

仍是和我以前的风格同样，这里只可能出现业务型的干货，并不会在此过多的原理陈述(一是怕误人子弟，二是感受不必)，git做为一种工具，咱们能在工做中用得顺手便可。

注意：本文的开发机器为Mac，代码仓库为Gitlab

刚进入新的工做群该用git干啥

进入新公司或是加入新的工做群，最重要的事情固然是要拿到当前业务的代码，这是进行后续开发工做的基础。就咱们当前的开发状况来讲，咱们须要作如下几件事--

①注册帐号，与管理仓库的同事沟通，开通相关项目的权限

通常在这个时候，都会要求你们提供一串秘钥--本机的SSH Key，若是以前有在本机生成过SSH Key的话咱们能够在终端输入（若是没有的话建议使用搜索引擎查找生成SSH Key的相关教程）

cat ~/.ssh/id_rsa.pub
复制代码

这样终端便会显示一串秘钥，以后只需把秘钥告知同事便可，为何要作这件事呢？由于就算咱们有查看项目的权限，咱们的机器也没有将其克隆下来的权限，只有将咱们的SSH Key记录到gitlab中，咱们才能够克隆项目。

②克隆代码

进入相应的目录
cd my_project
在本目录下将远端代码克隆到本地
git clone ssh://xxx/xx/xx.git
复制代码

开始接客接活以后改用git干啥

①建立本身的开发分支

正常状况下，咱们是不会在master分支下进行开发的，这既不安全也不优雅(通常也不会容许非管理员在master分支提交代码)。因此咱们就须要建立一个属于本身的开发分支，它与master的代码时刻保持同步，提交代码时merge到master分支便可。

git branch 
//确认在master分支
git checkout -b xxx(自定义分支名)
//从所在分支，checkout出一个新的分支，这个新分支拥有所在分支的全部代码
git push -u origin xxx 
// 将本地分支推往远程仓库
复制代码

输入这三行以后，咱们就拥有了属于本身的分支，由于这个分支是从master切出来的，因此它的代码与master彻底一致，以后咱们在此分支开发便可。

②管理本身的源码

在IDE里面愉悦的搬砖一段时间以后，要记得劳逸结合！咱们最好要养成定时提交代码的习惯，最好不要码了一成天以后才想起来要提交代码，就我我的而言，在完成需求中的某个小需求时我便会提交或推送一次代码。

git add .  or  git add /xxx/...
//将本次改动所有加入缓存区
git commit -m ""  or  git commit
//将代码提交到本地代码库，并附带相关注释
复制代码

③时刻同步master分支

维持一个项目的稳定性，其中一个要素就是保证代码的纯净，因此咱们须要保证咱们的开发分支须要时刻与master保持同步，咱们团队采用的rebase的方案。

git fetch origin
// 发现远程仓库最新的代码
git rebase origin/master
//同步远程仓库master分支
git push
//将你的代码推到远程仓库
or
git push -f origin xxx
//若是没法push则能够选择下面这个方式**(前提是要确保本地的代码是绝对的完整)**
复制代码

在这里咱们须要注意的是要记得fetch远端的最新代码，而后才进行rebase。紧接着就是rebase时对冲突的应对--

git fetch origin
// 发现远程仓库最新的代码
git rebase origin/master
//同步远程仓库master分支
----conflict----
//rebase时发生冲突
git status
//定位冲突文件
//...处理冲突...
git add .
//提交冲突处理到缓存区，必定不能commit
git rebase --continue
//继续rebase
or
//若是没法处理冲突则退出rebase复原代码
git rebase --abort
复制代码

④提交本身的第一个PR

为了保证代码的纯净，最理想的方式是只有一个有权限的管理员进行分支与master之间的合并，这里用到的就是咱们常说的PR(Pull Request)，简单来讲，就是向项目管理员提出一个merge的请求，管理员赞成以后则会将咱们的代码合并到master。

git fetch origin
git rebase origin/master
git push //...ok
复制代码

将本地改动推送到远端代码库后，咱们须要进入gitlab相应的项目，建立PR(图中Merge Request选项，也就是Github中的Pull Request)

确认相关改动无误后咱们能够建立PR等待管理员review，建立好以后又有改动怎么办？不要紧的，咱们只须要按照老方法将代码推送到服务器，PR内容会自动更新至最新。

一块儿接客接活时该怎么保证安全

背景--有一个比较大的需求，须要两我的共同开发，而且须要这个需求最终共同上线。

对于我来讲，这种状况不太常见，可是也想过相关的方案，在这里以前的rebase方案就不太够用了，须要区分主从分支。假设进行开发的童鞋为A和B--

// A童鞋
// on master
git checkout -b A
git push -u origin A

// B童鞋
git fetch origin
git checkout A
git checkout -b B
git push -u origin B

// 开发中...
// A童鞋
git add .
git commit
git fetch origin
git rebase origin/master
git push

// B童鞋
git add .
git commit
git fetch origin
git rebase origin/A
git push
复制代码

这样开发可使得AB两位的代码都能时刻与master分支保持同步，而且B还能够得到A最新的开发代码，在共同开发某样功能的时候应该会十分有用。最后B提交一个PR便可把两人的代码合并，再由A发起合并到master的PR便可。

小结

其实这就是我我的开发时候的备忘录，一些基本开发流程仍是有的，若是有特殊需求的话，能够上网找找Git相关的教程~在此不会过多的涉猎。