git常用操作汇总大全

• 👏作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，入职小红书广告投放开发，很高兴认识大家
• 🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦
• 🍂博主正在努力完成2024计划中：校招入职，稳扎稳扎
• 📝联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬👀

前言

对于程序员来说，熟练的掌握git操作是最基本的东西了，只不过会被大多数校招生或者刚工作的人所遗漏，总是过分的关注技术，但是连基本的git操作都不曾熟练掌握，因此本文章在这里为大家介绍一下。

工作中git基本操作

git配置

首先需要安装git 并且配置 git的一些基本信息（这些信息一般公司都会提供，所以按照公司要求配置即可）

idea中使用git拉项目

一般来说 配置好了以后，从idea中远程 clone到本地，需要，file --> new --> Project from Version Control 填写好对应的clone地址即可。

此时项目就clone下来了。其实针对git来说 操作其实就有数的几个 add commot push，以及每次都要去master pull下来最新的分支。但是针对这种情况又会有多种操作，比如说merge 和 rebase（重点）。

git约定俗成

按照约定俗成，一般来说，每次开发新需求都要新建一个新的分支，具体的分支命名要按照项目 + 团队的风格！！！（这个很重要）

新分支都是从master创建的，理论上新分支push上的版本其实是优先于master的，但是会出现这样的一种情况，因为大家都是多个分支并行开发，别人的分支合并进master，而你自己的分支还是依赖于之前的master。

出现以上这种问题，说明master分支的代码领先于自己的分支,此时需要将master分支代码合并到自己的分支上。因为在我的分支正在开发中，同事完成的分支被合并了，此时的master又被更新了一次，而我的分支仍然是没有合并同事之前的master，所以此时我的分支就落后于master了，所以此时我需将master上的新代码合并到我自己新建的分支上来。

这个其实就涉及到了两个比较关键的技术了，merge 和 rebase。

git stash

git stash的功能其实概括起来就是，当前的分支还没有commit，但是需要切出去，所以需要暂存下这些修改，毕竟如果还没有commit的话，你切出去，实际上本次修改的代码其实就没有了，通过这种方式，可以很方便的切出去，等到切回来的时候，使用git unstash即可。

给大家举一个例子吧。

比如说你正在开发一个新分支，但是远程的master更新了，但是你本地的master还没有更新，那么你提交代码的时候，你肯定是要和线上最新的master合并了，然后再提交自己的新分支呀。那么这个其实就能用到了git stash了。

首先git stash，然后切换master，然后pull master更新，然后切换回去新分支，git unstash，然后merge合并master的变更，然后解决文件冲突，然后push，这样就能保证新分支时依赖于最新的master版本。

merge的常见问题

修改远程仓库代码：

修改本地仓库代码：

提交本地仓库代码并拉取，发现代码产生冲突，点击Merge进行合并：

点击箭头将左右两侧代码合并到中间区域：

冲突合并完成后，点击Apply生效：

提交代码并推送到远程。

git提交版本

点击idea左侧的git就能看到各个分支的版本历时树了。

单击左下角git即可。还是和 git stash相关的是，如果切换出去分支就要add commit一次，那么其实就会在git 提交版本历史中有一个不美观的版本结构树。因此还是需要广泛使用git stash 和 git unstash

git 回滚

这个功能是有的时候，一不小心在master分支上，git unstash了一下，导致错误了merge冲突，这个时候，完全可以点击 git rollback，然后回滚回去就可以了。

git 更新最新的分支情况

b新分支push上去了，a分支待合并，但是在merge中找不到对应push上去的b分支，针对这种情况，需要在idea上的控制台输入：git fetch

新分支每次push前是基于最新的master

每次push分支之前，都需要和 master merge一下，防止给别人带来额外的merge冲突。

merge 和 rebase（具体内容都是参考博客：流浪在世界的博客内容，图片也是借用，再次声明！！！）

rebase本质点来说可以使得你的代码的版本提交树是线性的，而merge却不是，会有很多分叉，感觉不太美观，当然最终怎么样取决于 团队开发的约定俗成。

git rebase应用

先准备好一个主基线：

在此基础上创建一个分支：名字为fenzhi_1，创建另一个分支，名字为fenzhi_2

最开始fenzhi_1和fenzhi_2以及master的基线是同一个。

同一分支的rebase操作

当前分支为fenzhi_2，共有三个提交记录:

在第一次修改上进行右击鼠标：选择图中的选项，翻译一下就是在此处进行交互式改变基址。
交互式可以理解为可自定义的选择不同rebase行为进行操作。

然后就会出现这个页面，点击squash进行合并即可。

执行结果看一下：

如果自己分支的几个提交都是本地的，还没有提交到远程分支fenzhi_2上，那么就可以直接push推到远程,但一般我们总要合自己代码到dev/test,所以必然是已经提交到自己远程分支上了, 此时当你去push你的commit时，会再次与你远程分支的commit合并，之前本地rebase的那些commit又会出现了。

若选择force push呢，翻译过来就是强制推送，看一下操作结果：有个提示，翻译一下就是：强制推送，可能会覆盖远程服务器的提交。

在push中选择 force push。

若这个远程分支只有你一个人在开发：强制推送是可以的，没有人会在你rebase没完成时提代码，可以直接理解为用你本地分支的状态区覆盖掉远端origin分支的状态，也就是执行过后，本地的分支什么样，远端分支就什么样

分支跟master之间的rebase操作

Rebase的本意是改变基线，意思就是当从master拉取的分支1开发一段时间后，master也提交了几个版本，这就使得分支1的基线与现在的master不是同一个版本。需要将分支1的基线改成最新master。那就需要rebase操作了。看案例效果：

看一下fenzhi_2的基线是在提交id为1639f5db的基础上拉的分支，然后做了俩次变更

再看一下master的提交记录：master在 1639f5db上提交了一次变更。

这就造成了fenzhi_2的基线不是最新的master了，现在要将fenzhi_2的基线改为提交id为f7ec72e7，看下面操作
本地分支改为fenzhi_2：

在master上右击鼠标：第二步操作翻译一下就是在master基础上改变fenzhi_2的基线。

点击操作：若看到有冲突，手动处理一下即可，

可以看到同一个位置都有改动，这就根据实际情况合并代码了，这里我的目的是master的改动和本分支的改动都要保留。

解决完后，会自动弹出一个窗口：是提交信息的修改，这个也是根据实际情况定，这里我不改，点击继续rebase。

看结果：提交id为f7ec72e7的成为了fenzhi_2的基线。

接下来push：可以看到push有俩个操作，一个push一个是force push（强制推送）。

若分支是自己使用，那我们就强制推送。本地的分支提交记录覆盖远程的。

上面的操作是分支改变基线，那反过来操作呢，在master上rebase呢。

看一下分支fenzhi_3：这个分支做了俩次变更

Master也做了俩次变更

在master上进行rebase onto fenzhi_3:

可以看到有个提示：

大概意思就是会对master的提交记录进行修改，看下执行结果：

发现分支的提交记录在master记录之前，这个与merge操作是相反的。继续操作push

可以看到上面提示，若点击合并呢：可以看到分支的提交跟master在一条线上，但最上面又有一条合并记录。

若点击的是rebase呢：可以看到是将分支fenzhi_3的提交放在了最前面。这个操作就模拟了代码merge，但提交记录是一条线。这个才是我们的本意。