Git
-
git是版本控制软件，一般用来做代码版本控制
-
github是一个免费版本控制仓库是国内外很多开源项目的集中地，其本体是一个git服务器
-
Git初始化操作
git init 初始化仓库 git status 查看当前仓库的状态 git add . 将改动的文件加到暂存区 git commit -m 把暂存区的内容移往版本库（repository） git commit --amend -m'描述' 修改最近一次提交commit信息 git commit --amend --no-edit 把某个改动并入最近一次的commit
-
添加git相关信息
git config --global user.email "123123@163.com" git config --global user.name "JeeyWu"
-
git日志操作
git log 查看提交记录 git log 文件名 查看文件相关的提交记录 git log --author="JeeyWu" git log --grep="新增用户查询列表接口" 查找commit信息中是否含有某些关键字
-
.gitignore文件(忽略被git管理的文件)
-
添加远程仓库
git remote add <name><url> 本地仓库和远端仓库关联 git remote add origin https://gitee.com/t7uf7tu/one12312.git git push -u origin "master" 把本地仓库主分支推送到远程仓库主分支 git push -u origin "master"
-
从远程仓库拉取代码
git clone <url>
-
git拉取和推送
git push origin master 推送到远端仓库 git pull origin master 把远端最新的改动拉取下来
-
git 分支操作
git branch 查看分支 git branch Jeeny_wu 创建分支 git branch -m old-name new-name 修改分支的名字 git branch -d 分支名 删除本地分支 git push origin -delete 分支名 删除远端的分支 git checkout 分支名 切换分支 git checkout -b 分支名 切换分支或者切换创建分支 分支合并 master merge xiaohong 快转模式 （指向同一个commit）
-
ort策略
同时并行开发两个任务task-a和task-b，task-a、task-b和master分支指向同一个commit。切换到task-a分支提交一些修改并commit，之后切换到task-b分支提交一些修改并commit。此时无论是task-a合并taskb，亦或是task-b合并task-a，在这种情况下，git会生成一个额外的commit，这个commit会指向两个commit(task-a和task-b的commit)，明确地标记是来自哪两个分支
-
rebase变基
a分支和b分支都是从master分出去的，且各自做了改动并commit。a和b都是从master分出来的，它们的base都是master. 切换到a分支，执行git rebase b命令。意思是使用b分支作为a分支的新的参考基准。 rebase合并方式和merge方式的区别:使用rebase方式合并分支，git不会在做出一个专门用来合并的commit.
-
版本回退
git reset commit 识别码 --hard 回退版本 （使用git reflog命令 查看之前的commit识别码） git reflog 查看之前的commit识别码
-
合并冲突
-
不是改到同一个文件就一定会发生冲突，但改到同行就会出现冲突 无论是使用merge还是使用rebase进行合并，都有可能产生冲突
-
git flow工作流
简介:Gitflow工作流程围绕项目发布定义了严格的分支模型，它为管理更大规模的项目提供了坚实的框架。除了用于功能开发的分支，它还使用独立的分支进行发布前的准备、记录以及后期维护
用于记录历史的分支:Gitflow使用两个分支来记录项目开发的历史，而不是使用单一的master分支。在Gitflow流程中，master只是用于保存官方的发布历而develop分支才是用于集成各种功能开发的分史，支。使用版本号为master上的所有提交打标签(tag)也很方便。
用于功能开发的分支:每一个新功能的开发都应该名自使用独立的分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库。但是，在创建新的功能开发分支时，父分支应该选择develop(而不是master)。当功能开发完成时，改动的代码应该被合并(merge)到develop分支。功能开发永远不应该直接牵扯到master。
用于功能开发的分支:每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库。但是，在创建新的功能开发分支时，父分支应该选择develop(而不是master)。当功能开发完成时，改动的代码应该被合并(merge)到develop分支。功能开发永远不应该直接牵扯到master。
用于发布的分支:一旦develop分支积聚了足够多的新功能(或者预定的发布日期临近了)，你可以基于develop分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加新的功能--在这个分支上只能修复bug做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候这个分支会被合并入master，并且用版本号打上标签。另外，发布分支上的改动还应该合并入develop分支--在发布周期内develop分支仍然在被使用(一些开发者会把其他功能集成到develop分支)。使用专门的一个分支来为发布做准备的好处是，在一个团队忙于当前的发布的同时，另一个团队可以继续为接下来的一次发布开发新功能。
用于维护的分支:发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯-一种可以直接基于master创建的分支。一旦问题被修复了，所做的改动应该被合并入master和develop分支或者用于当前发布的分支)。在这之后，master上还要使用更新的版本号打好标签。
-
基于develop派生出release预发布分支用于测试bug修正
-
修复完成release分支合并入master分支喝develop分支
-
再将发布分支删除
-
基于master分支打标签
git tag -a 标签名 -m "标签信息描述"
把本地标签提交到远端仓库
git push origin --tags
用户发现bug 为了解决这个问题，小红基于master创建了一个用于维护的分支（hotfix）。她在这个分支上修复了那个bug，然后把改动的代码直接合并入master
跟用于发布的分支一样，在维护分支上的改动也需要合并入develop分支
-
最后可以将维护分支删除
