git笔记
管理工作目录
mkdir xxx
cd xxx
git init 初始化
git status 查看工作树状态
git log 查看提交记录
git reflog 查看之前所有的操作记录
git 三个状态切换
- 工作区 暂存区 本地仓库
git add ./<filename> 工作区到暂存区
git commit -m "修改说明" 暂存区到本地仓库
git checkout ./<filename> 丢弃工作区修改的内容
git reset ./<filename> 从暂存区退到工作区
git reset --hard/ --soft <commit_id> 版本回退
--hard 丢弃内容
--soft 把内容放入暂存区
分支管理
git branch <name> 创建分支
git branch 查看分支
git branch -d <name> 删除分支
git checkout <name> 切换分支
git merge <name> 将name分支合并到当前分支 ！！！name为分支名而不是文件名
-- 不同分支修改的内容会造成冲突，内容都在文件中，只能手动修改内容解决
-- 解决完冲突需要提交到add暂存区，commit到本地仓库
标签管理
git tag <name> <commit_id> 给指定的版本加标签
git tag 查看标签
git tag -d <name> 删除标签
远程仓库建立连接
- SSH
1. 切换到主用户的家目录下，生成公钥私钥
`ssh-keygen -t rsa -C "youremail@example.com"`
2. 把生成的公钥放入GitHub账号的sshkey列表里
3. 建立连接【在本地】
git remote add "远程仓库的别名" "远程仓库的地址https/ssh"
4. 查看本地连接的所有的远程仓库
git remote
5. 向远程仓库提交代码
git push -u 远程仓库别名 分支名
注意 -u 第一次提交代码的时候本地分支跟远程仓库的分支建立起连接
6. 从远程仓库拉代码
git pull 远程仓库别名 分支名
7. 远程仓库的代码与最后一次push的代码有变化时，push会失败
-- 先从远程仓库拉去代码
-- 手动解决冲突
-- 提交到本地仓库
-- git push ……
克隆项目【将网上的仓库拉到本地】
git clone 远程仓库地址
业务流程
1. 拉取自己分支的代码
2. 提交到测试分支
3. 提交到远程仓库自己的分支
4. 提交合并请求
5. 由领导将你的分支合并到master
6. 提交到保险分支 【和线上分支一模一样】
7. 提交线上分支
-- 当上线后再出bug
1. 在master分支建立bug分支
2. 在线上分支版本回退
3. 在bug分支 解决bug
reset 回退版本
rebase 合并提交记录， 保持记录的整洁性
即拉即用：你不知道的持续集成的3个Git Hooks详解
1.了解Git Hooks
Hook是Git系统的本地机制，用于在诸如代码提交（Commit）和合并(Merge)之类的操作之前或之后触发的定制化脚本，可以把它们看作是Git的插件系统。对Git-hooks有一个入门认识的朋友都知道， 如果你进去查看Git的.git目录，你将看到一个“hooks”的子目录，里面包含很多Hook脚本。
安装Git Hooks其实很简单，网上也有很多供查阅的参考文档，在此就不讨论这个问题了。
按照Git Hooks脚本所在的位置可以分为两类： 客户端Hooks和服务器端Hooks。
客户端Hooks在本地工作站运行， 而服务器端Hooks则在你的Git服务器上运行。
还可以将Hook分类为Pre- 或Post-。Pre-receive Hooks脚本在某些特定的Git操作之前被调用, 可以利用这个Hook脚本来检查推送过来的提交是否合法，如不合法，Git操作不被执行，即客户端的推送会被拒绝。它们实际扮演一个保镖的角色，从后台保护代码库, 防止你和项目成员提交错误的代码。当从客户端（本地库）完成一个推送后， Post-receive Hooks将运行，它不会拒绝Git代码提交，但可以完成开发工作流程中的一系列自动化任务。
使用Git Hooks，就像拥有一个小机器人助手， 可以实现Git相关的一系列自动化任务 (哈哈！)
Git Hooks可实现项目开发流程的一系列自动化任务，例如下面几点：
验证你在提交消息中包含了关联的JIRA密钥
在代码合并前，确保满足先决条件
发送通知给你开发团队的聊天室
在切换到不同的工作分支后，设置你自己的工作区
2.创建稳定健康的工作分支
服务器端 Pre-receive Hooks是持续集成中的一个特别有力的补充，可以利用它来检查代码是否符合某些条件，防止开发人员随意将代码推送到master，就像精英忍者守护者一样，保护代码库不受恶意代码的影响。
开发人员通常都有足够的责任心，当他们在自己的工作分支测试上出现问题时，他们不会将分支合并到主程序。但有时我们却忘了检查，特别是当我们和其他人共享一个工作分支的时候，这时候会发生更多的更改或变化，虽然我们上次已经检查了分支的情况，但没想到问题还是出现了。。。。。。
此时，你就可以使用一个服务器端Hook，用于查找进入master的合并， 找到时， 脚本将检查分支上最新的构建，如果有测试失败的情况，那么合并就会被拒绝。我的同事和Atlassian的开发者Tim Petterson为此编写了一个Hook脚本
旨在与Bamboo合作，并使它在Bitbucket上可完美运用。 你可以把它抓下来，定制它，并将其添加到你的代码库中。
3.保护你来之不易的代码覆盖率
我看到很多开发团队都在努力维护代码覆盖率。 很多情况下，他们不得不通过测试来追溯他们的源代码库。在没有经过测试验证支撑的情况下，当很多功能被添加进来时，好不容易达成的代码覆盖率每况愈下，看到这样的情景，实在令人心灰意冷。因此，Tim还编写了一个pre-receive服务器端Hook，来保护master代码覆盖率不再下降。
这个Hook也可以查找进入到master的合并，然后调用持续集成服务器来检查master以及分支上的代码覆盖率。如果分支的覆盖有任何问题，则合并将被拒绝。
大多数持续集成服务器不会通过它们的远程API显示代码覆盖数据，但Git Hook脚本可以获取代码覆盖报告。 要做到这一点，构建必须设置为将代码覆盖报告在master和工作分支上作为共享件发布。 一旦发布，你可以通过调用持续集成服务器从master获取最新的覆盖报告。对于分支覆盖，你可以从最新的构建中获取覆盖报告，也可以从正在提交的merge相关分支获取覆盖报告。
需要说明的是， 上述实践的前提是你已经运行了代码覆盖。别指望这个Hook来干这件事——它只是在你的构建结果中查找覆盖率数据而已。 默认情况下，这个脚本也适用于Bamboo，以及Clover（Atlassian的Java和Groovy代码覆盖工具）。但是它可以定制成与构建服务器或代码覆盖工具结合在一起使用。
4.检查分支构建的状态
朋友通常不会让朋友去检验有问题的分支。
那么此时，我们就可以利用另一个客户端Git Hooks: post-checkout Hook脚本，同样也是由Tim编写的，它在你的终端窗口中显示分支创建状态。该脚本从本地副本获取分支的头版本号，然后查询持续集成服务器，查看是否已经创建了该版本，并检查创建是否成功。
地址：https://bitbucket.org/tpettersen/post-checkout-build-status/src
比如，你想在master中创建分支，这个Hook会告诉你， master上的head commit是否成功建立，这意味着可以用这个“安全的”提交来创建分支。 再如，如果这个版本的分支构建失败了，但是开发团队的墙板却显示了一个绿色创建(或者正好反过来)。这意味着你的本地副本已经过期了，你可以自已决定是要更新版本还是继续使用旧版本的本地副本进行操作。
使用这个Hook对Atlassian的开发人员来说是无疑是一大神器，使他们避免了无数头痛的困扰。如果你实在不能说服你的开发团队采用上面讨论的服务器端Hook，那至少可以在你的本地工作站上安装一个，相信你绝对不会后悔的！
我在这里演示的所有用于持续集成的Git Hooks， 默认都是基于和Bamboo、Clover、Bitbucket 结合使用的情形,但是请记住，Git Hooks实际上是厂商无关的，因此你可以将它们定制成与你自已的编码工具结合使用，从而在开发过程中实现真正的自动化。
原文链接：https://www.atlassian.com/continuous-delivery/git-hooks-continuous-integration
