git常用知识实战

陪你一起捡蛋壳

已于 2023-09-28 16:08:56 修改

阅读量998

点赞数

分类专栏：工具类文章标签： git github

于 2021-10-22 17:01:03 首次发布

本文链接：https://blog.csdn.net/qq_18218071/article/details/120909549

版权

工具类专栏收录该内容

11 篇文章 1 订阅

订阅专栏

0.基础

创建本地分支 git branch branch_name
删除本次分支 git branch -d/D branch_name (-D 强制删除)

1.本地分支和远程分支建立关系

git branch --set-upstream-to=origin/feature/V100 （最好先执行 git fetch）

场景1：直接从本地分支建远程对应的分支（不能实现建不同名分支）：
当前在本地分支：feature/V100
如果执行git push origin feature/V100，那么如果远程不存在同名分支，将创建同名分支并完成提提交
注意：此时虽然提交了，但是本地分支仍然没有和远程分支建立关系
有两种方式（一样的作用）：git branch --set-upstream-to=origin/feature/V100 和 git push --set-upstream origin feature/V100

场景2：直接从远程分支建本地对应的分支：
拉取远程分支，并在本地建同名分支（此时也完成了建立关系）
git checkout -b feature/V100 origin/feature/V100
主要：最好先git fetch，获悉远程有哪些分支。

场景3：本地分支和远程分支映射关系（都已经创建）
1.同名：本地分支：feature/V100 远程分支：feature/V100 ：直接执行：git branch --set-upstream-to=origin/feature/V100 或者 git push --set-upstream origin feature/V100
2.不同名：本地分支：feature/V200 远程分支：feature/V300 ：执行：git branch --set-upstream-to=origin/feature/V300 但是提交git push 并不可以（因为默认只能提交到远程相同名称的分支，要把实现上面的操作：git push origin HEAD:feature/V300）

场景4：直接从远程分支建本地不同名分支：
git checkout -b feature/V100 origin/feature/V200
此时上传也要 git push origin HEAD:feature/V200

通过上面可以发现： git push origin HEAD 是一个上传很大的功能，他可以指定任何分支上传，所以使用要特别注意。

工具命令：
git branch -vv ：查看本地分支和远程分支映射关系
git branch -r ：查看远程分支
git branch -a：查看所有分支

2.git pull 和 git fetch的区别

git fetch 是把远程仓库的分支拉到本地仓库，此时不会发生合并操作。
git pull 是把远程仓库的分支拉到工作站，并完成合并到当前分支上（可能产生冲突）
例如：git fetch origin feature/V100 把远程分支feature/V100拉到本地仓库，并FETCH_HEAD指向远程分支feature/V100，此时可以查看该分支上的日志 git log -p FETCH_HEAD
然后可以把该分支合并到当前分支：git merge FETCH_HEAD （把远程分支的变化合并到当前分支）
而：git pull就是 git fetch + git merge
当然也可以 git merge origin feature/V100 直接把远程分支feature/V100合并到本地分支上。
注意：如果直接git fetch，不加分支，是把远程仓库所有的分支变化都拉到本地仓库（这个时候FETCH_HEAD不指向任何分支，git merge是无用的）

3.忽略文件本次所有的修改

git checkout – inc-medicine-web/Main.java

4.push操作

默认git push把当前分支推到对应远程分支上。
把新建的本地分支feature/V100 推到远程服务器的feature/V100分支：git push origin feature/V100
把新建的本地分支feature/V100 推到远程服务器，远程服务器分支名为feature/V200：git push origin feature/V100:feature/V200
将当前分支推送到源存储库中的远程引用匹配主机。这种形式方便推送当前分支，而不考虑其本地名称 git push orgin HEAD:master
删除远程分支 git push origin -d feature/V100
强制上推送：git push -f

5.rebase操作

该功能和git merge相似，都是用来合并分支的，但是有独到之处。（注意该命令最好都是本地分支，而且是合并两个分支分叉后所有提交，如果自己对代码中间逻辑记不清了，中间合并是很痛苦的。）
git rebase：主要的功能是把每个人提交的日志放在一起，便于梳理管理；合并过程是一步一步合并的。
git merge：是按照提交的时间合并的，这样就可能导致大家的代码是交织在一起，不好管理；合并过程是一次完成。
git rebase：步骤是 1.把本分支已经提交的内容，都去掉，然后保存到一个缓冲区中。 2.把要合并的分支内容合并到本分支上。 3.把自己保存到缓冲区中的提交一个一个应用到当前分支上【注意此时可能会产生冲突：第一种就是你和别人改了相同的内容，第二种就是由于第一种解决后的文档，与自己的下一个合并又冲突了】【例如：比如a.txt 别人改动第100行的文档，你第一次提交也改动了第100行的内容，你的第二次提交也改动了第100行内容，原来本地自己第一次和第二次都修改了100行代码提交是没有问题的，此时执行rebase先触发第一种冲突即：先把别人修改的内容应用到分支上，然后把你本地第一次提交的内容应用到分支上，造成冲突；解决冲突后，再把本地第二次提交的内容应用到分支上，由于第100行变化了，又会冲突，继续解决冲突，直到完成合并】
通过上面可以发现：就是你自己的提交是应用在别人提交之后，这就在日志上看似，各个人提交的内容都在一块，利于管理。
注意：如果在git rebase前已经把代码push到远程仓库了，也就是日志不能变更了，在执行git rebase后，（重新把自己的原来的commit再次加入到当前分支上），所以，push到远程仓库会出现两次自己的commit日志，但是代码还是最新的代码。（也就是只要push了，日志都是固定了，不能修改了）
其他相关命令：
一般的流程是：
git rebase feature/V200 (把feature/V200 合并到当前分支上）
如果有冲突：修改冲突，然后 git add . （不需要git commit）
git rebase --continue 继续应用下个提交，直到结束。（如果进入vim，就是处理上次冲突，需不需要更新下commit文档，q!推出）
git add . 把本次冲突添加到index中（注意不需要git commit）
git rebase --abort 直接回到git rebase命令之前，也就是取消git rebase（发现合并中出现很多记不得修改，想退出原来的状态，这是很好的）
git pull --rebase origin/feature/V200 (把远程分支feature/V200 合并到当前分支上）

6.修改注释（不能是已经push的commit）

已经push的commit是不可以变更的。当然已经push过的，也是可以改的，但是其实相当于在增加一个注释，此时已经和远程仓库不一样了。
修改最后一次commit注释：git commit --amend （然后在命令行输入最新的注释就覆盖原来的最后的注释了）
修改过去commit的注释：
第一步：git rebase -i HEAD~2 （2是表示要更改最近2次提交的注释，此时只是给出一个范围）
第二步：此时会出现日志，例如：pick aksdsadkf message-one； pick 8sdfk9jsaf message-two；就是最近两次的注释；把要修改的注释的 pick改成edit，此时只是告诉git你想改动该注释，然后保存。
第三步：git commit --amend 此时会跳出你标记为edit的注释，你可以改动了，保存
第四步：git rebase --continue 直到所有标记edit的注释，修改完后，在执行一次 git rebase --continue 结束

7. 合并多个commit

和修改注释类似，但是用到不同rebase的命令
第一步：git rebase -i HEAD~5 （5是表示要更改最近5次提交的注释，此时只是给出一个范围）
第二步：此时会出现日志，例如：pick aksdsadkf message-one； pick 8sdfk9jsaf message-two ；…. 就是最近5次的注释；把需要合并commit的pick改成squash，此时只是告诉git，这个commit要和他前面commit（比他时间更高的commit）合并在一起，然后保存。
第三步：此时将出现要合并的commit，然后修改组合在一起的commit信息，（他们的代码也会进行合并）。
第四步：如果还有其他要合并的，git会自动跳到下个要合并的过程，直到完成（不需要 git commit --amend 和git rebase —continue）

squash：保存后，还是会跳出来，也就是第三步，修改组合在一起的commit信息
fixup：保存后，就不会到第三步，直接把原来的commit信息去掉
drop：保存后，就是把commit信息和提交的代码同时去掉，可以与后面的提交冲突

例如下图：最新的commit是00000，然后是add**** ，最后是9999
在这里插入图片描述
现在要把00000和add**** 都合并到9999中，最后变成9999****0000
首先改成pick到squash

然后修改最后的9999****0000

最后的结果：

8. git stash

相应的模块还没有完成，不想commit（一个commit一般都是一个独立功能模块），但是要做其他紧急的工作
应用场景：1：正在做本版本的工作，但是生产上有bug修复，但是不想提交（commit）现在的工作
2：本应该在work分支工作，结果不小心在master上工作（污染了master代码），可以把mster上没有提交的代码stash，然后放到work上
1.把没有提交的工作保存到堆栈区： git stash save “first stash”，也可以不加名： git stash （此时会有一个对应标识stash@{}）
2.列出所有的堆栈区： git stash list
3.把堆栈区的代码放到当前分支上：git stash apply + stash名字（stash@{}）可能有冲突：按照一般冲突方法解决例如：git stash apply stash@{0}
git stash apply ：默认应用最后一个stash
4.删除堆栈区的代码块 git stash drop stash@{0}
5.清空所有的stash：git stash clear

9. git reset 版本回退到特定版本（之后的版本内部不要了）

这些回退都是在本地仓库操作，不是操作远程仓库，要操作远程仓库，建议拉下来单独分支，然后回退，再提交。
以前提交的commit信息也会消失，所以git reset适合是回退到特定的版本，版本后面的内容不要了。
本地仓库回退两个版本，但是这两个版本的内容仍然存在在工作区中：git reset commit_id
本地仓库回退两个版本，但是这两个版本的内容在工作区也就清空了（消失术），此时代码在原来倒数第三个提交上： git reset --hard commit_id
注意：建议使用commit_id（回到commit_id版本上，commit之后的消失）不建议使用HEAD，自己会迷。

10.git revert 删除特定版本（提交）

适用于中间某个版本出现错误，想要该版本的内容去掉，但是不影响后面的版本提交。
git revert commit_id
commit_id是回退的版本commit的id。
可能会有冲突，因为后面的版本，可能也修改该内容了，解决冲突后，提交就可以。

11.查看特定文件修改的过程

第一步：查看该文件所有修改的commit_id ：git log --pretty=oneline fileName
第二步：通过commit_id 获取对应的修改的代码： show log commit_id
或者：
查看文件改动的过程：git log -p fileName

12.冲突的文档

<<<<<<< HEAD
        System.out.println("111");   //合并其他人的代码
=======
        System.out.println("222");  //自己本地的代码
>>>>>>> 13ca54f (v2 222)

13.本地项目直接推送到git仓库

第一步：首先本地提交所有要提交的代码 git add . 和 git commit -m "xxxx"
第二步：推送代码到中央仓库：git remote add origin path_git_rep 其中：path_git_rep就是中央仓库的地址
这一步可能有错误：远程 origin 已经存在, 那么执行git remote rm origin, 然后再次执行第二步
第三步：git push -f origin master