git使用

原创已于 2026-05-03 19:02:01 修改 · 281 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

于 2024-12-24 22:43:29 首次发布

开发板推荐：天空星STM32F407VET6开发板

超高性价比 STM32主控 | 超高主频 | 一板兼容百芯 | 比赛神器 | 沉金彩色丝印

点击查看

本地数据管理区域

工作区：普通文件夹就是工作区
暂存区：临时存储区域，中间区域，用于保存即将提交到git仓库的修改内容，是在git版本控制时一个重要的区域。
本地仓库：git init命令创建的仓库，实际操作的目录。包含完整的项目历史和元数据，是git存储代码和版本信息的主要位置。

修改完工作区文件后需要将其添加到暂存区，再将暂存区的修改提交到本地仓库中.

ls：查看工作区内容

git ls-files：查看暂存区的内容

git status：查看仓库状态

文件存在的几种状态

未跟踪untrack：新创建的还未被git管理起来的文件
未修改unmodified：已经被git管理，但是忘记内容没有发生变换，还没被修改过
已修改modified：已经修改了文件，但未添加到暂存区
已暂存staged：修改以后且已经添加到暂存区域内的文件

简易的命令行入门教程:

Git 全局设置:

git config --global user.name "flying-guy"
git config --global user.email "8410114+flying-guy@user.noreply.gitee.com"

创建 git 仓库:

mkdir kotlin-practice
cd kotlin-practice
git init
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin https://gitee.com/flying-guy/kotlin-practice.git
git push -u origin "master"

已有本地仓库关联远程仓库

cd existing_git_repo
//本地已有仓库关联远程仓库
git remote add origin https://gitee.com/flying-guy/kotlin-practice.git

//查看当前窗口所对应的远程仓库的别名和地址
git remote -v

//把本地的master分支和远程的origin仓库的master分支关联起来，-u是把本地仓库和别名为origin的远程仓库关联起来，master:master把本地仓库的main分支推送给远程仓库的main分支，如果名称一致就可以只写一个
git push -u origin "master"

不保留本地代码强制本地和服务器一致

从远程获取内容可以

git pull

git fetch：只是获取远程仓库的修改，并不会自动合并到本地仓库中，需要手动合并

git fetch --all
git reset --hard origin/分支名

https和ssh的区别

https：在我们把本地代码push到远程仓库的时候需要验证用户名和密码

ssh：不需要验证，需要在git上添加ssh公钥的配置

配置ssh密钥

1.根目录cd .ssh

2.ssh-keygen -t rsa -b 4096

输入文件名test，然后会在用户根目录/.ssh/下生成一个id_rsa密钥文件

3.ls -ltr

生成test私钥文件，test.pub是公钥文件

4.打开公钥文件，复制公钥内容

5.github/gitee的settings->ssh and gpg keys->new ssh key->分别粘贴名字和公钥内容

6.（可选）tail -5 config

意思是当访问github.com时指定使用ssh下的test密钥

推代码4步骤

git pull
git add .
git commit -m"提交介绍"
git push

加上-a表示一个命令完成暂存和提交2个动作

git commit -a -m"feat:1"

-a -m也可以省略成-am

分支管理

git branch：查看本地所有分支

git branch dev：后面跟个分支名就是创建一个新分支

git checkout dev：切到不同的分支

git checkout除了切换分支和状态之外，还可以用来恢复文件或目录到之前的某一个状态，比如之前意外修改了某个文件，可以使用git checkout命令来恢复到修改之前的状态。这个时候如果分支名称和文件名称相同就会出现歧义，git checkout命令会默认切换分支而不是恢复文件，因此可以使用专门的git switch命令

git switch master：切换分支

git merge dev：将不同分支合并到当前分支中。merge后面的分支名称是将要被合并的分支，当前所在分支就是合并后的目标分支。比如需要将dev合并到master，就需要先切换到master，再git merge dev

git branch -d dev：删除分支，-d表示删除已经合并的分支。如果没有被合并又想删除，就需要使用-D命令来强制删除

git log --graph --oneline --decorate --all：查看合并后的分支图

alias ：取别名。可以使用 alias graph="git log --graph --oneline --decorate --all"将该命令定义成一个别名，后面直接输入graph查看图形化的提交记录

合并代码与冲突

冲突：如果2个分支修改了同一个文件的同一个代码就产生了冲突，需要手动解决冲突

预防：预防冲突的方式是自己本地提交前先git pull一下远程分支

产生冲突

基于master拉个dev分支。

修改dev分支的main1.txt文件后又修改master分支的main1.txt文件，然后将dev分支合并到master分支，产生冲突。

解决冲突

git status：查看冲突文件列表

git diff：查看冲突的具体内容

编辑main1.txt文件后重新保存

如果在合并过程中想要终止合并可以使用

git merge --abort

git rebase和git merge的区别

git merge：保留所有提交历史的原貌，创建一个新的“合并提交”来连接两个分支。历史记录是真实的，但可能会显得复杂，适用于公共分支。merge是在master分支执行，将dev合并到master分支
git rebase：重写提交历史，将一个分支的提交“复制”到另一个分支的最新提交之后。历史记录是线性的、清晰的，但不是原始的，适用于本地自己的分支。rebase可以在任意分支执行rebase操作。执行rebase之后最后的结果是一条直线。

如果在dev分支上执行rebase操作，dev分支的2条提交记录直接会变基到master分支上。

如果在master分支执行rebase操作，master的2条提交记录会变基到div分支的末尾。

rebase原理：在git中每个分支都有一个指针指向当前分支的最新提交记录，执行rebase操作时，git会找到当前分支和目标分支的共同祖先，main3节点，再把当前分支上从共同祖先到最新记录的所有提交都移动到目标分支的最新提交后面。从分叉点把整个分支都移动到目标放在的最新提交记录后面

什么时候不能用 Rebase？
永远不要对已经推送到远程仓库（与他人共享）的分支执行 rebase。因为 rebase 会重写历史。只对你本地、未推送的提交进行 rebase。

git rebase使用：

原来分支长这样

将当前dev分支变基到目标的main分支上

git rebase master

将当前master分支变基到目标的dev分支上

git rebase dev

比较差异

回滚

git reset --hard 2131252：将仓库回滚到某一个时间点

git rm --cached filename：把添加到暂存区的文件再取消暂存

git reset：回退版本，可以退回到之前的某一个提交的状态

有3种模式

git reset --soft：回退到某一个版本并且保留工作区和暂存区的修改内容
git reset --hard：回退到某一个版本并且丢弃工作区和暂存区的所有修改内容
git reset --mixed：介于soft和hard这2个参数之间，回退到某一个版本并且只保留修改区的内容而丢弃暂存区的修改内容，mixed是reset命令的默认参数

git relog：如果误操作删除，可以使用这个命令找到提交记录

再git reset --hard xxx：回退到某个记录