关于git:Git的常规操作

5次阅读

共计 3207 个字符，预计需要花费 9 分钟才能阅读完成。

作为一名开发人员，不论走到哪里可能都会和代码仓库产生不可形容的关系，从 clone 仓库 => 新的性能分支 => 开发性能实现后提交 => 分支合并 => 打上标签 => 部署到线上环境，这一系列操作都离不开这个代码版本管理工具 Git，所以常见命令烂熟于心有助于咱们晋升效率。

gitlab 或者 github 有有两种克隆形式，ssh 协定和 http 协定。应用 http 只有输出用户名和明码即可，应用 ssh 是要部署本人的公钥到 gitlab 或者 github 上，在登录用户的设置里边配置。查问本人的公钥，个别本人电脑的以下目录：

➜  ~ cd .ssh
➜  .ssh ls
id_rsa      id_rsa.pub  known_hosts

公钥就是 id_rsa.pub 这个文件中的内容，部署好之后就能够去克隆仓库了。

好的，据说名为 Blog 的仓库你曾经克隆到本地，当初要做一个评论的性能，那么从终端进入我的项目个别是这个样子：

➜  Blog git:(main)

如果生产环境部署的是 main 分支或者叫 master，那么新的性能应该从这个主分支检出。

➜  Blog git:(main) git checkout -b comment
Switched to a new branch 'comment'

* comment
  ele
  main

到这里就能够在这个分支上做你的性能了。当你写到衰亡的时候，忽然领导通知你线上有个问题急须要修复。忽然有点慌乱，不过还是得先保留你做了一半的评论性能。于是你应用了以下命令：

➜  Blog git:(comment) ✗ git status
On branch comment
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

// 看到了相熟的内容改变，示意释怀，应用上面的命令把它们纳入到版本治理
➜  Blog git:(comment) ✗ git add .
➜  Blog git:(comment) ✗ git commit -m "comment progress 50%"
[comment 006a55d] comment progress 50%
 1 file changed, 1 insertion(+), 1 deletion(-)

这样做是能够，然而产生了一次提交记录，其实还能够把你的批改先暂存起来，当初咱们把这次提交重置掉，要进行重置咱们须要晓得上一个版本号：

➜  Blog git:(comment) git log --oneline

006a55d (HEAD -> comment) comment progress 50%
2bf17f8 (origin/main, origin/HEAD, main) loading
56131ba 优化款式
cc91d8c abstract
a81dbe7 sitemap
b915f65 baidu

能够看到咱们只有重置 2bf17f8 这一次就好了，然而须要留神须要保留辛苦写起来的代码 (bug)。于是机智的应用了上面命令：

➜  Blog git:(comment) git reset --mixed 2bf17f8
Unstaged changes after reset:
M    README.md
➜  Blog git:(comment) ✗ git status
On branch comment
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

欢快的回到了未提交之前的状态。如果你应用 git reset –hard 2bf17f8，那么就要祝贺了，之前的改变就全副失落了，所以肯定要谨慎。

为了缩小一次无用的提交，咱们应用 git stash 来暂存未实现的评论性能：

➜  Blog git:(comment) ✗ git stash
Saved working directory and index state WIP on comment: 2bf17f8 loading
// 能够看到是以上次提交的信息记录本次 stash 的内容

接下来就能够解决领导安顿的紧急任务了，从主分支切出 hot_fix 分支

➜  Blog git:(main) git checkout -b hot_fix
Switched to a new branch 'hot_fix'

问题修复后保留提交：

➜  Blog git:(hot_fix) ✗ git add .
➜  Blog git:(hot_fix) ✗ git commit -m "bug fixed"

切换分支到 main 合并 hot_fix

➜  Blog git:(hot_fix) git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
➜  Blog git:(main) git merge hot_fix
Updating 2bf17f8..b85e853
Fast-forward
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

到这里，就能够从 main 分支公布新的版本到线上了，并且修复了线上的紧急问题。这时你的本地呈现了没有用的分支 hot_fix：

➜  Blog git:(main) git branch
  comment
  ele
  hot_fix
* main

当初能够把它删除掉了应用：

➜  Blog git:(main) git branch -d hot_fix
Deleted branch hot_fix (was b85e853).

如果你之前还把它推送到了近程，查看所有近程分支：

➜  Blog git:(main) git branch -r
  origin/HEAD -> origin/main
  origin/ele
  origin/hot_fix
  origin/main
(END)

那当初近程也没有任何用处了，应用上面命令删除近程分支：

➜  Blog git:(main) git branch -r -d origin/hot_fix
Deleted remote-tracking branch origin/hot_fix (was b85e853).

当初又从新回到清新的状态，能够从新回到 comment 分支实现之前的性能：

➜  Blog git:(main) git checkout comment
Switched to branch 'comment'

// 把之前暂存的内容复原
➜  Blog git:(comment) git stash pop
On branch comment
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (0553a4fa89f44ea5708a21d5c421c7b1115c40cb)

又能够 happy 的 coding 了。本文通过一个场景，重现了在理论工作中一些 git 命令的应用，心愿对你有帮忙。

正文完