git教程

GIT VS SVN

对比项	SVN	GIT
核心	集中式存储	分布式存储
网络	必须在线	可离线
分支操作	仅简单分支	对分支功能支持好
本地仓库	无	有
操作	简单	复杂
锁	支持乐观锁和悲观锁	不支持悲观锁
权限设置	权限功能强大	权限功能弱,只能设置项目读写权限

SVN的特点是简单，只是需要一个放代码的地方时用是OK的。
Git的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(这应该算是开发者最关心的地方)。

git安装

1. 下载git工具,链接地址: 官网地址
2. 安装git工具后可以使用git命令行,启动命令行工具gitbash.exe
3. 如果不习惯命令行可以使用TortoiseGit,链接地址:官方下载

git配置

1. 运行gitbash.exe,执行命令生成公有密钥
   ssh-keygen -t rsa -C “你的邮箱”

2. 打开C:\Users\当前用户名\.ssh\id_ras.pub,复制密钥,密钥格式如下

   ssh-rsa
   AAAAB3NzaC1yc2EAAAADAQABAAABAQDUKeA5sQjEA7ygmLHCdeHdLDGjQIAH19Twa
   HMRYqPbkbMI5h9qK8s86R5nk6pPB0Lm//nmrJkinKYyBUMrOitJXR9qeiS/yFrv/
   +5ZFD3ZMj7azD8n36Zmv1HnycjKjEwIYem80hn44wv7BTUbMCv1ocDD0Fh9oaPYzq4
   WcfahoLOOT9OLdVQhOot2f3NFOImv+B9EKH92rLJdPk90tTEeWDvOnu0lwfui6VU
   KOZeIv+D0nwI5XgrQOf/Vcj87y6Tkzb/iFPG7o1X0/hoFL4v9O83OTmAYFkB1sbq
   NwyAKxiZHtwCBnYIm9z+LpmZ9L7R1kxauyEjwzS9jVc2M
   [email protected]

3. 登录gitlab : 目前都使用标准登录方式登录
   

4. 进入个人设置页面
   

5. 添加公有密钥
   

6. 添加完成后,后续代码操作就无需输入帐号密码.
   GITHUB和码云的公有密钥操作也可以使用相同公有密钥,达到相同的效果

命令

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标签是永久的,一般标签为版本号
  更多命令自行百度

系统管理

帐号管理

1. 除管理员外的所有帐号必须为工号
2. 只有root用户能创建项目

##分支管理

分支分类

• 长期分支
  • master 主分支
    1. 负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。
    2. 必须是 Protected， 仅限项目 Owner 提交或合并
  • develop 开发分支
    该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建
• 短期分支
  • release/{version} 发布分支
    1. 用于代码上线准备，该分支从develop分支创建
    2. 该分支的最新版本与测试环境保持一致
    3. 测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。
  • feature/JIRA_ID* 特性（功能）分支
    1. 用于开发新的功能，该分支从developer分支创建
    2. 不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。
  • bugfix/JIRA_ID* bug修复分支
    1. 用于修复不紧急的bug，从developer分支创建
    2. 普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。
  • hotfix/JIRA_ID* 紧急bug修复分支
    1. 该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug
    2. 修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支。

分支步骤

1. 项目负责人 从developer分支创建当前待发布的分支，如release/20180921
2. 开发人员 更新远程分支列表
   git remote update origin --prune
3. 开发人员 下载远程分支并创建对应本地分支
   git checkout -b release/20180921
4. 开发人员 对本地分支进行代码修改
5. 开发人员 add代码
   git add 文件名
6. 开发人员 提交代码
   git commit -m "提交说明备注"
7. 开发人员 push代码至服务器
   git push origin release/20180921:release/20180921 正常提交
   git push origin release/20180921:release/20180921 -f 强制提交:如有冲突,视情况进行强制提交
8. 项目负责人 合并代码并部署发布服务
9. 测试人员 测试,并记录BUG
10. 开发人员 根据已提交的 issue 创建对应的开发本地分支
    git checkout -b bugfix/1 release/20180921
11. 开发人员 对本地分支bugfix/1进行代码修改
12. 开发人员 add及提交代码(与第5步,第6步相同)
13. 开发人员 切换本地分支至release/20180921
git checkout release/20180921
14. 开发人员 将bugfix/1分支合并至release/20180921
git merge bugfix/1
15. 开发人员 push代码至服务器
    git push origin release/20180921:release/20180921
16. 测试人员 测试全部通过后，发起将release/1.0合master的Merge Request给项目负责人，
17. 项目 Owner 合并代码并打标签v1.0，而后才可发布上线。
    git tag 1.0

无测试参与的项目
比如开发公共库或中间服务的项目，这种情况下，可以不拉 release分支，而直接在 master上拉 issue分支，但Merge Request的步骤不能缺少。

注意:合并后的分支应删除掉

如何用 Gitlab 做团队内的 Code Review

基于分支的代码 Review

1. 新建 Issue (无论是 bug 还是 feature), 描述背景或问题,
2. 本地创建分支 issue#123 (123是 issue 的 ID), 围绕关联 issue 进行 program -> commit -> push,
3. 新建 Merge Request 从 issue#123 到 master, 并指派给项目 Owner (或合适 Reviewer) ,
4. 被指派人完成代码审查后， 执行代码合并, 同时删除分支 issue#123 .

多人 Review

1. 提交 Merge Request 后， 被指派人可通过 @someone 邀请一个或多个额外的 Reviewer （它们会收到邮件通知）
2. 被邀请的 Reviewer 看过代码后， 可回复:thumbsup:或+1表示通过， 反之给出修改建议。

Protect Branch

为了避免意外的代码提交或合并， 项目 Owner 或 Master 可以在项目 Settings -> Protected branches 添加受保护的分支，进而引导代码提交是基于 Merge Request 的形式经过 review 之后才合并到目标分支上。