Git

Git图解

    

　　

常用示例

新项目上传到远程仓库：
    先在gitlab上创建一个仓库,然后把小组内的成员都拉进来,给他们分配dev权限,把master锁的机制打开
    git init    # 初始化git仓库
    git remote add origin https://github.com/a877252372/wwwww.git    # 添加远程仓库
    git add .
    git commit -m "第一次提交"
    git push -u origin master

    
多人协作上传代码到远程仓库：
    git add .
    git commit -m "我的代码"
    git push origin master    # 如果成功,完美;如果失败,进行如下操作
    git pull origin master
    根据git提示,手动解决冲突
    git add .
    git commit -m "我的代码&解决冲突"
    git push origin master
    

创建与合并分支:
    git checkout -b dev
    git branch  # 查看当前分支
    在dev分支上开发开发完进行以下步骤
    git add .
    git commit -m "我在dev上改的代码"
    git checkout master
    git merge dev  # 把dev上的代码合并到master上,
    (git merge --no-ff -m "merge with no-ff" dev  # 请注意--no-ff参数，表示禁用Fast forward
     因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。)
    有冲突手动解决冲突
    git add .
    git commit -m "添加新功能"
    git push origin master


开发代号为Vulcan的新功能,该功能计划用于下一版:
    git checkout -b feature-vulcan
    git checkout dev
    git merge feature-vulcan


查看分支日志：
    git log --pretty=oneline
    git log --graph --pretty=oneline
    git log --graph --pretty=oneline --abbrev-commit

    
版本回退：
    git log --pretty=oneline
    git reset HEAD^  # 上一个版本就是HEAD^，上上一个版本就是HEAD^^,只恢复本地,没啥用
    git revert {commitId}  # 工作中不用reset用revert，直接就会把远程仓库的版本也回退掉，不需要自己再有额外的操作
    git reflog
    git revert {commitId}

提交到远程其他分支

场景:
从master分支拉了一份代码，做了一些修改，但是不想提交到branchA分支，想新建一个分支branchB保存代码。
git add .
git commit -m "做了修改"
git push origin master:new_branch  
#仓库中原本没有branchB，提交后会生成新分支branchB，并将本地基于branchA修改的代码提交到branchB中
git checkout -b new_branch origin/new_branch
#本地仓库中也没有这个分支需要新建

git commit后,用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别：

下面是一个通常的git diff的输出结果：

$ git diff README.md
diff --git a/README.md b/README.md
index d29ab50..7e42b29 100644
--- a/README.md
+++ b/README.md
@@ -37,3 +37,4 @@
 You can get it using command `hostname` in your remote robot:
 $ hostname
+Enjoy it!
第一部分表示为你使用的git格式的diff：

diff --git a/README.md b/README.md
第二部分表示两个版本的git哈希值（index区域的d29ab50对象，与工作目录区域的7e42b29对象进行比较），最后的六位数字是对象的模式（普通文件，644权限）。

index d29ab50..7e42b29 100644
第三部分表示进行比较的两个文件：

--- a/README.md
+++ b/README.md
"---"表示变动前的版本，"+++"表示变动后的版本。

第四部分表示变动的位置，用两个@作为起首和结束：

@@ -37,3 +37,4 @@
前面的"-37,3"分成三个部分：减号表示第一个文件（即index区域的d29ab50对象），"37"表示第37行，"3"表示连续3行。合在一起，就表示下面是第一个文件从第37行开始的连续3行。同样的，"+37,4"表示变动后，成为第二个文件从第37行开始的连续4行。

最后一部分是具体的差异部分：

You can get it using command `hostname` in your remote robot:
 $ hostname
+Enjoy it!

Git规范

1. 所有二进制文件不要提交到仓库
2. 尽量微小化提交，不要修改了一堆问题再提交。
3. 后期逐步进行代码仓库功能规划和BUG记录，提交代码与其绑定。
4. commit信息规范：
所有的提交信息用现在时语气而不是完成时语气，例如使用“增加(add)…，修改(fix)…，解决(solve)…”，而不是“改好了(fixed)…，解决了(solved)…, 增加了(added)…，修改了(revised)…”。
提交的信息，尽量用英语表述，如果实在用英语表述不清楚的，可以用中文。
第一行是commit信息概述，控制50个字符（或25个汉字）以内。结尾统一都不要使用句号，因为后面通常都会有详细描述。

在第一行的commit信息中，可以加一些前缀，它可以帮助我们对commit进行分类，同时当我们使用git log来检查，或者查找某一个提交的，非常有用。可用的前缀有：
1) ADD：增加新的功能，新的单元测试等。
2) REV：修改代码的实现，增强了代码的健壮性，重构代码，优化一些功能的细节等
3) FIX：修复某一个bug。
4) DEL：删除一些文件。
5) FMT：修改主要是提高代码的规范，格式化原来的代码，例如去掉一些空格、空行，将Tab替换成空格等，没有修改代码的功能。

针对上述的几个前缀，举几个例子：
1) [REV] Update all app download qcode picture
2) [FIX] Fix sms urls that can not access
3) [ADD] Add user register account by email
4) [DEL] Delete the duplicate template file
5) [FMT] Format the evaluate module code

第二行是空行，一些处理工具会把第一行作为邮件的标题，其它的作为正文，所以需要一个空行来区分标题和正文。如果后面没有信息详述，此空行可以省略。

第三行开始是commit 信息详述，每行的长度控制在 72个字符(或 36个汉字)之内。该信息应该要保证足够的详细，开发人员看了之后可以可以在合理的时间内实现几乎相同的补丁程序。
若有bug跟踪软件，对于每一次的bug修复的提交，commit信息中都应该包含bug的ID，commit信息分为两部分，第一部分是提交的概述，第二部分是对该次bug提交的详细描述，例如：
[FIX] bugfix <bug_id>

Bug <bug_id> - Something goes wrong