虽然说 ”好记性不如烂笔头”,但是学习不看等于没学,学习不用等于不会,所以说”实战才是检验真理的唯一标准“,通过实战则会学到很多东西。
因为陈** 太懒,并且不喜欢查百度,老是犯同样的问题,于是我通过完整的操作git流程和一些实战中的场景,将常用git流程和命令整理了下来,这样也方便我女盆友带入学习,哈哈哈。
首先,新人进入公司,拉取代码必然先要注册账号,设置自己的环境。俗话说得好:工欲善其事必先利其器,所以配置一个好的环境可以方便自己很多。下面就先配置环境:
下载git就不多说了,陈某某可以看我之前的笔记。然后就是配置git环境了。
首先,您需要配置您的 Git 环境,包括设置您的用户名和邮箱,以便您的提交能够正确归属。
git config --global user.name "Your Name" git config --global user.email "your.email@example.com"
因为Git 的签名设置涉及到用户的姓名和电子邮件地址,以及 GPG 密钥的使用。并且签名用于标识提交的作者和验证提交的真实性。所以设置签名有助于确保提交的真实性和作者的身份,特别是在开源项目中。根据特定的的需求,也可以选择是否使用 GPG 密钥进行更强的签名验证。
并且后续提交代码,也可以通过commit添加签名的提交,比如下面操作:
git commit -s -m "Signed commit" # 进行签名的提交 这样查看log,即使用 git log, 显示结果如下: commit 6e65a67132ae94b9bdc887d72ff87e2f14ac3c9f (HEAD -> main) Author: Your Name <your.email@example.com> Date: Mon Aug 17 12:34:56 2023 +0000 Your commit message Signed-off-by: Your Name <your.email@example.com> GPG Key ID: XXXXXXXX commit a8c7e9d63a44c692e53c6181f2b1b55e523c19fe Author: Another Contributor <another@example.com> Date: Sun Aug 16 15:20:12 2023 +0000 Another commit message Signed-off-by: Another Contributor <another@example.com> GPG Key ID: YYYYYYYY
在这个示例中,每个提交都带有 "Signed-off-by" 行,显示了签名的作者信息和 GPG 密钥的 ID。请将 "Your Name"、"your.email@example.com"、"Your commit message"、"XXXXXXXX" 等想象为实际的信息。
自己的环境设置好之后,就可以通过 Git 命令行或图形界面工具来克隆公司的代码仓库。假设远程代码仓库的 URL 为 https://github.com/yourcompany/repository.git
,就可以执行以下命令来克隆代码仓库:
git clone https://github.com/yourcompany/repository.git
陈童靴,注意复制的时候需要更改一下名称,当然公司的代码库旁边就有git clone(ssh...)等。
默认情况下,您克隆仓库后会在主分支(通常是 master 或 main)上。但根据您的需求,您需要切换到公司给您创建的 dev_new 分支上,通过下面命令进行操作:
git checkout -b dev_new
怎么说呢,就是master分支(近年来,github社区修改为main分支了,因为master有歧义,涉及到一些人权等问题)一般是主分支,项目的发布版本。所以我们克隆到本地后,如果要开发的话,也要切换到自己的开发分支,因为远程自己也有自己的开发分支。所以我个人认为就是和远程保持一致而已。也不要东3自己本地的master分支就好。
一旦切换到 dev_new 分支,也就是自己的开发分支,当然就可以通过以下命令拉取远程分支的最新更改:
git pull origin dev_new
如果在拉取过程中有冲突,需要解决这些冲突。Git 会提示您手动合并冲突的部分。但是首次拉取,一般没有。因为自己远程的dev_new分支也是克隆master分支的,至于所说的冲突就是后面提交代码多了的问题。这个后面遇到再说,我也会给出实战例子的,不要担心。
如果您还想获取其他分支(如 master 或 dev)的更新,您可以切换到相应分支并拉取最新更改,操作如下:
git checkout master git pull origin master git checkout dev git pull origin dev
这种情况一般就是协助同事进行测试操作,所以需要远程拉取别人的分支代码,但是不影响自己的开发分支。这个我后面也会举个例子的。
在您工作的过程中,定期地更新您的本地分支以获取最新的更改。您可以使用 git pull
命令来获取远程分支的更新。就是自己开发的部分会给远程代码提交,当然别人也会提交,为了保持代码的最新,则需要定期update。
以上就是一个整体的流程,其实这样说,懂得都懂,不懂得也是一脸懵逼。所以我为小陈设定了下面一些常见新手会遇到的场景,并且手把手的教练。
小陈喜欢使用Pycharm写代码,觉得非常好用,于是自己写完代码后,进行提交代码,结果架构师反馈,提交的PR有问题,需要修改,但是她不知道为什么会有.idea文件,自己都没有注意,结果把本地的.idea文件夹提交到远程了。
顺便提一句.idea文件:首先,无论是谁开发,使用IDE都无可厚非,毕竟这是一种提升开发效率的软件,而.idea文件就是以”configuration File" 形式存储于Pycharm等IDE工具中的配置文件,也就是说,在创建项目时,IDE会自动生成一个.idea文件夹,目的是存储项目设置相关的文件。.idea文件夹包含了工程相关的元数据,如项目名称,编译器配置,版本控制,项目模板,语言设置,运行配置等等。
废话说完了,那么如何从自己已经提交到自己远程仓库中删除“.idea” 文件及其内容呢。
首先在自己的本地项目目录中,运行以下命令来删除:
git rm -r .idea
然后可以使用git status查看更改状态,当然也可以直接提交更改:
git commit -m "Remove .idea directory"
这里顺带说一下git commit命令。
git commit
是 Git 版本控制系统中的一个重要命令,用于将暂存区中的更改提交到版本历史中。每次提交都会生成一个新的提交记录,其中包含了更改的快照以及相关的元数据。以下是关于 git commit
命令以及常见参数的详细介绍:
git commit -m "Commit message"
常见参数:
-m "Commit message"
:使用 -m
参数后面跟随的字符串作为提交消息。提交消息应该简洁明了地描述本次提交的目的和内容。注意这里少说废话,也不要长篇大论,就简单明了的将自己的问题提交了,比如自己写了什么功能等。-a
:自动将已追踪的修改添加到暂存区并提交。这相当于运行 git add
和 git commit
命令的组合。注意,该选项只适用于已经追踪的文件,对于新添加的文件仍然需要使用 git add
。
-s
:用于签署提交,表示提交的更改已经经过签名验证。通常用于在开源项目中证明提交者的身份。这个之前有介绍,如果使用-s,则提交都带有 "Signed-off-by" 行,并且显示自己的name, email。
-v
:在提交消息中显示当前更改的详细信息,包括差异和更改的行数统计。
示例:
git add file.txt # 将更改添加到暂存区 git commit -m "Fix a bug" # 提交暂存区中的更改并添加提交消息 git commit -a -m "Add new feature" # 添加并提交所有已追踪的更改,包括新添加的文件 git commit -s -m "Signed commit" # 进行签名的提交 git commit # 使用文本编辑器输入详细的提交消息
注意这里,因为是自己删除自己的代码(这里指的是.idea文件夹),所以其实并不需要增加git commit 新写”delete .idea"去覆盖自己之前的commit,可以复用之前的,让别人无需知道自己做了一件蠢事,所以这里则可以使用下面命令:
git commit --amend
进去之后是自己之前的commit,一般情况下不需要修改,如果要修改则进去修改也可以。但是注意,就是该操作会改变你原来的commit id哦。
最后就是push了。
git push origin <branch-name>
其中,<branch-name>
是自己要推送更改的分支名称。
如何一次性解决问题呢,那么就是在本地设置.gitignore文件内容,这样就不会每次提交.idea文件,并且再进行删除操作了。
本地设置的地址是:将自己的.gitignore剪贴到C盘根目录(Windows:C:/User/你的用户名/)
一般项目的根目录下,都会存在一个名为 .gitignore
的文件。但是自己也可以为自己设置一个全局的个人的.gitignore,因为项目的.gitignore可能没有考虑那么到位,如果你不想修改项目的.gitignore,并且自己也不想手动删除,就给自己配置一个吧。
当然我们可以给自己配置专属的其他希望忽略的内容。为此呢,我这里简单的说一下常见的规则,并且给小陈两个模板,一次是如果写C++常用的模板,一个是Python为主的代码。
在.gitignore
文件中,您可以列出希望Git忽略的文件、文件夹或模式。以下是一些常见的.gitignore
规则示例:
忽略特定文件或文件夹:
filename.ext # 忽略特定文件 folder/ # 忽略特定文件夹
2,使用通配符
*.ext # 忽略所有扩展名为 .ext 的文件 folder/*.ext # 忽略特定文件夹中的所有扩展名为 .ext 的文件
3,忽略文件夹及其内容
folder/ # 忽略整个文件夹及其内容
4,排除特定文件或文件夹
!filename.ext # 不忽略特定文件(排除忽略规则) !folder/ # 不忽略特定文件夹(排除忽略规则)
5,忽略编译生成的文件或文件夹
build/ # 忽略编译生成的文件夹 *.o # 忽略所有 .o 文件(编译生成的目标文件)
6,忽略操作系统或编译器生成的文件:
.DS_Store # 忽略 macOS 生成的 .DS_Store 文件 Thumbs.db # 忽略 Windows 生成的 Thumbs.db 文件 *.swp # 忽略 Vim 生成的 .swp 临时文件
这只是一些常见的示例,.gitignore
文件的内容会因项目类型、开发环境和个人偏好而有所不同。您可以根据您的项目需要自定义.gitignore
文件,以忽略不必要的文件和文件夹,并确保仓库中只包含必要的源代码和资源文件。另外,GitHub官方提供了一个.gitignore
模板集合,您可以在GitHub/gitignore上找到针对不同编程语言、开发环境和工具的模板参考。
这里给出两个模板,C++和Pyhton的
C++ 深度学习项目的 .gitignore 文件示例:
# Compiled Object files *.slo *.lo *.o *.obj # Precompiled Headers *.gch *.pch # Compiled Dynamic libraries *.so *.dylib *.dll # Compiled Static libraries *.lai *.la *.a *.lib # Executables *.exe *.out *.app # Build directories _build/ build/ dist/ bin/ tmp/ CMakeFiles/ CMakeCache.txt CMakeScripts/ CMakeTmp/ CTestTestfile.cmake # Visual Studio files .vscode/ *.sln *.vcxproj *.vcxproj.filters *.pdb *.idb *.ipdb *.obj *.db *.tlog *.manifest *.log *.cache *.ilk *.dll *.exe *.log *.suo *.user *.vcproj.* *.opensdf # Xcode files .DS_Store *.xcodeproj/ *.xcworkspace/ # IDE project files .idea/ *.pro.user *.kdev4 # Miscellaneous *.swp *.swo *.tmp *.tmp.* *~ *# .#*
Python 深度学习项目的 .gitignore 文件示例:
# Byte-compiled / optimized / DLL files __pycache__/ *.py[cod] *$py.class # C extensions *.so # Distribution / packaging dist/ build/ eggs/ *.egg-info/ *.egg # Python local environment .env/ # Jupyter Notebook auto-generated files .ipynb_checkpoints/ # PyCharm .idea/ *.iml *.iws *.ipr # Visual Studio Code .vscode/ # Miscellaneous *.swp *~ __MACOSX/ .DS_Store Thumbs.db
上述示例中的 .gitignore
文件会排除编译、构建、临时文件以及 IDE 生成的文件等,以确保您的版本控制仓库保持干净。根据项目的具体情况,您可能需要根据需要进行适当的调整。这些示例只是一些常见的排除规则,您可以根据项目的实际情况进行修改。
之前忘了说.gitconfig文件了,既然都配置了.gitignore文件,那么顺手也配置一下.gitconfig吧。.gitconfig
是 Git 的配置文件,用于设置 Git 的全局配置选项。你可以通过编辑这个文件来配置你的 Git 环境。以下是如何配置 .gitconfig
文件的步骤:
定位 .gitconfig
文件:
.gitconfig
文件通常位于你的用户主文件夹下(例如:C:\Users\YourUsername
)。.gitconfig
文件位于你的用户主目录下(例如:/Users/YourUsername
)。编辑 .gitconfig
文件:
你可以使用任何文本编辑器来编辑 .gitconfig
文件。你可以在终端使用命令行编辑器如 nano
或 vim
,也可以使用图形界面的编辑器如 Notepad(Windows)、TextEdit(macOS)、VS Code 等。
打开终端(或命令提示符)并输入以下命令来编辑 .gitconfig
文件:
git config --global --edit
这将打开默认文本编辑器,并在其中显示 .gitconfig
文件的内容。
关于配置选项:
在打开的 .gitconfig
文件中,你可以设置各种不同的选项,如用户名、电子邮件、默认编辑器、别名等。以下是一些示例配置选项:
[user] name = Your Name email = your.email@example.com [core] editor = code --wait # 设置默认编辑器为 Visual Studio Code [alias] co = checkout ci = commit br = branch
在 [user]
部分设置你的用户名和邮箱,在 [core]
部分设置默认编辑器,在 [alias]
部分设置一些常用的别名命令。
保存文件:
在编辑完成后,保存文件并关闭文本编辑器。
验证配置:
可以使用以下命令来查看当前的全局配置:
git config --global --list
请注意,--global
标志表示这些配置将适用于你的整个 Git 环境。如果你想在特定项目中覆盖某些配置,你可以在项目目录下创建一个名为 .git/config
的文件,其中的配置选项会覆盖全局配置。
下面是一个有经验的 Git 用户使用的 .gitconfig
文件示例。这个示例包含了一些常见的配置,以及一些高级别的配置选项,如颜色设置、别名、分支保护等.
[user] name = John Doe email = john.doe@example.com [core] editor = code --wait # 默认编辑器设置为 Visual Studio Code autocrlf = input # 在提交时转换换行符为 LF [color] ui = auto # 自动启用颜色 [alias] co = checkout ci = commit br = branch st = status hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short [diff] tool = vscode # 使用 Visual Studio Code 作为 diff 工具 [difftool "vscode"] cmd = code --wait --diff $LOCAL $REMOTE [merge] tool = vscode # 使用 Visual Studio Code 作为合并工具 [mergetool "vscode"] cmd = code --wait $MERGED trustExitCode = true [push] default = simple # 默认推送模式设置为 simple [rebase] autosquash = true # 自动折叠 commit [fetch] prune = true # 获取时自动删除远程分支上不存在的分支 [pull] rebase = true # 默认拉取模式设置为 rebase [commit] gpgsign = true # 启用 GPG 签名 [credential] helper = wincred # 使用 Windows 凭据管理器存储凭据 [branch "main"] protection = required-status-checks,strict # 保护分支配置 [core] pager = less -F -X # 设置分页工具为 less 并禁用清屏
我自己的如下:
[user] name = XaaXbb email = XaaXbb@company.com [core] editor = vim autocrlf = input fileMode = false [color] ui = auto [push] default = simple [alias] co = checkout cb = checkout -b cp = cherry-pick cx = cherry-pick -x st = status ss = status -s br = branch ba = branch -a cs = commit -s ca = commit --amend -s df = diff dfca = diff --cached throw = reset --hard HEAD throwh = reset --hard HEAD^ lg = log --oneline --decorate --color logs = log --stat --color dt = difftool mt = mergetool [merge] tool = vimdiff [diff] tool = vimdiff [difftool] prompt = false [log] date = default [filter "lfs"] clean = git-lfs clean -- %f smudge = git-lfs smudge -- %f required = true process = git-lfs filter-process [pull] rebase = true [safe] directory = %(prefix)///AA/BB/CC/..
小陈发现自己刚刚设定好一切后,同时新增加了一些其他无用的东西,但是这次学聪明了,并没有add进去,于是她要删除 Git 中的未跟踪文件,最简单的方法就是git status去查看,然后手动去项目删除,当然作为一个程序员,必须要代码删除,这可是尊严,不是码?
所以可以使用 git clean
命令进行删除。git clean
命令用于清除未添加到版本控制的文件。请注意,git clean
命令是不可逆的,并且将永久性地删除未跟踪文件,请确保在执行该命令之前确认你确实要删除这些文件。
下面简单介绍一下,以下是一些常用的 git clean
命令选项:
-n
或 --dry-run
:显示将要删除的未跟踪文件列表,但不执行删除操作。-f
或 --force
:强制执行删除操作,即使存在只读文件或受保护的文件夹。-d
:同时删除未跟踪的文件夹。-x
:同时删除 Git 忽略的文件。例如,要查看将要删除的未跟踪文件列表,可以执行以下命令:
git clean -n
如果你确定要删除这些未跟踪文件,请使用以下命令进行删除:
git clean -f
如果你还希望删除未跟踪的文件夹,可以添加 -d
选项
git clean -fd
请再次注意,执行 git clean
命令时要小心,以免误删除重要文件。在执行任何 Git 命令之前,请确保已备份你的代码。
小陈做了两天,老板发现其能力确实稍微有些欠缺,就让她先帮忙测试,顺带熟悉项目代码。同时呢,项目组小张写完了一个功能找老板merge,但是老板希望小陈来帮忙测试一下,于是小陈就有新的需求:需要远程拉取小张的dev分支,然后帮助小张测试代码,因为这时候小张的代码并没有merge到master分支,所以小陈需要去拉去小张的开发分支,然后再测试,那么小陈应该如何做呢?
下面简单介绍一下流程,其实和拉取master分支一样。
git branch -r
通过上述命令,可以查看远程仓库的所有分支。
为了让小陈对branch命令有个深刻的印象,下面再复习一下git branch的命令操作:git branch
是一个用于管理和查看分支的 Git 命令。它用于列出、创建、删除和切换分支,以及显示有关分支的信息。
下面是常见的git branch命令及其介绍:
git branch: 显示当前仓库中所有分支的列表,当前分支会用星号标记。 git branch <branch-name>: 创建一个新分支,命名为 <branch-name>。 git branch -d <branch-name>: 删除已合并到其他分支的 <branch-name> 分支。如果分支未合并,此命令会报错。 git branch -D <branch-name>: 强制删除分支 <branch-name>,无论其是否合并。 git branch -m <new-branch-name>: 重命名当前分支为 <new-branch-name>。 git branch -a: 列出本地和远程所有分支的列表。 git branch -v: 列出每个分支的最新提交信息。 git branch --merged: 列出已合并到当前分支的其他分支。 git branch --no-merged: 列出尚未合并到当前分支的其他分支。 git branch --contains <commit>: 列出包含指定 <commit> 的所有分支。 git branch --set-upstream-to=<upstream-branch>: 为当前分支设置上游分支,以便与远程跟踪分支关联。 git branch --unset-upstream: 解除当前分支与上游分支的关联。
下面是常见的git branch命令的示例用法(陈童靴只需要掌握这几个目前就够用了):
创建一个新分支:git branch feature-branch 切换到另一个分支:git checkout another-branch 列出所有分支:git branch -a 删除已合并的分支:git branch -d merged-branch 列出包含特定提交的分支:git branch --contains <commit-hash>
根据上面列出的远程分支,进行复制要拉取的远程分支的名称(也就是找到小张的开发分支),然后创建本地分支
git checkout local_branch_name origin/remote_branch_name
上面代码是根据远程分支创建一个本地跟踪分支。
然后从自己本地的开发分支切换到本地测试分支
git checkout local_branch_name
这样就可以切换到本地分支了。
但是实际上,上面步骤2和步骤3的命令,通过下面代码一步实现
git checkout -b local_branch_name origin/remote_branch_name
说到 checkout命令,当然这也是git中比较重要的命令之一。下面再复习一下 git checkout命令。git checkout
是 Git 中一个重要的命令,主要用于切换分支、恢复文件以及创建新分支等操作。根据不同的用法,它有不同的功能。
以下是一些常见的 git checkout
命令及其介绍:
切换分支: git checkout <branch-name>:将工作目录切换到指定的 <branch-name> 分支。 git checkout -b <new-branch-name>:创建并切换到名为 <new-branch-name> 的新分支。 git checkout -:切换回上一个分支,特别适用于在两个分支之间切换。 恢复文件: git checkout -- <file>:将指定的 <file> 文件恢复为最近一次提交的状态。这可以用于取消工作目录中的修改。 git checkout <commit> -- <file>:将指定的 <file> 文件恢复到指定 <commit> 提 交中的状态。 切换提交状态: git checkout <commit>:将工作目录和暂存区重置为指定的 <commit> 提交状态。您将进入分离头指针状态,用于查看特定提交的内容。 切换标签: git checkout <tag-name>:将工作目录切换到指定的 <tag-name> 标签对应的提交。 切换到特定目录: git checkout --path <directory>:将工作目录切换到指定的 <directory> 目录。这在您只希望检出仓库中的一部分内容时很有用。
下面是常见的git checkout命令的示例用法(陈童靴只需要掌握这几个目前就够用了):
切换到另一个分支:git checkout feature-branch 创建并切换到新分支:git checkout -b new-feature 恢复文件到最近一次提交状态:git checkout -- file.txt 恢复文件到特定提交状态:git checkout abc123 -- file.txt 切换到某个标签对应的提交:git checkout v1.0
本地分支创建好之后,并且切换到测试分支,就可以拉取小张的提交到远程的分支代码了,通过下面命令:
git pull
这样就可以抓取远程同事的最新提交,到本地分支。然后帮助他测试了。
拉取同事的代码测试之后,如果有问题,就要反馈bug,如果问题不大,自己可以debug也是OK的,但是自己有修改则要提交到远程小张分支上,但是这时候我们本地debug的打印代码就要删除了,只留下解bug的代码。
如何删除自己的打印测试代码呢,这时候也可以使用git checkout。
上面介绍提到过,如果您想在Git中撤销对文件的修改(假设是 a.file),您可以使用以下命令:
git checkout -- a.file
这将撤销对 a.file
的修改,将文件恢复到最近一次提交的状态。
如果您想要Git撤销对整个工作目录下所有文件的修改(包括新增的文件和删除的文件),可以使用以下命令:
git checkout -- .
注意:也可以使用下面命令撤销对文件的修改:
git checkout a.file
实际上 git checkout a.file
和 git checkout -- a.file
在大多数情况下是等效的,都可以用来撤销对文件的修改,将其恢复到最近一次提交的状态。两者的区别在于使用 --
的情况。
git checkout a.file
是直接指定了文件名,Git 会将文件恢复到最近一次提交的状态。git checkout -- a.file
中的 --
是一种约定,用于分隔文件名和可能与文件名相同的分支名或提交哈希。使用 --
可以确保 Git 将后面的内容解释为文件名而不是分支名。 在撤销文件修改的场景下,两者的效果是一样的,您可以根据习惯选择使用哪种方式。如果文件名可能与分支名相同,使用 --
可以避免歧义。
请注意,这些命令会永久性地丢弃未保存的修改,所以在使用前请确保您已经保存了需要保留的修改。如果您需要更细粒度的控制,也可以考虑使用 git stash
命令来保存当前的修改,然后再恢复。
除了上面两种用法之外,在Git中,git checkout
命令还可以还原到指定提交的状态,我们上面默认直接回退到上一次提交,而下面加上提交的哈希值就可以回退到指定版本。命令如下:
git checkout <commit> -- <file>
其中 <commit>
是提交的哈希值或者分支名,这个命令可以用来从指定的提交中获取指定文件的副本,相当于撤销该文件的所有后续修改,将其还原到指定提交的状态。
既然要查找哈希值或分支名,那么如何做呢? 这里再补充一个概念,就是log查找。这里介绍两个命令,git log 和 git reflog。
git log
和 git reflog
都是用于查看Git提交历史的命令,但它们有不同的用途和适用场景。
git log
git log
用于查看仓库的提交历史。它会列出所有的提交记录,并按照提交时间的倒序显示,最新的提交在最上面。通过 git log
命令,你可以查看每个提交的作者、提交时间、提交消息以及提交所包含的更改。
适用场景:
示例:
git log
当你使用 git log
命令查看Git提交历史时,会显示一系列提交记录,每个提交记录都包含有关提交的信息,如提交作者、提交时间、提交哈希、提交消息等。以下是一个示例 git log
命令的结果:
commit 5c2d7f6d9b2c7809c26c704a93e4a4e9e4d77e87 Author: John Smith <john@example.com> Date: Fri Aug 12 15:24:18 2022 +0300 Add new feature: user authentication commit 9fbae82f1de89b8a1cfcf65a5e1d29e91e96f489 Author: Jane Doe <jane@example.com> Date: Thu Aug 11 10:57:32 2022 -0700 Fix issue with data processing commit 72b1a3d6f7850d03c3d8c41a013bfef49e614a96 Author: Alex Johnson <alex@example.com> Date: Wed Aug 10 18:42:09 2022 +0200 Update README with installation instructions ...
在这个示例中,每个提交记录都包含以下信息:
通过查看这些提交记录,你可以了解项目的开发历史,包括谁在何时做了哪些更改。这对于跟踪项目的演变和查找特定更改非常有用。请注意,实际的 git log
输出可能会更长,具体的提交信息会根据项目的不同而有所变化。
git reflog
git reflog
用于查看本地仓库的引用日志,包括分支、HEAD、标签等的变更历史。这包括了所有的引用操作,比如分支切换、提交、合并等。git reflog
通常用于恢复误操作或找回丢失的提交。
适用场景:
示例:
git reflog
以下是一个示例 git reflog
命令的结果:
5bf6542 (HEAD -> feature-branch) HEAD@{0}: checkout: moving from develop to feature-branch 827f564 (develop) HEAD@{1}: commit: Update file1.txt e4824b3 HEAD@{2}: commit: Fix issue #123 3a17d98 HEAD@{3}: checkout: moving from master to develop 1f0b2c6 HEAD@{4}: commit: Add new feature ...
在这个示例中,每个条目都包含以下信息:
git reset
或 git cherry-pick
等操作。 下面给一个结合 git reflog
的结果进行 Git 调用的示例:
1,恢复意外删除的分子
假设你意外删除了一个分支,而现在想恢复它。你可以使用 git reflog
找到删除前的提交哈希,然后重新创建分支。
git checkout -b recovered-branch 827f564
这会创建一个名为recovered-branch
的新分支,并将它指向提交 827f564
。
2,找回丢失的提交
如果你切换分支或进行操作后发现之前的提交消失了,你可以使用 git reflog
找回这些提交。
git checkout -b temp-branch e4824b3
这会创建一个临时分支 temp-branch
并将其指向提交 e4824b3
,从而使你能够检查丢失的提交
3,撤销操作
如果你意外执行了一个操作(如合并或重置),你可以使用 git reflog
找到之前的操作,然后通过 git reset
或其他适当的命令进行撤销。
git reset --hard 1f0b2c6
这会将当前分支重置到提交 1f0b2c6
,并将工作目录和索引回滚到该提交状态。通过结合 git reflog
的结果,你可以更好地理解本地仓库的引用变更历史,并使用相应的 Git 命令进行恢复、找回或撤销操作。这对于纠正错误或恢复意外操作非常有用。
最后总结一下:在实际使用中,git log
用于查看提交历史,帮助你理解项目的发展和更改。而 git reflog
则是在需要恢复误操作或追踪引用变更历史时使用的工具。通常情况下,你会更频繁地使用 git log
,而 git reflog
则是一个辅助工具,用于处理特定的场景。
希望小陈不会再犯这些小错误,当然git使用的熟悉后,可能会遇到更麻烦的事情,这时候查看git官网会更好。我这里只是简单的总结了一下小陈(一个初学者)遇到的小问题而已,如果各位看官看到了,请轻喷,谢谢!
通过strimzi部署的kafka集群,如何部署prometheus+grafana去监控呢?官方文档信息量太大,即便照着做也可能失败,这里有一份详细的保姆级操作指南,助您成功部署监控服务
本文通过docker快速部署elasticsearch8版本,再添加一台组成集群,并且部署kibana用于常规查询操作,以及一些常见的es操作