GIT操作

发表于2023-07-03更新于2024-09-15字数统计2.9k阅读时长18分

已完成的文章

GIT操作

登录git账号

使用git本地仓之前，需要先设置用户签名

1
2
git config --global user.name 姓名
git config --global user.email 邮箱

常用命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 查看本地库状态
git status
# 查看历史记录
git reflog
# 查看详细历史记录
git log
# 版本穿梭
git reset --hard 版本号
# 撤回commit
# 不删除工作空间代码，撤销commit、add
git reset --mixed HEAD^ # HEAD^等同与HEAD~1 就是上一个版本
# 不删除工作空间代码，撤销commit不撤销add
git reset --soft HEAD^
# 删除工作空间代码，撤销commit、add
git reset --hard HEAD^
# 修改上一次commit注释
git commit --anend

分支的操作

1
2
3
4
5
6
7
8
# 创建分支
git branch 分支名
# 查看分支
git branch -v
# 切换分支
git checkout 分支名
# 把指定的分支合并到当前分支上
git merge 分支名

远程仓库的操作

1
2
3
4
5
6
7
8
9
10
# 查看当前所有远程地址别名
git remote -v
# 起别名
git remote add 别名 远程地址
# 推送本地分支上的内柔到远程仓库
git push 别名 分支
# 将远程仓库的内容克隆到本地
git clone 远程地址
# 将远程仓库对于分支最新内容拉下来后与当前本地分支直接合并
git pull 远程库地址别名 远程分支名

创建本地git仓库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
mkdir 项目文件夹
cd 项目文件夹
# 初始化git本地仓
git init	
touch README.md
# 将文件添加到暂存区
# 添加全部文件夹 git add .
git add README.md
# 缓存区的文件提交到本地仓	-m对本次提交做的备注
git commit -m "first commit"
# 设置本地仓库连接到远程仓库的地址
git remote add origin https://gitee.com/******
or
git remote set-url origin https://gitee.com/******
# 本地仓库上传到远程仓库master分支下
git push -u origin "master"

git 拉取项目

1
2
3
git init
git remote add origin https://gitee.com/******
git pull origin "master"

git克隆项目

clone 会做如下操作。1、拉取代码。2、初始化本地仓库。3、创建别名

1
git clone https://gitee.com/******

git pull 强制覆盖本地的代码方式

1
2
3
4
5
6
7
# git fetch从远程下载最新的，而不尝试合并或rebase任何东西
git fetch --all
# git reset将主分支重置为您刚刚获取的内容。 
# --hard选项更改工作树中的所有文件以匹配origin/master中的文件。
git reset --hard origin/master
# 或者如果你在其他分支上：
git reset --hard origin/<branch_name>

Fork 与 Pull reques

Fork: 将项目叉到自己的本地仓库

Pull request： 拉取请求

生成/添加SSH公钥

1
2
3
4
# 这里的 xxxxx@xxxxx.com 只是生成的 sshkey 的名称，并不约束或要求具体命名为某个邮箱
ssh-keygen -t ed25519 -C "xxxxxx@xxx.com"
# 按照提示完成三次回车，即可生成 ssh key。通过查看 ~/.ssh/id_ed25519.pub 文件内容，获取 public key
cat ~/.ssh/id_ed25519.pub

设置 Git 短命令

方式一

1
git config --global alias.ps push

方式二

1
2
3
4
5
6
7
8
9
10

# 打开全局配置文件
vim ~/.gitconfig
# 写入内容
[alias] 
        co = checkout
        ps = push
        pl = pull
        mer = merge --no-ff
        cp = cherry-pick

使用

1
2
# 等同于 git cherry-pick <commitHash>
git cp <commitHash>

忽略文件

本地仓库中创建 .gitignore 文件

1
2
3
4
# 忽略指定文件
xxx.txt
# 忽略指定文件夹
文件夹名

文件模版

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*

.classpath
.project
.settings
target
.idea
*.iml

可在在.gitconfig 文件中引用忽略配置文件

1
2
3
4
5
[user]
	 name = 姓名
	 email = 邮箱
[core]
 	 excludesfile = 文件路径

5 条提高效率的命令

  • stash：存储临时代码。
  • reset --soft：软回溯，回退 commit 的同时保留修改内容。
  • cherry-pick：复制 commit。
  • revert：撤销 commit 的修改内容。
  • reflog：记录了 commit 的历史操作。

stash

描述

官方解释：当您想记录工作目录和索引的当前状态，但又想返回一个干净的工作目录时，请使用git stash。该命令将保存本地修改，并恢复工作目录以匹配头部提交。

stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。

命令使用

应用场景：某一天你正在 feature 分支开发新需求，突然产品经理跑过来说线上有bug，必须马上修复。而此时你的功能开发到一半，于是你急忙想切到 master 分支，然后你就会看到报错，因为当前有文件更改了，需要提交commit保持工作区干净才能切分支。由于情况紧急，你只有急忙 commit 上去，commit 信息也随便写了个“暂存代码”，于是该分支提交记录就留了一条黑历史…

如果你学会 stash，就不用那么狼狈了。你只需要：

1
git stash

就这么简单，代码就被存起来了。

当你修复完线上问题，切回 feature 分支，想恢复代码也只需要：

1
git stash apply

相关命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 保存当前未commit的代码
git stash

# 保存当前未commit的代码并添加备注
git stash save "备注的内容"

# 列出stash的所有记录
git stash list

# 删除stash的所有记录
git stash clear

# 应用最近一次的stash
git stash apply

# 应用最近一次的stash，随后删除该记录
git stash pop

# 删除最近的一次stash
git stash drop

当有多条 stash，可以指定操作stash，首先使用stash list 列出所有记录：

1
2
3
4
git stash list
stash@{0}: WIP on ...
stash@{1}: WIP on ...
stash@{2}: On ...

应用第二条记录：

1
git stash apply stash@{1}

pop，drop 同理。

reset –soft

描述

完全不接触索引文件或工作树（但会像所有模式一样，将头部重置为）。这使您的所有更改的文件更改为“要提交的更改”。

回退你已提交的 commit，并将 commit 的修改内容放回到暂存区。

一般我们在使用 reset 命令时，git reset --hard会被提及的比较多，它能让 commit 记录强制回溯到某一个节点。而git reset --soft的作用正如其名，--soft(柔软的) 除了回溯节点外，还会保留节点的修改内容。

命令使用

应用场景：回溯节点，为什么要保留修改内容？

应用场景1：有时候手滑不小心把不该提交的内容 commit 了，这时想改回来，只能再 commit 一次，又多一条“黑历史”。

应用场景2：规范些的团队，一般对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现问题排查。本来属于两块不同功能的修改，一起 commit 上去，这种就属于不规范。这次恰好又手滑了，一次性 commit 上去。

学会reset --soft之后，你只需要：

1
2
# 恢复最近一次 commit
git reset --soft HEAD^

reset --soft相当于后悔药，给你重新改过的机会。对于上面的场景，就可以再次修改重新提交，保持干净的 commit 记录。

以上说的是还未 push 的commit。对于已经 push 的 commit，也可以使用该命令，不过再次 push 时，由于远程分支和本地分支有差异，需要强制推送git push -f来覆盖被 reset 的 commit。

还有一点需要注意，在reset --soft指定 commit 号时，会将该 commit 到最近一次 commit 的所有修改内容全部恢复，而不是只针对该 commit。

cherry-pick

描述

给定一个或多个现有提交，应用每个提交引入的更改，为每个提交记录一个新的提交。这需要您的工作树清洁（没有从头提交的修改）。

将已经提交的 commit，复制出新的 commit 应用到分支里

命令使用

应用场景

commit 都提交了，为什么还要复制新的出来？

应用场景1：有时候版本的一些优化需求开发到一半，可能其中某一个开发完的需求要临时上，或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit 抽出来，单独处理。

应用场景2：有时候开发分支中的代码记录被污染了，导致开发分支合到线上分支有问题，这时就需要拉一条干净的开发分支，再从旧的开发分支中，把 commit 复制到新分支。

1
2
3
4
5
6
7
8
9
10
11
# 复制单个
git cherry-pick <commitHash>
# 复制多个
# 一次转移多个提交
git cherry-pick commit1 commit2
# 多个连续的commit，也可区间复制
git cherry-pick commit1^..commit2
# 当有冲突时想放弃 cherry-pick，回到操作前的样子，就像什么都没发生过
git cherry-pick --abort
# 退出 cherry-pick，不回到操作前的样子。即保留已经cherry-pick成功的 commit，并退出cherry-pick流程
git cherry-pick --quit

revert

描述

给定一个或多个现有提交，恢复相关提交引入的更改，并记录一些这些更改的新提交。这就要求你的工作树是干净的（没有来自头部的修改）。

将现有的提交还原，恢复提交的内容，并生成一条还原记录。

命令使用

应用场景

应用场景：有一天测试突然跟你说，你开发上线的功能有问题，需要马上撤回，否则会影响到系统使用。这时可能会想到用 reset 回退，可是你看了看分支上最新的提交还有其他同事的代码，用 reset 会把这部分代码也撤回了。由于情况紧急，又想不到好方法，还是任性的使用 reset，然后再让同事把他的代码合一遍（同事听到想打人），于是你的技术形象在同事眼里一落千丈。

1
2
# revert 普通提交
git revert <commitHash>

生成了一条 revert 记录，虽然自己之前的提交记录还是会保留着，但你修改的代码内容已经被撤回了。

1
2
3
# revert 合并提交
# -m 后面要跟一个 parent number 标识出"主线"，一般使用 1 保留主分支代码。
git revert -m 1 <commitHash>

revert 合并提交后，再次合并分支会失效，这时就需要 revert 掉之前 revert 的合并提交

reflog

描述

此命令管理重录中记录的信息。

如果说reset --soft是后悔药，那 reflog 就是强力后悔药。它记录了所有的 commit 操作记录，便于错误操作后找回记录。

命令使用

应用场景

应用场景：某天你眼花，发现自己在其他人分支提交了代码还推到远程分支，这时因为分支只有你的最新提交，就想着使用reset --hard，结果紧张不小心记错了 commitHash，reset 过头，把同事的 commit 搞没了。没办法，reset --hard是强制回退的，找不到 commitHash 了，只能让同事从本地分支再推一次（同事瞬间拳头就硬了，怎么又是你）。于是，你的技术形象又一落千丈。

1
2
3
update(c,自己错误的提交)
update(b)
update(a)

分支记录如上，想要 reset 到 b。

误操作 reset 过头，b 没了，最新的只剩下 a。

这时用git reflog查看历史记录，把错误提交的那次 commitHash 记下。

再次 reset 回去，就会发现 b 回来了。