开发环境之git:团队协做git工做流与经常使用命令

此篇文章只是一篇傻瓜式的,记录工做中比较规范且常见的一个git工做流须要用到的命令,让你能够快速的开始工做。而不是一些长篇大论的理论知识,若是你有用过sourcetree或者其它图形化工具,结合你正在使用的工具,敲这些命令,看图形化工具中的变化,对比思考这些命令可能会更容易吸取。html

1.基本配置

刚入职公司开始作项目拉代码,须要经历的第一件事。配置我的的用户名称和电子邮件地址(一般是公司邮件地址)git

1.1 配置用户名和邮箱

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

1.2 设置public key

首先须要在本地生成keygithub

ssh-keygen -t rsa -C "你的邮箱"

一路回车,接下来复制public keyshell

cat ~/.ssh/id_rsa.pub

固然也能够去系统里找到这个文件本身手动复制,
windows用户,文件通常在windows

C:\Users\Administrator\.ssh\id_rsa.pub

mac用户,文件在缓存

用户名\.ssh\id_rsa.pub

能够在命令行里输入ssh

open ~/.ssh

有可能你的[用户名]目录下只有[公共, 图片, 文稿, 下载, 音乐,影片] 等这类文件夹,你就能够同时按下 shift command . 三个键,就能够看到里面会有一个 .ssh 文件夹了。
还有可能你的文件夹目录甚至都没有[用户名]这一栏,能够按照 访达 --> 偏好设置 --> 边栏 中勾选你的用户名就行了。编辑器

扯远了,回到主题。复制好 .ssh 下的 id_rsa.pub 文件后,打开你的gitlab 或者 其它大家公司用的git仓库管理系统,将它添加到你的帐户上svn

右上角点击头像 --> 点击settings --> 点击 SSH KEYS --> 点击 ADD SSH KEYS --> 将获取的 id_rsa.pub 文件内容粘贴于此

2.开发阶段的实际场景与经常使用命令

2.1 若是是启动一个新项目,组长须要作什么?

// 2.1.1:新建gitlab仓库,复制ssh仓库地址
// 2.1.2:克隆项目到本地文件夹
git clone "复制的地址"
// 2.1.3:此时默认是在maser分支上,进到拉取的本地项目目录中去,将本地仓库与远程仓库关联起来。
git remote add origin '复制的地址'
// 2.1.4:推送本地master分支到远程master分支
git push -u origin master
// 2.1.5:新建一个本地dev分支,并切换到本地dev分支
git checkout -b dev
// 2.1.6:在此以前远程是没有dev分支的,须要推送本地dev分支到远程dev分支
git push -u origin dev

master分支未来控制着发布到线上的稳定版本代码,普通成员不能够对master分支进行操做,否则每一个组员改点东西,颇有可能把线上代码搞崩。组员们只能在dev分支上进行操做。工具

2.2 接下来组员们须要作什么

// 组员小智:
// 2.2.1 将组长建好的仓库克隆到本地
git clone "复制的地址"
// 2.2.2 默认在master分支上,须要检出远程dev分支到本地dev
git checkout -b dev origin/dev
// 2.2.3 不直接在本地dev分支上写代码,否则就跟svn没什么两样了,基于本地dev分支建一个本身的本地分支,名为xiaozhi
git checkout -b xiaozhi dev
// 2.2.4 此时,就切换到了本地xiaozhi分支上,开始写功能,好比task0001,写完后
git status
// 查看你本地作了哪些修改
git add '修改的文件名(包含目录)'
// 或者
git add *
// 来把你的修改添加到暂存区去,接下来提交代码到本地xiaozhi分支
git commit -m "task0001:基础布局功能"
// 2.2.5 建议每完成一个任务的其中一个小功能就重复一次2.2.4步骤,天天下班前至少要合并推送一次到dev分支。确保你的代码不能影响别人的运行,也不会跟最新的代码相差太远。首先,切换到本地dev分支
git checkout dev
// 2.2.6 拉取最新dev分支代码,可能在你写task0001的时候,别人提交过代码了
git pull
// 2.2.7 合并本地xiaozhi分支代码到本地dev分支
git merge xiaozhi
// 2.2.8 推送你改动的代码到远程dev分支
git push
// 2.2.9 切换到本地xiaozhi分支
git checkout xiaozhi
// 2.2.10 合并本地dev分支到本地xiaozhi分支
git merge dev
// 至此,你将你的改动推送到了远程,你的本地也是最新代码了,继续去作task0003。重复2.2.4-2.2.10步骤

...
...
...
// 当你在2.2.1步骤的时候,可能你的同事小狒也要开始作task0002,他在他的电脑上又是怎么操做的呢?
git clone '复制的地址'
git checkout -b dev origin/dev
git checkout -b xiaofei dev
git status
git commit -a -m "task0002: 基础布局功能"
git checkout dev
git pull
git merge xiaofei
git push
git checkout xiaofei
git merge dev

// 每一个组员除了基于dev分支新建的本地分支命名不同以外,其余基本同样。

2.3 此过程可能会遇到的问题

在执行 git pull 或者 git merge 操做的时候

2.3.1 若是出现这样的代码

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch。
# lines starting with "#" will be ignored, and an empty message aborts the commit

// 能够按 ESC 退出键,输入 :wq  而后敲回车就能够恢复正常,而后继续git push 便可

2.3.2 发现有冲突怎么办?

// 若是提示有冲突,在你的编辑器里看到代码是这样的

>>>>>> HEAD
// 从HEAD到下面的====之间的代码是你当前分支上的代码
function a () {
    console.log('a')
}
======
// 从======到下面的>>>>>之间的代码是你要合并过来的代码
function a () {
  console.log('aa')
}
>>>>>> xiaofei
// 须要小狒和小智商量,保留小智的仍是保留小狒的,仍是两我的的都要保留一部分。手动改好代码后,执行
git add '冲突的文件名'
git commit -m '解决冲突'
git push

2.3.2 如何放弃本地修改?

// 当小智在他的本地xiaozhi分支上加功能时,可能他开始没考虑全面,想把本地修改的内容都删掉从新来过。

// 当小智尚未 git add 缓存代码时
git checkout -- '想放弃修改的文件名(带路径)'
// 或者放弃全部文件的修改
git checkout .


// 当小智已经把想撤销修改的文件执行了 git add 的时候
git reset HEAD '想放弃修改的文件名(带路径)'
git checkout -- '想放弃修改的文件名(带路径)'


// 当小智已经把想撤销修改的文件不只git add还git commit的时候
git reset --hard HEAD^
// 能够用这条命令来恢复至上一次commit的状态,若是发现已经提交了好几回怎么办,噗,没忍住笑出了声。若是直接回退确定是能够的,可是这中间的几回commit可能又有你想要的代码,这个说实话,有点惨。说个比较实际的方案吧。把如今的代码文件夹先复制一份。再执行
git log
// 看看你想回退到哪次commit的状态,找到那次commit的版本号(记住关键的前几位就能够了),而后
git reset --hard e235a
// 而后再从复制的那份文件夹中去对比,看看哪些是你想要的,想要的就加进来。

3. 测试阶段的实际场景与经常使用命令

终于到了开发完成,要测试的时候了。此时,全部人各自对应的本地分支代码(xiaozhi分支,xiaofei分支)都应该和dev保存一致了。
其实就能够把release分支看成dev分支,只不过开始是你们都推送到dev分支上作开发,而如今是都推送到release分支上改bug。

// 组长:
git checkout -b release dev
git push -u origin release

// 组员小智:
git checkout -b release origin/release
git checkout xiaozhi
git status
git add *
git commit -m "bug0001:修复首页xxxx的问题"
git checkout release
git pull
git merge xiaozhi
git push
git checkout xiaozhi
git merge release
// 继续解决下一个bug

// 组员小狒
git checkout -b release origin/release
git checkout xiaofei
git status
git add *
git commit -m "bug0002:修复列表页的XXXX的问题"
git checkout release
git pull
git merge xiaofei
git push
git checkout xiaofei
git merge release
// 继续解决下一个bug


// 当全部测试提出的bug都解决完后,你们应该保证dev分支,release分支,各自的本地分支(xiaozhi,xiaofei)都同样
// 组长:
// 合并release分支到dev分支上
git checkout dev
git merge release
git push
// 合并release分支到master分支上并打上标签版本号
git checkout master
git merge release
git push
git tag -a v1.0.0 -m '1.0.0版本'
git push origin --tags

// 组员们继续写功能开始进行下一版本的产品迭代,重复2.2.4-2.2.10步骤

4. 上线后客户反馈有bug怎么办?

有可能当组员们已经在各自的本地分支(xiaozhi, xiaofei)上去作下一版本的开发的时候,客户反馈一些测试小姐姐们当时没有测出来的bug。此时你们确定不会直接去把dev分支再去合并到master分支了。

// 组长:
// 4.1.1 基于master分支新建一个hotfix001分支
git checkout -b hotfix001 master
// 4.1.2 与远程hotfix001分支关联起来
git push -u origin hotfix001

// 组长将这个重大而又紧急的任务指派给小智
// 组员小智:
// 4.1.3 检出远程分支hotfix001到本地分支hotfix001
git checkout -b hotfix001 origin/hotfix001
// 4.1.2 小智一顿牛逼操做以后
git commit -a -m "hotfix001: 解决线上xxxx的问题"
git push
// 4.1.3 测试经过后组长去拉取hotfix001的代码并合并回master分支
git checkout hotfix001
git pull
git checkout master
git merge hotfix001
git push
git tag -a v1.0.1 -m '1.0.1版本:修复XXXX等一系列的问题'
git push origin --tags
// 4.1.4 接下来判断这个线上的bug下一版本是否还要处理,若是这个功能还要的话,为了不下一版本出现一样的问题,那组长还须要把这个hotfix001分支合并到dev分支中去
git checkout dev
git pull
git merge hotfix001
git push
// 4.1.5 线上bug分支hotfix001完成了它光荣的使命,能够删除了
git branch -d hotfix001
git push origin --delete hotfix001

5.后话:

我也在用git图形化工具,好比sourcetree。相信不少人也在用,其实用命令行仍是不如sourcetree那么方便而强大的。好比在撤销修改的时候,sourceTree能够只撤销这个文件你所改动的某一部分,而git命令行只能对某一个文件的全部改动撤销修改(固然,多是我对git命令行操做还不那么深刻的缘故,可是我相信就算git命令行能作到,也远没有图形化工具那么方便)。

不过我以为我写这篇文章其实仍是有意义的,工做了这么久,几乎每天都会用到git,一些常见git命令都不懂也说不过去,对本身要求并不那么高,并非要强到什么均可以马上想到用什么git命令去解决,而此篇文章中工做流经常使用到的命令仍是要熟记于心的。

你们能够用本身的github帐号而且找一个小伙伴去建一个仓库模拟体验一下上述多人协做的过程,若是有问题能够一块儿交流下。

另外,你可能会感兴趣的一些点:

相关文章
相关标签/搜索