Git相关的命令

发布于:2025-09-03 ⋅ 阅读:(19) ⋅ 点赞:(0)

目录

整体框架

本地仓库

配置Git

认识工作区,暂存区,版本库

版本回退

撤销代码

删除文件

分支管理

分⽀管理策略

bug 分⽀

删除临时分⽀

远程操作

标签管理

整体框架

上述图片展示了 Git 版本控制系统的基本工作流程和各个组件之间的关系。它分为四个主要部分:Remote(远程仓库)、Repository(本地仓库)、Index(暂存区)和 Workspace(工作区)。用户通过 fetch/clone 从 Remote 获取代码到本地 Repository,然后在 Workspace 进行修改,使用 add 将更改添加到 Index,再通过 commit 提交到 Repository。最后,可以通过 push 将本地的更改推送到 Remote,或者用 pull 同步 Remote 的最新更改到本地。checkout 则用于切换分支或恢复文件状态。整个流程确保了代码版本的管理和团队协作的高效性。

本地仓库

仓库是进行版本控制的一个文件目录,此时你所创建好的目录之中会多出一个”.git“隐藏文件

git init //创建方式,要在你创建的目录之下进行创建

配置Git

我们需要设置自己的用户名和邮箱,以便后续可以与远程仓库进行连接。

git config --global user.name "name"
git config --global user.email "email"
//此处的 --global 是指全局配置,如果只想在特定文件中进行配置去掉即可,但要注意配置必须在仓库中进行配置
git config -l //查看配置
git config --global --unset user.name //删除配置

忽略特殊⽂件

在⽇常开发中,我们有些⽂件不想或者不应该提交到远端,⽐如保存了数据库密码的配置⽂件,那怎么让 Git 知道呢?在 Git ⼯作区的根⽬录下创建⼀个特殊的 .gitignore ⽂件,然后把要忽略的⽂件名填进去,Git 就会⾃动忽略这些⽂件了。不需要从头写 .gitignore ⽂件,gitee 在创建仓库时就可以为我们⽣成,不过需要我们主动勾选⼀下。

如果当时没有选择这个选择,在⼯作区创建⼀个也是可以的。⽆论哪种⽅式,最终都可以得到⼀个完整的 .gitignore ⽂件,例如我们想忽略以 .so 和 .ini 结尾所有⽂件, .gitignore 的内容如下:

# 省略选择模本的内容
...
# My configurations:
*.ini
*.so

在 .gitignore ⽂件中也可以指定某个确定的⽂件。最后⼀步就是把 .gitignore 也提交到远端,就完成了。

git add -f [filename]  //强制添加被忽略的文件
git check-ignore -v a.so //a.so ⽂件是要被添加的,但是没被添加,查看原因

把指定⽂件排除在 .gitignore 规则外的写法就是 ! +⽂件名,所以,只需把例外⽂件添加进去即可。

# 排除所有.开头的隐藏文件:
.*
# 不排除.gitignore
!.gitignore

给命令配置别名

git config --global alias.st status //将 git status 简化为 git st
git config --global alias.last 'log -1' //配置⼀个 git last ,让其显⽰最后⼀次提交信息

认识工作区,暂存区,版本库

工作区(workspace):在电脑上你要写代码或者文件的目录。

暂存区(index):stage或者index,一般存放在.git/index中,我们也叫他索引。

版本库(repository):这里就是指.git这个隐藏目Git的版本库,他可以管理这个版本库又叫仓库里面的所有文件,可以跟踪文件的修改、删除等,可以追溯版本做到还原。

注意:通过在workspace新建或粘贴进去文件,并不能称为向仓库中新增文件,而只是在工作区中增加了文件,我们要通过如图进行add和commit命令提交到repositoryGit进行管理。

git add files/dir/. //将工作区中的事务/目录/all提交到暂存区
git commit -m "详情" //将暂存区中的信息提交到版本库,详情即你提交的细节,以便后续可以对自己的操作明了
git log //查看历史提交记录,从上到下,从最新到最远提交,包括提交id date,和详情
git log --pretty=oneline //一行美观查看历史提交记录
//历史提交记录信息中显示一长串的数字字母组合,它可以看作是提交id,commit id Head指向最新一次的commit id 
tree .git/  //树状结构查看,git隐藏目录
里面有几个关键区域
1.index 暂存区,add的内容存在这里
2.HEAD 指向master分支的指针
cat .git/HEAD //查看该路径的信息 显示ref: refs/heads/master 指向master分支
cat .git/refs/heads/master 查询出来的一连串熟悉的字符就是我们最新提交的id
3.objects git对象库,当执行git add 时,暂存区的目录树被更新,同时工作区修改的文件内容写入到对象库中的一个新的区域,就位于.git/objects目录之下
ls .git/objects //列出所有objects目录下的内容,发现是提交的log的commit id的前两位记录,前两位时文件夹名称,后面是文件名称
git cat-file -p "commit id" //查看最新commit id的内容使用这个git cat-flie 是因为该类文件经过sha(安全哈希算法进行过加密)不能直接查看,里面包含tree和parent的commit id
git cat-file -p "tree commitid" 显示gitcode的仓库文件
git cat-file -p "ReadMe commitid" 看 ReadMe 对应的commitid //显示对readme文件的修改内容
touch file //创建文件
cat ReadMe//查看文件详情
git status //查看仓库状态
git diff file //显示暂存区和工作区的文件差异
git diff HEAD -- file //查看版本库和工作区的文件差异
git commit -a //你只修改或删除了已有文件,没有添加新文件。你想快速提交所有当前的修改,而不想手动 git add 每个文件。

版本回退

回退的本质是要将版本库中的内容进行回退,工作区和暂存区是否回退由命令参数决定。

git reset [--soft  |  --mixed  |  --hard]  [HEAD] 

1.--mixed为默认选项,使用时可以不带参数,该参数将暂存区中的内容回退到指定版本,工作区不变。

2.--soft参数对于工作区和暂存区中的内容不变,只是将版本库回退到某个版本。

3.--hard参数将暂存区和工作区的内容都回退到指定版本切记工作区中有未提交的代码时不要使用这个命令,因为工作区会回滚,你没有提交的代码就再也找不回来了。

注意:

1.HEAD可以直接写成commit id,HEAD表示当前版本,HEAD^表示上一个版本,HEAD^^表示上上版本。

2.可以使用~数字表示 HEAD~0表示当前版本,HEAD~1表示上版本。

git reflog //记录本地的每一次命令,如果你在回退版本过程中后悔了,而且还清屏了,可以使用这个命令

撤销代码

1.仅存于工作区中

git checkout -- ReadMe  //用 Git 已知的版本(最近提交或暂存区)覆盖工作区中的 ReadMe 文件,从而丢弃你所有的本地修改。
git restore ReadMe  //一样的意思

2.已经 add ,但没有 commit

git reset HEAD -- ReadMe  //已暂存(staged)的文件移出暂存区,但保留工作区的修改。
git checkout -- ReadMe

3.已经 add ,并且也 commit 了

注意:不要担⼼,我们可以 git reset --hard HEAD^ 回退到上⼀个版本!不过,这是有条件的,就是你还没有把⾃⼰的本地版本库推送到远程。

git reset --hard HEAD^ //直接将全部的东西回退到上一个版本或者指定版本

删除文件

//工作区误删
git checkout -- file5
//确定要删除
git rm file5 
git commit -m "详情"

分支管理

git branch //查看当前本地所有分支
git branch dev  //新建分支dev,此时还未进行操作的情况下指向同一个commit id
git checkout dev //切换分支
git merge dev //合并分支,当前合并是fast-forward模式
git branch -d dev //删除dev分支,在当前的分支下不能删除当前分支
git branch -b dev1 //一步创建并且切换
git log --graph --pretty=oneline --abbrev-commit//
git branch -r  //查看远程分⽀需要加上-r选项
git checkout -b dev origin/dev //基于远程分支 origin/dev 创建一个新的本地分支 dev,并立即切换到该分支。

如果有两个分支都修改了某个文件,就有可能产生冲突,发现⽂件有冲突后,可以直接查看⽂件内容,要说的是 Git 会⽤ <<<<<<<,=======,>>>>>>> 来标记出不同分⽀的冲突内容,

此时我们必须要⼿动调整冲突代码,并需要再次提交修正后的结果!!(再次提交很重要,切勿忘记)。

分⽀管理策略

通常合并分⽀时,如果可能,Git 会采⽤ Fast forward 模式。在这种 Fast forward 模式下,删除分⽀后,查看分⽀历史时,会丢掉分⽀信息,看不出来最新提交到底是 merge 进来的还是正常提交的。不是 Fast forward 模式的好处是,从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀,但依旧能看到 master 其实是由其他分⽀合并得到。Git ⽀持我们强制禁⽤ Fast forward 模式,那么就会在 merge 时⽣成⼀个新的 commit ,这样,从分⽀历史上就可以看出分⽀信息。

git merge --no-ff -m "merge with no-ff" dev2  
//请注意 --no-ff 参数,表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ,所以加上 -m 参数,把描述写进去。

所以在合并分⽀时,加上 --no-ff 参数就可以⽤普通模式合并,合并后的历史有分⽀,能看出来曾经做过合并,⽽ fast forward 合并就看不出来曾经做过合并。

bug 分⽀

假如我们现在正在 dev2 分⽀上进⾏开发,开发到⼀半,突然发现 master 分⽀上⾯有 bug,需要解决。在Git中,每个 bug 都可以通过⼀个新的临时分⽀来修复,修复后,合并分⽀,然后将临时分⽀删除。可现在 dev2 的代码在⼯作区中开发了⼀半,还⽆法提交,怎么办?Git 提供了 git stash 命令,可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。⽤ git status 查看⼯作区,就是⼲净的(除⾮有没有被 Git 管理的⽂件),因此可以放⼼地创建分⽀来修复bug。储藏 dev2 ⼯作区之后,由于我们要基于master分⽀修复 bug,所以需要切回 master 分⽀,再新建临时分⽀来修复 bug,修复完成后,切换到 master 分⽀,并完成合并,最后删除 fix_bug 分⽀,⾄此,bug 的修复⼯作已经做完了,我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀,⼯作区是⼲净的,刚才的⼯作现场存到哪去了?⽤ git stash list 命令看看,⼯作现场还在,Git 把 stash 内容存在某个地⽅了,但是需要恢复⼀下,如何恢复现场呢?我们可以使⽤ git stash pop 命令,恢复的同时会把 stash 也删了。再次查看的时候,我们已经发现已经没有现场可以恢复了。

git stash  //将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。
git stash list  //列出当前仓库中所有已保存的储藏(stashes)。
git stash pop//应用最近一次储藏(stash)的更改,并将其从储藏列表中删除。
git stash apply //应用最近一次储藏(stash)的更改,不会从储藏列表中删除。
git stash drop //最近一次储藏(stash)从储藏列表中删除
git stash apply stash@{0} //多次stash,恢复的时候,先⽤ git stash list 查看,然后恢复指定的stash

但我们注意到了,修复 bug 的内容,并没有在 dev2 上显⽰。Master 分⽀⽬前最新的提交,是要领先于新建 dev2 时基于的 master 分⽀的提交的,所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。我们的最终⽬的是要让 master 合并 dev2 分⽀的,那么正常情况下我们切回 master 分⽀直接合并即可,但这样其实是有⼀定⻛险的。是因为在合并分⽀时可能会有冲突,⽽代码冲突需要我们⼿动解决(在 master 上解决)。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉,因为在实际的项⽬中,代码冲突不只⼀两⾏那么简单,有可能⼏⼗上百⾏,甚⾄更多,解决的过程中难免⼿误出错,导致错误的代码被合并到 master 上。解决这个问题的⼀个好的建议就是:最好在⾃⼰的分⽀上合并下 master ,再让 master 去合并dev ,这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试,⽽不影响 master 。

删除临时分⽀

git branch -D dev3  //强制删除名为 dev3 的本地分支。

远程操作

git clone https://gitee.com/sdf/git.git  //使⽤ HTTPS ⽅式
git clone git@gitee.com:scasa/git.git   //使⽤ SSH ⽅式
git remote  //查看远程库的信息
git remote -v  //查看远程库的信息,更详细
git remote show origin//查看remote地址,远程分⽀,还有本地分⽀与之相对应关系等信息
git remote prune origin//删除了那些远程仓库不存在的分⽀

使⽤ SSH ⽅式克隆仓库,由于我们没有添加公钥到远端库中,服务器拒绝了我们的 clone 链接。需要我们设置⼀下:

创建SSH Key。在⽤⼾主⽬录下,看看有没有.ssh⽬录,如果有,再看看这个⽬录下有没有id_rsa 和 id_rsa.pub 这两个⽂件,如果已经有了,可直接跳到下⼀步。如果没有,需要创建SSH Key

ssh-keygen -t rsa -C "email"

顺利的话,可以在⽤⼾主⽬录⾥找到 .ssh ⽬录,⾥⾯有 id_rsa 和 id_rsa.pub 两个⽂件,这两个就是SSH Key的秘钥对, id_rsa 是私钥,不能泄露出去, id_rsa.pub 是公钥,可以放⼼地告诉任何⼈。

ls -a .ssh/

添加⾃⼰的公钥到远端仓库。

向远程仓库推送

git push <远程主机名> <本地分⽀名>:<远程分⽀名>
//如果本地分⽀名与远程分⽀名相同,则可以省略冒号
git push <远程主机名> <本地分⽀名>
git push origin master//将本地的 master 分⽀推送到 origin 主机的 master 分⽀

拉取远程仓库

git pull <远程主机名> <远程分⽀名>:<本地分⽀名>
//如果远程分⽀是与当前分⽀合并,则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>
git pull origin master

标签管理

git tag [name]  /it tag v1.0  //创建标签
git tag //查看所有标签
git tag v0.9 c6ce3f0 //在指定的commit上打标签
git show [tagname]/git show v1.0 //查看标签信息
git tag -a [name] -m "XXX" [commit_id]//创建带有说明的标签,⽤-a指定标签名,-m指定说明⽂字
git tag -d [name] //删除标签
git push origin <tagname> //推送某个标签到远程
git push origin --tags //全部推送到远端
​
//如果标签已经推送到远程,要删除远程标签就⿇烦⼀点,先从本地删除,然后,从远程删除。删除命令也是push
git tag -d [name]
git push origin :refs/tags/v1.0


网站公告

今日签到

点亮在社区的每一天
去签到