文章目录
GIT VS SVN
对比项 | SVN | GIT |
---|---|---|
核心 | 集中式存储 | 分布式存储 |
网络 | 必须在线 | 可离线 |
分支操作 | 仅简单分支 | 对分支功能支持好 |
本地仓库 | 无 | 有 |
操作 | 简单 | 复杂 |
锁 | 支持乐观锁和悲观锁 | 不支持悲观锁 |
权限设置 | 权限功能强大 | 权限功能弱,只能设置项目读写权限 |
SVN的特点是简单,只是需要一个放代码的地方时用是OK的。
Git的特点版本控制可以不依赖网络做任何事情,对分支和合并有更好的支持(这应该算是开发者最关心的地方)。
git安装
git配置
-
运行
gitbash.exe
,执行命令生成公有密钥
ssh-keygen -t rsa -C “你的邮箱” -
打开
C:\Users\当前用户名\.ssh\id_ras.pub
,复制密钥,密钥格式如下ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDUKeA5sQjEA7ygmLHCdeHdLDGjQIAH19Twa
HMRYqPbkbMI5h9qK8s86R5nk6pPB0Lm//nmrJkinKYyBUMrOitJXR9qeiS/yFrv/
+5ZFD3ZMj7azD8n36Zmv1HnycjKjEwIYem80hn44wv7BTUbMCv1ocDD0Fh9oaPYzq4
WcfahoLOOT9OLdVQhOot2f3NFOImv+B9EKH92rLJdPk90tTEeWDvOnu0lwfui6VU
KOZeIv+D0nwI5XgrQOf/Vcj87y6Tkzb/iFPG7o1X0/hoFL4v9O83OTmAYFkB1sbq
NwyAKxiZHtwCBnYIm9z+LpmZ9L7R1kxauyEjwzS9jVc2M
xuming@linshimuye.com -
登录gitlab : 目前都使用标准登录方式登录
-
进入个人设置页面
-
添加公有密钥
命令
TortoiseGit的使用不在本文档中描述
基础命令
初始化目录
- git init
在本地新建一个repo,进入一个项目目录,执行git init,会初始化一个repo,并在当前文件夹下创建一个.git文件夹.
2.获取代码
- git clone [url]
获取一个url对应的远程Git repo
, 创建一个local copy.clone下来的repo会以url最后一个斜线后面的名称命名,创建一个文件夹,如果想要指定特定的名称,可以git clone [url] newname指定
. - git fetch
可以git fetch [alias]
取某一个远程repo,也可以git fetch --all
取到全部repo
fetch将会取到所有你本地没有的数据,所有取下来的分支可以被叫做remote branches,它们和本地分支一样(可以看diff,log等,也可以merge到其他分支),但是Git不允许你checkout到它们. - git pull
git pull
会首先执行git fetch
,然后执行git merge FETCH_HEAD
,把取来的分支的head merge到当前分支.这个merge操作会产生一个新的commit.
如果使用–rebase参数,它会执行git rebase
来取代原来的git merge
.
tips:git clone 在第一次获取代码时使用,且不能有同名的文件夹;代码更新使用git fetch ,尽量少用git pull
合并代码
- git rebase 强烈,强烈,强烈,推荐使用
在fetch之后,执行此命令可更新为最新代码,此方式变基,使版本树更清晰 - git merge FETCH_HEAD
在fetch之后,执行此命令可更新为最新代码 - git merge 本地分支名
将指定本地分支合并至当前分支,此命令之后,需要执行删除本地分支操作git branch -d 本地分支名
提交代码
- git add 文件/文件夹
在提交之前,需要将新文件或更新后的文件提交到Git的暂存区(staging area). - git rm 文件/文件夹
删除更改. - git commit -m "提交说明"
Git的暂存区(staging area)的待更新文件,提交至本地仓库.
- git push
将本地版本库HEAD区更新文件提交至服务器 - git push 远程分支 本地分支
将本地分支更新文件push至远程分支
分支命令
- git branch
列出本地所有分支,当前分支会被星号标示出 - git branch -v
可以看见每一个分支的最后一次提交 - git branch -a
查看所有本地分支和远程分支 - git branch 分支名
创建一个新的分支(当你用这种方式创建分支的时候,分支是基于你的上一次提交建立的). - git branch -d 分支名
删除一个分支 git checkout 分支名
切换至所选分支- git checkout -b origin/远程分支名
创建与远程分支名相同的分支并切换 - git checkout -b 本地分支名xxx origin/远程分支名yyy
创建本地分支xxx,关联远程分支yyy,并切换至本地分支yyy
git更新分支命令
- git remote update
跟新远程分支列表,不会删除本地已存在,但
服务器已删除分支 - git remote update origin --prune
同步远程分支列表,与服务器分支列表相同,如果你的remote branch不是在origin下,按你得把origin换成你的名字。
git日志
- git log
查看git记录 - git log -p FETCH_HEAD
查看FETCH_HEAD日志,一般在fetch之后查看.红色字体为删除,绿色字体为新增
git打标签
- git tag 标签
git标签是永久的,一般标签为版本号
更多命令自行百度
系统管理
帐号管理
- 除
管理员
外的所有帐号
必须为工号 - 只有
root
用户能创建项目
##分支管理
分支分类
- 长期分支
- master
主分支
- 负责记录上线版本的迭代,该分支代码与线上代码是完全一致的。
- 必须是 Protected, 仅限项目 Owner 提交或合并
- develop
开发分支
该分支记录相对稳定的版本,所有的feature分支和bugfix分支都从该分支创建
- master
- 短期分支
- release/{version}
发布分支
- 用于代码上线准备,该分支从develop分支创建
- 该分支的最新版本与测试环境保持一致
- 测试过程中发现bug需要开发人员在该release分支上进行bug修复,所有bug修复完后,在上线之前,需要合并该release分支到master分支和develop分支。
- feature/JIRA_ID*
特性(功能)分支
- 用于开发新的功能,该分支从developer分支创建
- 不同的功能创建不同的功能分支,功能分支开发完成并自测通过之后,需要合并到 develop 分支,之后删除该分支。
- bugfix/JIRA_ID*
bug修复分支
- 用于修复不紧急的bug,从developer分支创建
- 普通bug均需要创建bugfix分支开发,开发完成自测没问题后合并到 develop 分支后,删除该分支。
- hotfix/JIRA_ID*
紧急bug修复分支
- 该分支只有在紧急情况下使用,从master分支创建,用于紧急修复线上bug
- 修复完成后,需要合并该分支到master分支以便上线,同时需要再合并到develop分支。
- release/{version}
分支步骤
项目负责人
从developer分支创建当前待发布的分支,如release/20180921开发人员
更新远程分支列表
git remote update origin --prune
开发人员
下载远程分支并创建对应本地分支
git checkout -b release/20180921
开发人员
对本地分支进行代码修改开发人员
add代码
git add 文件名
开发人员
提交代码
git commit -m "提交说明备注"
开发人员
push代码至服务器
git push origin release/20180921:release/20180921
正常提交
git push origin release/20180921:release/20180921 -f
强制提交:如有冲突,视情况进行强制提交项目负责人
合并代码并部署发布服务测试人员
测试,并记录BUG开发人员
根据已提交的 issue 创建对应的开发本地分支
git checkout -b bugfix/1 release/20180921
开发人员
对本地分支bugfix/1
进行代码修改开发人员
add及提交代码(与第5步,第6步相同)开发人员
切换本地分支至release/20180921
git checkout release/20180921
开发人员
将bugfix/1
分支合并至release/20180921
git merge bugfix/1
开发人员
push代码至服务器
git push origin release/20180921:release/20180921
测试人员
测试全部通过后,发起将release/1.0合master的Merge Request给项目负责人
,- 项目 Owner 合并代码并打标签v1.0,而后才可发布上线。
git tag 1.0
无测试参与的项目
比如开发公共库或中间服务的项目,这种情况下,可以不拉 release分支,而直接在 master上拉 issue分支,但Merge Request的步骤不能缺少。
注意:合并后的分支应删除掉
如何用 Gitlab 做团队内的 Code Review
基于分支的代码 Review
- 新建 Issue (无论是 bug 还是 feature), 描述背景或问题,
- 本地创建分支
issue#123
(123
是 issue 的 ID), 围绕关联 issue 进行program -> commit -> push
, - 新建 Merge Request 从
issue#123
到master
, 并指派给项目 Owner (或合适 Reviewer) , - 被指派人完成代码审查后, 执行代码合并, 同时删除分支
issue#123
.
多人 Review
- 提交 Merge Request 后, 被指派人可通过
@someone
邀请一个或多个额外的 Reviewer (它们会收到邮件通知) - 被邀请的 Reviewer 看过代码后, 可回复
:thumbsup
:或+1
表示通过, 反之给出修改建议。
Protect Branch
为了避免意外的代码提交或合并, 项目 Owner 或 Master 可以在项目 Settings -> Protected branches
添加受保护的分支,进而引导代码提交是基于 Merge Request
的形式经过 review
之后才合并到目标分支上。