• Git常用操作及技巧
  • 1、基础配置
  • 2、基础操作
  • 3、提交操作与管理
    • 3.1 版本回退
    • 3.2 管理修改
      • 3.2.1 查看修改
      • 3.2.2 撤销修改
    • 3.3 删除文件
    • 3.4 文件恢复
    • 3.5 文件比较
  • 4、远程仓库
    • 4.1 管理远程仓库
      • 4.1.1 添加地址
      • 4.1.2 修改地址
    • 4.2 克隆远程库
    • 4.3 远程推送
  • 5、分支管理
    • 5.1 创建与合并分支
      • 5.1.1 创建分支
      • 5.1.2 合并分支
    • 5.2 分支管理策略
    • 5.3 Bug分支
  • 6、标签管理
    • 6.1 创建标签
    • 6.2 删除标签
  • 7、参与到GitHub

Git常用操作及技巧

1、基础配置

配置全局用户名称和邮件地址

git config --global user.name "xxx"
git config --global user.email "xxx@163.com"

针对单个项目配置用户名称和邮件地址

cd 项目路径下
git config  user.name "xxx"
git config  user.email "xxx@163.com"

查看配置信息

git config --list

git更新命令

git update
git git update-git-for-windows

2、基础操作

创建本地版本库

mkdir my_project
cd my_project
git init

添加文件到暂存区

cd my_project
touch test.txt
git add test.txt

提交文件至版本库

git commit -m "add test.txt"

查看工作区状态

git status

查看git提交日志

git log

或者

# git reflog 常用在git reset版本回退之后的后悔操作
git reflog

3、提交操作与管理

3.1 版本回退

提交记录 A -> B -> C，假设因为C有严重Bug，想回退版本至B

1. 查看git提交日志，获取提交记录B的id

2. 通过git reset命令进行回退

   git reset --hard commit_b_id
   

   或者

   git reset --hard HEAD^ # HEAD^ 表示回退到上一个版本，HEAD^100表示回退到上100个版本
   

3. 现在版本成功回退至B，万一因为某些原因（可能因为误操作），我们又需要回到版本C，可以这样操作

   git reflog # 找到版本c的id
   git reset --hard commit_c_id
   

3.2 管理修改

3.2.1 查看修改

查看文件在工作区和版本库里最新版本之间的区别

git diff HEAD -- test.txt 

3.2.2 撤销修改

• 场景1：撤销工作区的修改

  修改了工作区的文件 test.txt，还未提交到暂存区

  git checkout -- test.txt
  

• 场景2：撤销暂存区的修改
  修改过后的 test.txt 文件已经提交到暂存区，步骤如下：

  1. 撤销暂存区的修改，同样适用于撤销删除操作！！！

  git reset HEAD -- test.txt
  

  2. 撤销工作区的修改，同上↑

• 场景3：撤销版本库的提交
  使用命令 git reset --hard HEAD^
  具体请参考 3.1版本回退

3.3 删除文件

• 删除版本库文件，一旦提交之后当前版本test.txt就会在版本库里面被删除

  # 本地和版本库都会被删除
  git rm test.txt
  # 提交删除
  git commit -m "delete test.txt"
  

• 删除文件的版本控制

  # 提交之后暂存区、版本库中会被删除，但是本地文件不会被删除
  git rm --cache test.txt
  git commit -m "delete remote test.txt"
  

3.4 文件恢复

• 场景1：工作区的删除撤销。通过 rm test.txt 删除，未commit

  git checkout -- test.txt
  

• 场景2：暂存区的删除撤销。通过 git rm test.txt 删除， 未commit

  # 暂存区恢复
  git rest HEAD -- test.txt
  # 工作区恢复
  git checkout -- test.txt
  

• 场景3：版本提交撤销。删除了文件并进行了commit。此时从旧的commit中找出含有该文件的commit进行恢复

  git log # git reflog
  git checkout commit_id test.txt 
  git status # 此时文件已经恢复至工作区和暂存区
  

  还有另外一种办法就是直接进行版本回退，前提是不会影响到其他文件

  git reset --hard HEAD^
  

3.5 文件比较

git diff --stat # 仅仅比较统计信息即文件列表

git diff [filename] # 比较的是工作区文件与暂存区文件的差异

git diff --cached(--staged) [filename] # 比较的是暂存区的文件与上一个commit的差异
  
git diff HEAD -- [filename] # 比较的是工作区与当前分支最新commit之间的差异

git diff [commitId1] [commitId2] # 比较两次提交之间的差异

git diff <branch1> <branch2> # 在两个分支之间比较

4、远程仓库

准备SSH Key，中间会提示输入密码，如果项目不是绝对机密可以直接回车跳过

ssh-keygen -t rsa -C "youremail@example.com"

运行上述命令会在当前用户目录的 .ssh目录下生成 id_rsa 和 id_rsa.pub 两个文件

cat /c/Users/xxx/.ssh/id_rsa.pub # 查看公钥

这样就可以在 github 或者 gitlab 上添加 SSH Key 了。

4.1 管理远程仓库

4.1.1 添加地址

在本地仓库 test 下添加 github 上的空项目test 作为远程仓库地址，远程仓库 test 在这里被叫做 origin , 名字可以自己随便定义

git remote add origin https://github.com/xxx/test.git

下一步，就可以将本地库的 maste 分支推送到远程库上， -u 参数表示把本地的 master 分支和远程的 master 分支关联起来，-u 参数在第一次推送时使用，随后的推送就可以不用加上了。

git push -u origin master

4.1.2 修改地址

首先查看远程仓库

git remote -v

直接修改

git remote origin set-url [url]

先删再加

git remote rm origin
git remote add origin [url]

4.2 克隆远程库

mkdir test & cd test
git clone https://github.com/xxx/test.git # 默认拉取master分支
git clone -b dev https://github.com/xxx/test.git # -b 指定要拉取的分支

如果拉取下来的 master 分支，想切换到 dev 分支进行开发，步骤如下

1. git getch origin dev 同步到最新的远程库 dev 分支代码
2. git switch -c dev origin/dev 在本地创建并切换到 dev 分支
3. git pull origin dev 将远程库的 dev 分支拉取到本地

4.3 远程推送

git push origin master # 将master分支推送到远程库 origin

分支链接

git branch --set-upstream-to=origin/dev dev # 将dev分支链接到远程库的dev分支

5、分支管理

5.1 创建与合并分支

5.1.1 创建分支

新版的 git 创建并切换分支命令如下， -c 表示切换到目标分支

git switch -c dev 

旧版的用 git checkout -b dev

创建分支

git branch test

查看当前分支

git branch

切换分支

git switch dev # 旧版 git checkout dev

删除本地分支，强制删除用 -D 参数

git branch -d dev

删除远程 dev 分支

git push origin :dev

5.1.2 合并分支

分支合并：例如将 dev 分支合并到 master 分支

# 切换到master分支
git switch master
git merge dev

通过 merge 进行合并实际上是将冲突解决后又进行了一次新的提交，我们可以使用 rebase 来进行更加优雅的合并

git switch master
git rebase dev # 在mster上合并dev分支，此时出现文件冲突，手动解决冲突即可
git rebase --continue # 继续指令rebase

git rebase 过程相比较 git merge 合并整合得到的结果没有任何区别，但是通过 git rebase 衍合能产生一个更为整洁的提交历史。
如果观察一个衍合过的分支的历史提交记录，看起来会更清楚：仿佛所有修改都是在一根线上先后完成的，尽管实际上它们原来是同时并行发生的。

5.2 分支管理策略

• 请尽量避免使用 fast forward 方式合并分支

• 多人协作开发，请创建自己的分支，然后 merge 到 dev 分支

• 使用普通模式进行分支合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward 合并就看不出来曾经做过合并。

  git merge --no-ff -m "merge with no-ff" dev
  

5.3 Bug分支

bug解决流程

1. 保存工作区现场

   git stash
   

2. 首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

   git switch master
   git switch -c issue-101
   

3. 开始在 issue-101 分支上进行修复工作，修复完成后提交

4. 回到 master 分支，合并 issue-101 分支，合并完成后就可以删除 issue-101 分支了

   git switch master
   git merge --no-ff -m "merge bug fix 101" issue-101
   git branch -d issue-101 # 删除分支
   

5. bug 修复完之后，就可以继续回到 dev 分支开始干活啦，查看之前保存的工作区现场

   git stash list
   

   然后恢复工作区，命令如下

   git stash apply # 恢复不删除
   git stash drop # 删除
   git stash pop # 恢复删除
   git stash apply stash@{0} # 指定stash进行恢复
   

6. 当我们在 master 分支上修复 bug-101 后，同样的分支 dev 也存在同样的bug，那么我们有一个快速的办法来修复 dev 分支上的相同的bug。
   回到 dev 分区之后，不要着急通过 git stash 进行工作区场景恢复，我们先使用如下命令将 master 分支的bug 修复的提交复制到 dev 分支，git 提供了一个专门的命令 cherry-pick

   git cherry-pick fix_bug_101_commit_id
   

   通过这样操作，我们就在 dev 分支上 “重放” 了这个修复的过程，做完这些后，可以进行步骤5来接着进行开发工作啦。

6、标签管理

6.1 创建标签

命令 git tag <tagname> 用于新建一个标签，默认为HEAD，也可以指定一个commit id

git tag v1.0 f52c633 # 给f52c633这次commit打上1.0标签

查看所有的标签

git tag

查看标签详细信息

git show v1.0

6.2 删除标签

推送标签到远程服务器

git push origin v1.0

命令 git tag -d <tagname> 可以删除一个本地标签

git tag -d v1.0

推送全部的标签到远程服务器

git push origin --tags

删除一个远程标签，先从本地删除标签，再从远程删除

git tag -d v1.0 # 删除本地标签
git push origin --delete tag v1.0 # 删除远程标签写法一
git push origin :v1.0 # 写法二

7、参与到GitHub

举个栗子：

假设上游仓库为 https://github.com/kqkdChen/learning-git

步骤：

1. fork 上游仓库 learning-git

2. 然后使用 git clone https://github.com/your_name/learning-git 命令克隆fork之后的库到本地，执行以下命令：

   git remote add upstream https://github.com/kqkdChen/learning-git
   

   这一步是将上游仓库设置为你的本地库的上游库，通过 git remote -v 查看

3. 此时就可以在本地进行开发工作了，修bug、开发新功能都可以，待开发工作完成之后，进行一次原仓库的同步。

   git fetch upstream
   

4. 将刚刚开发提交完的本地库、fork库仓库、主仓库三个库进行同步

   git pull upstream master --rebase
   

   如果有冲突，则手动解决文件冲突，建议进行 rebase

5. 截至前面的步骤，此时将代码再推送到自己的fork库之后

   git push origin master
   

   就可以在 github 上进行 pull request 了。