Git

windows上Git bash 查看log乱码?
https://segmentfault.com/q/1010000002463247

版本控制软件:
SVN:中央式 弊端:若中央服务器出现故障,则会影响所有的文件,恢复很难
Git:分布式 只要有一台OK,就没事

Git如何使用?
首先在GitHub注册一个账号,下载Cmder-full版,内部集成了git

在git中查看日志,如果日志过多,如何退出? q

Git中删除文件?
1.物理删除
直接在工作目录下删除文件,

2.使用git rm file命令删除文件

两者比较:
物理删除的话,只是在工作目录中删除了该文件,但没有同步快照到暂存中,所以此时不能直接提交,需要git add file,在commit;
而使用命令删除的会自动同步暂存,可以直接commit.

文件重命名?
1.在工作目录下直接重命名文件
Git会将这种操作看成是先将原文件删除,在新建了重命名后的文件.

2.使用git mv 旧文件名 新文件名

git中的重要概念:分支(branch)
为什么要有分支?
大型项目都是多人合作开发的,如果每个人写的代码都往master上提交,一般的公司都会有程序集成,会自动监视master上的代码变化,自动同步变化到生产环境中,这样会造成混乱.引入分支就是为了解决多人协同开发.例如:新建一个开发库分支DEV,每个人开发的代码都往这个分支上提交,现在这个分支上存的是A和B模块,测试库分支TEST上存的是C和D模块,Master上跑的是E,当A,B开发完成提交到DEV上后,TEST分支从DEV分支上合并A,B进行测试OK后,再将A,B,C,D一同Merge合并到Master上,这样提高了开发效率.

master分支

每次放到暂存区,就相当于进行一次快照,产生一个唯一的序列号,后面的快照都会合并前一个快照,master相当于一个指针,指到哪,就表示当前的版本是哪一个.

git开发常用命令:
1.合并代码:
将dev分支合并到release分支

git checkout release
git pull = git ffetch + git merge
git merge --no-ff dev
git push
git status
git diff
git add . 或git add *
git commit -m "注释"
git push 

关于git merge --no-ff和git merge的区别:
https://segmentfault.com/q/1010000002477106

关于git pull:
https://segmentfault.com/q/1010000011650575?sort=created

git查看、删除、重命名远程分支tag:
https://blog.zengrong.net/post/1746.html

git怎么回退到某个历史版本?
1.git checkout dev
2.git log 查看提交的历史 git reflog
3.git reset --hard 5d2651b9f76008b9f47a737454a3ffa4bbc95e1f
4.git push -f -u origin dev
执行以上脚本前 一定记得做个分支的备份，在回滚前，拉个新分支.
5d2651b9f76008b9f47a737454a3ffa4bbc95e1f一定得是 直接在dev分支上的直接提交记录编号，否则会回滚成其它分支的某个版本.

git stash 储藏当前修改
当前分支内容发生修改，这时候需要切换到其他分支工作，git会提示切换之前有两个选择：先commit或者stash当前分支修改的内容,如果不想commit,可以使用stash将修改储藏起来，等再切换回来时可以还原回以前修改的内容.
https://www.cnblogs.com/leyi/p/7705570.html
放弃最后一次的commit而回复到再上一次commit的指令：git reset --hard HEAD^

gitk-强悍的git图形化工具
https://my.oschina.net/davelet/blog/1846174

处理git bash中文乱码
git config --global core.quotepath false

git flow分支管理
1.总体分支管理图

• master分支：主分支，产品的功能全部实现后，最终在master分支对外发布，这个分支只能从uat分支合并（由管理员进行合并），不能在这个分支直接修改。
• dev_[version][requirementCode][beginDate]分支：开发分支，基于master分支克隆，产品的编码工作在此分支进行，[version]为版本号，[requirementCode]为需求代号,[beginDate]为开始开发时间.
• dev分支:与前端/H5联调环境对应的分支
• release分支:测试环境对应的分支
• uat:预生产环境对应的分支
• hotfix_[version][bug][beginDate]分支：Bug修复分支，基于master分支发布的里程碑Tag克隆，主要用于修复对外发布的分支，收到客户的Bug反馈后，在此分支进行修复，修复完毕后合并到master分支。本分支属于临时分支，目的实现后可删除分支, [version]为版本号，[bug]为需要修复的bug内容，[beginDate]为开始开发时间。

按照以上方案之后的实际开发流程将会如下：
假设当前master版本是v0.1.0,
开发阶段：现在要开发下一个版本，比如分段式需求，A程序员要就从master拉取一个分支dev_v0.2.0_ A339771_20180705进行编码的工作，开发完毕自测OK后要与前端联调，把dev_v0.2.0_A339771_20180705的代码合并到dev分支并发布服务；
测试阶段：联调ok后,合并dev_v0.2.0_ A339771_20180705分支到release, 进行发布部署，测试阶段有出现bug，需要在dev_v0.2.0_ A339771_20180705进行修改,修改后再同步合并到dev和release分支;
uat阶段: 测试ok后,合并dev_v0.2.0_ A339771_20180705分支到uat,发布再进行测试,同上;
上线阶段:uat测试稳定了，可以发布上线了,进行版本合并,把uat分支合并到master分支,并且打一个tag， v0.2.0，然后到tag对应的Excel文档新增一条记录(因为我们项目有多个服务order、pay。。。每个服务是一个git，为了方便查询最新tag，所以希望上线之后进行记录)。
线上Bug解决阶段：假如上线完之后，第二天线上出现bug，需要从master分支拉取一个新分支，命名规则为hotfix_ v0.2.1_amount_20180706 ，修改完之后合并到master分支，并且打一个tag， v0.2.1，然后到tag对应的Excel文档新增一条记录.

Tag版本制定规则：
Tag版本号由3位组成，主版本号、次版本号、修订版本号，上一级变动下一级要清零
版本号定修改规则：
主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目决定是否修改。
示意图如下：

Git提交注释规范，提交模板如下：
【版本号】V1.3.8.4
【变更类型】新增特性/Bug修改/优化处理/代码重构/其他
【代码描述】

分支管理:
https://www.sohu.com/a/226733625_355140

git-更改本地和远程分支的名称

git branch -m old_branch new_branch # Rename branch locally 
git push origin :old_branch # Delete the old branch 
git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote