git命令那么多，怎么学？刚入职的学长告诉你应该学哪些...

目录

背景

开发

本机 + 虚拟机 开发模式

工作中的git场景

开发准备

场景一：创建开发分支

场景二：修改回滚

场景三：commit之后发现自己的commit message 错了！

场景四：我不想提交生成的 .xx 文件

场景五：我只想在其他同事提交的某个分支上进行特性开发

场景六：合并发生冲突！

基础命令参考

---

大家好，我是小李。

背景

相信很多刚从校园里走到工作岗位的同学要接触的第一个实战工具就是大名鼎鼎的分布式协作工具 git，但是对于很多同学来说，在学校里玩的git和在公司里实际使用的git还是有不少差距的。就小李自己来说，在学校的时候，也就是自己用git玩玩，没有参与过团队协作，只用过几个git的基本命令：git clone、git push、git pull...

但是小李进了公司之后才知道那些基本都是玩具用法，根本无法解决实际工作场景中复杂的git问题，而同事们平时都很忙，没有什么时间和精力指导，只能自己摸索踩坑，有时候一踩就是一天，说起来都是泪啊... 今天小李就结合这段时间自己的踩坑经验和学习总结来给大家说说工作中经常用到git的场景，并提供一些解决方案，希望能帮助同学们快速上手工作，尽早走上人生巅峰...

开发

本机 + 虚拟机 开发模式

首先，在公司的实际开发场景中，我们都有两台开发机，分为本机（实体机）和虚拟机（虚拟机一般是公司配的远程服务器，应该都是Unix系统），我们先将要开发的项目分别拉一份到本机和虚拟机（命令：git clone 开发库git地址），通过VSCode（当然也可以是其他的IDE）进行SFTP配置，让本机上的修改可以实时同步到虚拟机。

以github上RPC为例示范如何clone到本地：

git clone git@github.com:RPCS3/rpcs3.git

在实际开发过程中，我们的任何修改都在本机上进行，因为修改会同步到虚拟机上，修改完成后，我们在虚拟机上进行项目构建并运行来判断我们的修改是否符合预期。

工作中的git场景

开发准备

团队开发的主项目有一个git主库，我们先将这个主库 fork 一份到个人仓库。以后我们都对个人仓库上的分支进行开发，开发完成后推送到个人仓库，然后提交MR（merge request）即可。

 

我们在每次拉取个人分支的时候，记得先和主库进行同步，将个人仓的代码同步为最新的主库代码

git clone 个人仓.git 
git remote add main 远程仓.git
git pull main # 拉取并合并远程仓的最新代码 
git add . 
git commit -m "message" 
git push origin # 更新同步个人仓代码

场景一：创建开发分支

  由于我们在实际工作中可能会同时接到好几个并行的开发任务，我们不可能都在master分支上进行开发，这样可能会让自己的开发特性相互影响，从而变得混乱不堪。这个时候就需要用到分支了，我们使用 git branch branchName进行分支创建。

  例如现在我们接到两个需求，一个是增加A业务的按钮，一个是删除B业务的按钮，那么我们可以用如下命令先创建两个开发分支。要开发A业务的时候记得使用git checkout 命令切换到相应的开发分支哦。

git branch addAButton 
git branch addBButton 
git checkout addAButton # 切换到开发分支addAButton，再进行代码开发

场景二：修改回滚

  我们在开发场景中可能会碰到这种情景：开发到一半时发现自己原来的思考是错误的，需要全部推倒重来，这个时候怎么办呢？代码都修改得面目全非了，怎么回退到之前的版本呢？

  这个时候分两种情况：

• 本地的修改还没有进行 add 和 commit 操作：这个时候通过git status 查看自己修改过的文件，然后用 git checkout filename 进行文件回滚，执行完这个命令之后，filename就变回最开始的模样了，又可以快乐开发了。

  git status 
  git checkout filename

• 本地的修改已经进行了add 和 commit操作：这个时候先使用 git log 查看自己提交过的所有 commit，然后找到你想要回退到的提交版本，并记下这个commit id，就是下图中commit后面的这个哈希值，然后使用git reset --hard comitId 进行回退。

git log # 查看所有 commit 记录，找到要回退的版本commit id 
git reset --hard commitId

场景三：commit之后发现自己的commit message 错了！

有时候在commit的时候，由于同学们手速过快，导致commit -m 后的message写错了咋办，git commit 给我们提供了一个强大的参数 --amend，通过 git commit --amend --message="new message" 就可以修改上一次提交的message啦！

git commit --amend --message="new message"

场景四：我不想提交生成的 .xx 文件

我们在构建项目的时候，通常会生成一堆别的文件，这个时候如果直接使用 git add .的话，会将所有的生成文件都提交到个人库上，怎么解决这个问题呢？难道要通过git add filename 一个一个文件添加吗? no,no,no，使用一个命令 git clean --dfx 就能一键清除啦！

git clean --dfx

场景五：我只想在其他同事提交的某个分支上进行特性开发

我们在进行团队协作的时候，往往是我开发A业务的x特性，而同事B开发A业务的y特性，我的x特性可能还得依赖y特性，这个时候如果同事B开发得非常快，开发完了y特性之后又开发了z特性，而我只想拉他的y特性进行开发怎么办？叫他回退一个commit吗？？？那估计会被揍一顿，这个时候我们要用到 cherry-pick命令。

git remote add 同事B的git仓库 
git fetch 分支名 # 要拉取的分支名，拉取同事的分支代码下来 
git log # 查看并获取特性y的commit id 
git cherry-pick commitId # 将commitId对应的修改应用到我的修改之上

场景六：合并发生冲突！

经过x天x夜的奋斗，代码终于写完啦，已经将代码合入到个人库，下一步就是提交MR合入到主库了！激动的心，颤抖的手！诶，怎么合并发生冲突了，咋办呀？基本上，我们在提交MR的时候都可能会遇到这个问题，那就是同事B在特性y上可能也对你修改的文件的某处进行了增删改操作，并且他先你一步将这个修改合入到主库了（倒霉啊）！这个时候就会发生冲突了！这个时候，我们可以通过下面的步骤进行冲突解决。

# 我们这里假设 origin 指向个人库， main 指向主库 
git fetch main/master # 先将主库的master分支拉取下来 
git rebase -i main/master # 这个命令就是在告诉git，我要把我的修改应用在最新的版本上，待会提交的时候别再说我冲突了 
# 修改发生的冲突。如果大家用VSCode IDE的话，这个时候VSCode会提示 conflict 冲突，我们只要在IDE界面上解决下冲突 
git add . # 将修改进行提交 
git commit --amend --no-edit / git commit -m "message" # 前者是合并上次提交的message，后者是新添加一个commit，大家可以视情况自由选择 
git push origin -f # 提交！合并！

基础命令参考

最后，小李提供一些工作中可能会用到的基础命令给各位同学进行参考

git commit： 将 git commit 记录看成是一棵树，每个commit对应一个快照版本，commit不占空间且能快速切换；
git branch：为commit创建一个reference，不占空间; git branch就是在当前工作分支上创建一个reference
git checkout branchName：将HEAD切换到branchName分支
git merge：合并两个branch，产生一个新的commit，这个commit包含两个parent commit；将某个分支合并到当前工作区指向的分支。
git rebase：取出一连串的commit，将它们复制到指定位置之下；简言之，就是我找到另一个分支的公共祖先，然后把这个点往下的都接到另一个分支
HEAD指向当前工作分支，HEAD -> branchName -> commit，git checkout commitid(hashid) 可以使得 HEAD -> commitId
git log: 查看commit hash值
相对引用: 移动工作指针HEAD ^ 向上移动一个 commit, ~n向上移动n个commit
git branch -f main HEAD~3(commitId)：任意移动分支，将main移动到HEAD往上3个commit
git reset commitId：将当前工作分支回退到commitId
git cherry-pick：git cherry-pick <commit1><commit2><...>，复制任意多个 commit 到当前工作分支指向的commit
git rebase commitId：将当前分支构建在commitId的基础之上
git tag tagName commitId：为某个commitId打上tag标签

git checkout filename/commitId/branchName:
    1. filename: 撤销filename修改
    2. commitId: 将HEAD工作指针移动到commitId处
    3. branchName：将HEAD工作指针移动到branchName处

小李也是在不断地学习与总结中，非常欢迎同学们和小李进行留言交流，大家一起学习进步。

本文也将根据工作场景进行持续更新，欢迎同学们关注我呀！