TortoiseGit操作

git规范

版本管理中必须遵循的规则

• 每个提交必须包含清晰，有意义的Commit Message，零碎的提交在push前适当使用rebase整理
• 开发完成后只允许push到个人分支，通过merge request合并到master-*，develop-*，feature-*，hotfix-*，不允许直接push到master-*，develop-*，feature-*，hotfix-*
• 每次代码变动均需要包括二次检查，即push前自测，merge的交叉检查
• 测试环境部署只能使用master-*，develop-*，feature-*，hotfix-*分支，上线部署只能使用master-*分支，镜像tag和版本库tag一一对应
• 冲突前置原则，通过良好的设计和合理的工作安排，能在个人分支解决的冲突不要蔓延feature-*，能在feature-*解决的不延伸到master

分支说明

master*

功能：存储正式发布的历史

限制：发布前由团队负责人合并，其他成员没有合并权限

develop

功能：功能集成，测试

限制：测试前从feature合并，可随时合并，也可以限制经过pull request来合并

feature-*

功能：每个功能的独立分支，该功能的修改都在这个分支完成，然后合并到develop测试

限制：上线后删除

hotfix-*

功能：修复线上bug的临时分支

限制：完成后合并到master和deveop然后删除

用户名-*

功能：代码开发完成的推送服务端的分支

命名规则：用户名-目标分支，例：zhangsan-feature-*

Commit Message参考规范

message规范

每次提交，Commit message 都包括三个部分：type/scope/subject

格式为：<type>(<scope>): <subject>

type

用于说明 commit 的类别，只允许使用下面7个标识。

• feat：新功能（feature）

• fix：修补bug

• docs：文档（documentation）

• style： 格式（不影响代码运行的变动）

• refactor：重构（即不是新增功能，也不是修改bug的代码变动）

• test：增加测试

• chore：构建过程或辅助工具的变动

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

例如在Angular，可以是$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等。

如果你的修改影响了不止一个scope，你可以使用*代替。

subject

subject是 commit 目的的简短描述，不超过50个字符。

TortoiseGit操作

项目设置多个远端库

克隆项目的dev分支

也可以切换分支

重置到某个版本

git reset --hard

 重置到指定的版本

 新增的文件添加到忽略列表，不是.gitignore中的忽略列表

Git 分支操作命令

#查看远程分支
git branch -r 

#查看本地分支
git branch 

#切换至某分支
git checkout master

#把其他某个分支，合并入当前分支.
git merge branchName

#删除本地dev分支
git branch -D dev

专业的分支管理

apt-get install git-flow

初始化: git flow init

开始新Feature: git flow feature start MYFEATURE

Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE

获取Publish的Feature: git flow feature pull origin MYFEATURE

完成一个Feature: git flow feature finish MYFEATURE 分支的内容就会合并到develop，并且删除feature/name分支

避免git clone和push时每次都需要输入用户名和密码

//git remote add origin https://username:password@xxx.git 
git clone https://username:password@xxx.git

Git源地址

#查看源地址
git remote -v

#替换地址
git remote set-url origin https://xxx@github.org/XX.git

#添加源
git remote add other https://xxx@github.org/XX.git 

#删除源
git remote remove other

#拉取指定源的master分支
git pull --no-rebase other master

#推送 git pull 源 本地分支:远端分支
git push origin dev:dev

Git-将指定文件回退到指定版本

1.首先查看文件的历史版本。

git log /path/to/file

 2.找到你想要还原的版本。如 

commit 052c0233bcaef35bbf6e6ebd43bfd6a648e3d93b 
Author: panww <panww@gmail.com> 
Date: Wed Nov 8 11:48:31 2017 +0800 

 3. 将文件还原到你想要还原的版本。$ git checkout ${commit} /path/to/file。即

$ git checkout 052c0233bcaef35bbf6e6ebd43bfd6a648e3d93b /path/to/file

查看状态（冲突文件 未提交 修改列表）
 

git status

还原本地修改

git checkout .
git checkout a.js

git push --all 当遇到这种情况就是不管是否存在对应的远程分支，将本地的所有分支都推送到远程主机，这时需要 -all 选项
git push --tags 不会推送分支，如果一定要推送标签的话那么可以使用这个命令

如何合并多次提交纪录
每一次功能开发， 对多个 commit 进行合并处理。
这时候就需要用到 git rebase -i 了。这个命令没有太难，不常用可能源于不熟悉，所以我们来通过示例学习一下。

git commit –amend
在使用git作为版本控制的时候，偶尔会出现这种情况：对当前的修改用git commit -m'xxx'做一次commit，并记录一些commit log。但是随即又因为某些原因对工程做了修改，而这次修改逻辑上属于上次的commit的内容，此时再提交一些commit显然不合适，这时候我们需要有一种命令能将本次修改的内容合并到上一次的commit中，这样本次的修改和上一次的commit中的修改就逻辑上属于同一个commit了。

Git 中的stash功能

stash可以把当前工作现场“保存”起来，等以后恢复现场后继续工作

当你的开发进行到一半,但是代码还不想进行提交 ,然后需要同步去关联远端代码时.如果你本地的代码和远端代码没有冲突时,可以直接通过git pull解决.但是如果可能发生冲突怎么办.直接git pull会拒绝覆盖当前的修改.遇到这种情况,需要先保存本地的代码,进行git pull,然后再pop出本地代码

git stash save "临时"     #添加带备注的stash
git stash list            #缓存的列表
git pull 
git stash drop stash@{0}  #删除单个缓存
git stash apply           #与git stash pop相似，但他不会在堆栈中删除这条缓存，适合在多个分支中进行缓存应用

解决git revert后再次merge代码丢失问题

核心思想就是对 revert 的那次提交记录再次进行 revert（有点像负负得正的意思），下面开始实验。

 然后切换回 dev 分支，将revert_tmp 这个分支 merge 到 dev 分支上。

# 切换到master分支
git checkout master
git pull
# 基于master拉出一个分支 revert_tmp
git checkout -b revert_tmp

# 将之前git revert那次commit再次revert（commit号从git log可以查到）
git revert f5c3b544164eec662ea6914d6bd19aedf46874f8
git checkout dev
git merge revert_tmp
git commit -m "revert"
git push

将 dev 分支推送到远程后，重新提交对 master 的 merge 申请