Git 常见场景操作

注：下面提交的文件统一用 readme.md 代替

Git 安装后的初始化

Git 安装完成之后有一段初始化的操作

• 设置用户名以及邮箱

  git config --global user.name "Your Name"
  git config --global user.email "[email protected]"
  

本地创建版本库

本地先新建一个空目录叫做myrepo

• 创建新目录

  mkdir myrepo
  cd myrepo
  pwd
  

• 将其变为 Git 可管理的仓库

  git init
  

查看有推送权限的地址

• 查看有推送权限的远程库

  git remote
  

• 详细查看有推送权限的远程库

  git remote -v
  

Git 提交最常规操作

假如要提交 readme.md 文件到远端库中，可以先把这个文件放在本地 Git 仓库中

• add 添加到仓库准备提交（add 之前 git status 可以查看到被 modified 的文件 not staged）

  git add readme.md
  

• commit 把所有 add 的文件提交到仓库（commit 之前 git status 可以查看被 modified 的文件 to be committed）

  git commit -m "提交readme文件"
  

• push 推送提交到远端（push 之前 git status 可以查看 nothing to commit）

  git push
  

git 切出分支并推送到远程

• 当前在 develop 分支下，从 develop 切出新分支 newBranch

  git checkout -b newBranch
  

• 查看远端分支

  git branch -r
  

• 将新分支推送到远端

  git push -u origin newBranch
  

常规的本地库版本回退

本地库经历数次 commit 提交，形成多个不同版本

• 查看本地库版本详情

  git log
  

• 查看本地库版本（只保留版本号和 commit 的信息）

  git log --pretty=oneline
  

• 若想回到上一个版本（Git 中 HEAD 表示当前版本，上一个版本就是 HEAD^，上上版本就是 HEAD^^，往上 100 个版本就是 HEAD-100）

  git reset --hard HEAD^
  

• 若想再回到最新的那个版本（git log已经看不到那个新版本的版本号了，可以翻历史找到新版本的版本号再跳。或者用 git reflog，它可以记录每次命令）

  git reflog
  

撤销工作区修改、add、commit

• 场景一：仅仅改乱了工作区代码，想要工作区代码还原（若该文件在暂存区 stage 存在，会还原成 stage 中的样子，若 stage 中不存在则工作区代码还原成版本库的样子）

  git checkout --readme.md
  

• 场景二：误把代码进行了 add 操作，想要撤销暂存区 stage 中的修改到工作区（撤销后工作区代码变成 stage 中的样子，并且 stage 中是清空的，相当于撤销 add 操作）

  git reset HEAD readme.md
  

• 场景三：工作区改乱了代码，同时还误提交到了 stage 中，想要清空 stage 中的修改同时将工作区乱改的代码还原（相当于把场景一和场景二合并起来使用）

  git reset HEAD readme.md
  git checkout --readme.md
  

• 场景四：撤销版本库中的提交，即更换为之前的版本

  git reset --hard 版本号
  

当前工作完成了一半，又紧急接到另一个任务，想要保存当前工作场景以后可以恢复

A 同事在本地 develop 分支修改代码，改了一半，此时又接到一个修改一个紧急修改 bug 的任务需要率先完成，那么 A 同事需要将当前工作保存下来，当前在 develop 分支的工作中有的修改已经 add 了，有的修改还没有 add，他需要将这些 修改（不管是已经 add 或是还没有被 add）stash 一下，来存储到 stash 存储区域，然后从某个分支切出 bug 分支进行 bug 的修改，该 bug 任务完成之后，删除本地这个 bug 分支，A 同事还需要切回到 develop 分支，但是通过 git status 命令是看不见修改的，这是因为已经把 modified 的文件（不管有没有被 add）存进了 stash 存储区，他需要恢复到之前的工作，使用 git stash pop 命令来将工作内容恢复到过来，同时 stash 存储区域中的保存被成功删除

• A 同事当前在 develop 分支上，查看当前状态以及当前修改 add 情况

  git status
  

• A 同事将修改保存到 stash 存储区域

  git stash
  

• A 同事切出 bug 分支进行开发代码提交并删除分支

  git checkout -b bug01
  git add readme.md
  git commit -m "提交bug01修改"
  git checkout develop
  git branch -d bug01
  

• A 同事在 develop 分支下可以先通过 status 命令查看到确实没有修改，这是因为保存到 stash 区域了，然后查看 stash 存储区中保存了哪些修改，然后恢复之前工作，并删除 stash 存储区的修改

  git status
  git stash list
  git stash pop
  git stash list
  

  或者用下面这个，使用 apply 时候可以恢复但是 stash 存储区中的数据不会删除，使用 drop 去删除

  git status
  git stash list
  git stash apply
  git stash list
  git stash drop
  git stash list
  

冲突解决

• 场景一：pull 拉取冲突或者 push 推送冲突。你的小伙伴刚刚已经提交了一个内容进远端 develop 分支，这时你也改好了想提交到远端 develop 分支，这是你发现提交不上去，显示冲突了，你需要先使用 pull 把最新的提交拉下来，本地合并解决冲突再提交

  • 现在在 develop 分支下，push 到远端发现冲突，先拉下来，发现显示冲突，查看冲突文件

    git pull
    git status
    

  • cat 命令打开冲突文件，手动修改代码解决冲突文件信息，<<<<<<< HEAD下面是拉下来之前本地的版本中该文件冲突的代码，>>>>>>> develop上面是拉下来的版本中该文件冲突的代码，二者通过=======隔开，把该冲突的文件修改好一个全新的版本再提交，等到 push 冲突的修改成功后，本地和远端 develop 内容就是一致的了

    cat readme.md
    git add readme.md
    git commit -m "解决readme.md文件拉取时候冲突"
    git push
    

• 场景二：merge 合并冲突。你的小伙伴从 master 分支拉出 A 分支和 B 分支，同时在 A 和 B 分支上做了两个方向的修改，这个时候他想把 B 分支合并进 A 分支，发现冲突了，但是他想成功合并进去…

  • 现在在 A 分支下，合并命令已经显示冲突了，使用 status 命令查看冲突文件，并打开冲突文件进行修改

    git status
    cat readme.md
    

  • 修改好后进行提交冲突修改，提交后就会合并成功，然后通过 log 命令查看分支合并情况

    git add readme.md
    git commit -m "解决readme.md文件合并时候冲突"
    git log --graph
    

发版时打标签操作

发布一个版本时候，我们是会在版本库中打上一个标签，比如说 V1.0 版本，以后也可以取那个标签版本。tag 标签从数据结构上来讲是指向 commit 的指针，打标签时候默认是打在最新提交 commit 上（merge 的话也算是提交），若是之前有 commit 后忘记打标签了，可以找到历史 commit id，然后再打标签命令后跟上 commit id 即可，也很容易，打标签的意义是在于给项目设置开发结点，方便日后项目成员进行项目维护差错和回溯。

• 现在在 master 主分支下，develop 每次合并到主分支，然后把 master 拉下来后，打标签

  git tag v2.0
  

• 之前有个版本提交忘记打标签了现在补上，6224937 这个数字是之前那个版本最后提交的 id

  git tag v1.0 6224937
  

• 想要查看本地所有标签，还有查看某个详细标签

  git tag
  git show v2.0
  

• 把某个标签推送到远端，因为一般的 push 是没法推送标签的

  git push v2.0
  

• 删除本地标签

  git tag -d v2.0
  

• 删除远端标签，删除远端标签之前需要先删除本地标签

  git tag -d v2.0
  git push origin :refs/tags/v2.0
  

Git 在 GitHub 上的实际操作

• 场景一：GitHub 上热门的开源项目想要自己贡献功能性代码

  • 先在 GitHub 上热门的开源项目上点击 fork 按钮把开源项目克隆到自己 GitHub 仓库

  • 然后需要从自己 GitHub clone 到本地，因为要是从源头仓库克隆到本地，是无法提交的，因为提交要求输入对应 GitHub 账号的用户密码

    git clone 自己GitHub仓库.git的http路径
    

  • 你可以自己修改功能代码提交到自己的该项目仓库中，修改完后你想要提交开那个开源项目的源头仓库，可以在 GitHub 上发起一个 pull request 请求，当然对方是否接受你的请求还是要看你代码功能好不好，就是看命

搭建自己的 Git 服务器

有些商业公司，既不可能开源自己的项目放在开源的 GitHub 仓库又不想给 GitHub 交保护费来使用 GitHub 没有限制的私有仓库，所以它们选择自己搭建一个 Git 服务器，来存放自己公司的项目代码。对于服务器的选择，强烈建议使用 Ubuntu 或者 Debian，因为这样几个简单的 apt 命令就可以完成安装，加入你已经有 sudo 权限使用账号

• 安装 git

  $ sudo apt-get install git
  

• 创建一个 git 用户来运行 git 服务

  $ sudo adduser git
  

• 创建证书登陆，即搜集所有需要登录用户的公钥，就是他们自己的 id_rsa.pub 文件，把所有公钥导入到/home/git/.ssh/authorized_keys文件里，一行一个。

• 初始化 git 仓库。先选定一个目录作为 git 仓库，假如是/srv/sample.git在/srv目录下输入如下命令，初始化的这个实际上是一个裸仓，没有工作区。这个服务器中的仓库纯粹是为了免费存储并且可以免费共享给指定的项目组员，一般是不能让成员去服务器中修改工作区，并且服务器中 git 仓库通常以 .git 结尾

  $ sudo git init --bare sample.git
  

• 把拥有者改为 git

  $ sudo chown -R git:git sample.git
  

• 禁用 shell 登陆。处于安全考量，第二步创建的 git 用户不允许登陆 shell，可以通过编辑/etc/password文件完成，找到类似下面的一行

  git:x:1001:1001:,,,:/home/git:/bin/bash
  

  改为

  git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
  

  这样之后，git 用户可以正常通过 ssh 使用 git，但是无法登陆 shell，因为我们为 git 用户指定的 git-shell 每次登陆就自动退出

• clone 远端仓库

  $ git clone 自己仓库.git的路径