Git 这样玩 爽翻！！！

Git架构

日常8个命令

// 添加文件到工作区
git add 
//显示工作区状态
git status
//提交信息到本地仓库
git commit
//将变更推送至远程仓库
git push
//获取远程分支更新
git pull
//切换或者还原本地更改
git checkout
//克隆远程仓库到本地新目录
git clone
//初始化一个目录为git工作目录
git init 

示例

//克隆远程仓库到本地
git clone https://github.com/a.git
//创建化本地仓库
git init 
//查看当前工作区状态
git status
//将当前工作区的修改添加到暂存区
git add **/*.java
//提交暂存区到本地仓库
git commit -m 'commit message'
//将本地仓库中的文件覆盖到工件区
git reset HEAD~1
//使用当前本地分支新创建一个新分支
git checkout -b feat/1.0
//使用远程指定的分支创建一个新分支
git chekcout -b feat/1.0 origin/feat/1.0
//合建本地仓库文件还原工作区的所有更改
git checkout .
//获取远程仓库的更新
git pull
//将变更推送至远程仓库
git push 
//将本地仓库当前文件推送到远程仓库，交推送分支上的更改
git push --set-upstream origin master

合并 merge

//切换分支至master
git checkout master
//获取master分支上的变更
git pull 
//切换分支到feat/1.0
git checkout feat/1.0
//合并master分支到feat/1.0
git merge master

merge与rebase的分歧
支持使用 merge 的开发者，他们认为仓库的提交历史就是记录实际发生过什么，它是针对于历史的一个文档，本身其实是有价值的，我们不应该随意修改。我们改变历史的话，就相当于使用“谎言”来掩盖实际发生过的事情，而这些痕迹是应该被保留的。可能，这样并不是很好。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pr2059Y9-1620008435476)(media/16195741701942/16196281708129.jpg)]
支持使用 rebase 的开发者，他们认为提交历史是项目过程中发生过的事情，需要项目的主干非常的干净。而使用 merge 操作会生成一个 merge 的 commit 对象，让提交历史多了一些非常多余的内容。

使用原则：
只对尚未推送或分享给其他人的本地修改执行变基操作清理历史，从不对已经推送到仓库的提交记录执行变基操作，这样，你才可能享受到两种方式带来的便利。

修改commit中的message

有时提交后发现提交的历史中有些commit message描述不准确,又或者需要在当前提交中再添加更改，这时不想再生成一个新的commit Id,达到合并的效果。这时可以使用 git commit --amend

//修改工作区的文件
echo "test git commit --amend" >> test2.txt
//暂存工作区的变更
git add test2.txt
//提交工作区的修改并保存修改提交描述
git commit --amend 

当前工作区没有暂存的变更时使用git commit --amend可以达到修改上一次提交中的message的目的

合并部分提交

产品汪小明发布了版本1.4的开发计划；开发小红创建feat/1.4分支进行对应的功能开发，业务主小靜告诉小明业务需要快速上线；可以先上1.4版本中的功能A;得到这个消息后…

产品汪小明：怎么办，功能A要先上，能快速剥离出来功能A吗？

开发小红：我去WC …

小红回来后使用git cherry-pick很快解决的产品汪的需求,她这样操作了：
feat/1.4 分支log：

//将分支切换到目标分支 master
git checkout master
//使用 cherry-pick 摘出42032b6 commitID的提交内容
git cherry-pick 42032b6

master分支执行git cherry-pick后的结果

执行git cherry-pick会在分支中创建一个新的Commit ID
git cherry-pick commitid1 commitid2 可以合并多个到当前分支

回滚提交

在合并分支到master时不小心合并错了，需要将master分支回滚到上一个版本；git为我们提供了小工具revert;只需要执行git revert 32e4481就可以回滚到32e4481的commitid点上；
执行回滚前：

执行get revert 32e4481后：

revert操作会在当前分支前插入新的commitId0038c12
在实际工作中不建议进行revert解决回滚的问题，而是使用reset命令，将当前工作区域还原到指定的commitId状态；这样在后续需要时还可以通过reset还原回来；

查找记录reflog

在使用git reset命令还原工作区后再使用git log打印提交日志将看到还原点的后继提交日志；这怎么办呢？
git 提供了reflog工具，它默默的为我们记录下了git的所有操作记录；妥妥的小助理；
git reflog结果如下：

在这段日志中能看到上面revert的操作记录0038c12；合并版本feat/1.4的merge记录e61d5da;如果现在需要回退到feat/1.4合并后的提交只需要执行

git reset --hard e61d5da

再使用git log打印提交记录主是下面的结果了：

get reflog的结果中也增加了reset操作的记录

通过查询reflog后可以再次使用git reset --hard 0038c12还原到回滚点上

批量修改历史记录

在开源或者个人项目中使用了公司的邮箱进行提交，这时我们想把所有这样错误的提交修改回来；这样的需求git也为我们想到了，你只需要这样操作：

//为了安全先创建一个分支
git branch -b testing
//对提交的错误信息进行修改
git filter-branch --commit-filter '
    if [ "$GIT_AUTHOR_EMAIL" == "jason_test@jasony.site" ]; then
        GIT_AUTHOR_NAME="jason";
        GIT_AUTHOR_EMAIL="jason@gmail.com";
        git commit-tree "$@"
    else
        git commit-tree "$@"
  fi' HEAD

这里我们可以使用 filter-brach 的方式进行修改，但是建议在使用之前，新建一个分支，在上面进行测试没有问题之后，再在主干上操作，防止出现问题，背个大锅在身上。
使用这样的命令可以搞这些事

• 开源或个人项目中使用了公司邮箱进行提交了
• 提交文件中包含隐私性的密码相关信息
• 提交时将大文件提交到了仓库代码中了

快速克隆

在大项目中新拉取代码会是一个很占用时间的活，如果再遇上网络带宽低的话基本一个半天可以去摸鱼了。
怎么办呢？
git已经想到了，在执行clone命令时加上--depth参数；--depth=1表示只拉取分支中最新的一次提交历史，不包含项目中其它的历史提交记录；在.get/objects/目录下的对象只是本地的，没有包含之前修改产生的对象。

git clone http://github.com/jason/d.git --depth=1

clone 完成后git log的打印结果如下：

如果需要快速克隆么个tag或者分支可以这样操作

//创建目录​
​mkdir project-v1.4 && cd project-v1.4
//初始化git​
git init
//添加远程库链接​
git remote add origin https://github.com/jason/d.git
//获取远程库tag 深度为1​
​git fetch origin v1.4 --depth=1
//将结果创建一个新分支​
​git checkout FETCH_HEAD

这样能快速的克隆指定的Tag或者分支

工作中的中断处理

工作中经常会有多路运转的情况，在这样的情况下怎样保持高效呢？
git stash来帮您：

//将工作区的内容进行存储，并将工作区回滚到HEAD
git stash push 
//显示stash存储的项
git stash list
//将stash存储栈中的最后一次存储的内容还原到工作区并删除这一项
git stash pop
//将stash存储栈中指定索引位置的项还原到工作区，不删除索引位置的项
git stash apply
//将项从stash存储栈中删除
git stash drop

在当前分支中进行内容修改还没有修改完成时需要放下当前的工作在另外的分支上处理其它问题时，可以将当前工作区的内容stash，执行git stash push -m 'test'命令；然后切换到另外的分支进行工作；完成后再切换回没处理完成的分支，通过git stash pop进行工作区的还原；
这样做的好处在于不用将没有完成的工作内容commit到本地仓库中，增加无效的commit；缺点在于这些更改存储在本地，如果本地数据丢失将无法找回。

公众号阅读 码农杰森