git 只会add、commit这几个操作吗？来学点新姿势～

78模板网分享很全面的git命令使用说明。
相信大家在使用 git 的使用过程中，都会遇到一些小问题阻碍你继续下一步，我先说几个，看看你有没有遇到过：
正在写功能但要切分支改 bug;
提交信息手快写错了单词或少提交了代码;
不该提交的东西提交了并推送到远程；
多个提交重复了...。
如果有，那你可以跟着我一起看一下，看看我是怎么解决这些问题的。
或者你会说，我只是简简单单、规规矩矩的git add、git commit、git push，一切都很顺利，那么恭喜你，你很棒！虽然没有遇到啥问题，只是简单的add、commit、push，但你不想提高效率增加摸鱼时间吗？如果想，那就请你随我一起看看，我平时一些使用 git 的技巧。如果能从中得到一两点对你有所帮助的，那么花这 10 分钟时间也就算是赚到了；如果没有，那对不起浪费你10分钟时间了，你可以给我来点你的技巧，让我也学习学习。
先来一张 git 常用命令速查表。

从何说起
我也不太好定位我这篇算是 git 使用指南还是说 git 常见问题记录，所以有点难开头，既然这样，那我就以一个正常的 git 使用（拉代码、提交、推代码）为引导线说起。开始之前先说一下 git 别名配置，因为我有很多简写的操作，怕各位小伙伴看不懂。
配置别名
相信大家都有这种感觉，git 命令这么多怎么会记得住，没错第一次记不住很正常，但如果每天敲一遍，一个月下来就是肌肉记忆了，忘都忘不掉。同时我们也可以为常用的命令设置别名，这样不仅好记，而且便于理解。
比如我会设置 cherry-pick 为 cp，这样感觉就很形象，copy 一条 git 提交记录。
别名配置就是一条命令git config --global alias.a b，这里 --global 表示修改对全局生效，如果不加，只对当前仓库起作用，a和b指对应的别名和 git 命令，以下是我的一些别名配置：
bash复制代码# 配置别名 将commit简写为ci 提交git commit可简写为git ci
git config --global alias.ci commit
git config --global alias.br branch
# 很强大的历史记录 建议试试
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
这篇文章比较用的多的，像：ci代替commit、br代替branch、co代替checkout等。
这些配置都会写入全局 Git 配置文件（存储在用户主目录下的一个隐藏文件.gitconfig）中，我们也可以直接修改这个文件，更加直接。改完这些别名配置之后，你会发现 git 使用变得极度丝滑，妈妈最也不用担心我敲不出 git 命令了 。
可能有的小伙伴会问：那我换电脑了怎么办？
别担心，我也刚换，所以我也遇到了。首先找到 git 的全局配置文件，找到后查看如下所示，也可以控制台直接一条命令git config --global --edit显示全局配置：

然后把 alias 对应的部分（图中框起来的部分）复制过去就行，新电脑照常使用。因为我之前一直是 Windows，最近才换了 Mac，所以我是手敲命令的重度爱好者，不喜欢用工具。但如果用 Mac 的话，也可以使用 on-my-zsh，不过我已经用惯了我自己的这一套，用起来感觉很舒服。
安装 oh-my-zsh 后默认会打开 git 插件，它会在命令行下光标前显示当前分支名称，还可以实现自动补全，输入 git re 按 tab 会自提示可以选择命令，再按 tab 就可以选择命令，方便命令输入。
接下来，我们开始今天的正文吧。
流程一：拉取代码
作为一个新人，你到公司的第一天，领导让你拉项目先跑起来，于是你就：
git clone https://xxx.com/fe/xxx.git
一顿操作，代码运行起来了，这时候领导又说，先跟着谁谁改几天 bug，他用的feat-table这个分支，接着：
bash复制代码# 新建分支
# git checkout -b feat-table
git co -b feat-table
# 拉取代码
git pull origin feat-table
这时候，第一个优化操作就来了，上面两个命令可以用下面这一个命令代替：
bash复制代码# 创建分支并从远程分支拉取代码
# git checkout -b feat-table origin/table
git co -b feat-table origin/table
接着我们开始写代码，进入流程二。
流程二：提交代码前后会出现的问题
这一部分内容较多，请耐心观看✊。
此时，你正开心的写着代码，突然线上出现紧急 bug，其他人都很忙，就你个新来的最闲，领导说让你来改。你一想：”领导给我机会，那我得表现表现，可是我本地的 bug 还没改完，写一半也不好提交啊，肿么办？“。这时候第二个操作stash可以助你：
 先把代码储存在本地缓存
# git stash save "未改完的bug，等下再改"
git ss "未改完的bug，等下再改"
# 切换master 重新拉一个新分支
git co master
# git checkout -b fix-xxx
git co -b fix-xxx
stash 更多操作
git stash # 暂存当前正在进行的工作，比如想 pull 最新代码，又不想加新 commit，或者为了 fix 一个紧急的 bug，先 stash，使返回到自己上一个 commit，改完 bug 之后再 stash pop, 继续原来的工作
git stash save "message" # 暂存时加备注 方便查找
git stash show # 默认显示第一个改动 如果显示其他 git stash show "stash@{1}"
git stash show -p # 改动的具体内容
git stash apply # 恢复第一个存储 恢复其他使用 git stash apply "stash@{1}"
git stash drop "stash@{2}" # 删除stash@{2}存储
git pop # stash apply 和 stash drop 结合体
git stash clear # 清空stash
然后，当你改完这个 bug 之后，提交代码：
 提交当前所有修改文件
# git commit -am "fix: 修复线上紧急buh"
git ci -am "fix: 修复线上紧急buh"
因为你手滑 ，把bug打成了buh，这不能推到远程吧，不然让其他人看到显得你不专业一样，这时候你会想：“我要是能把提交信息修改一下就好了”。这时候第三个操作 amend就浮现在你眼前：
将上次提交的提交信息改为 -m 后的信息
# git commit --amend -m "fix: 修复线上紧急bug" 
git amend "fix: 修复线上紧急bug"
# 推代码
git push
当然，如果你提交后发现少改了一个文件，这时候也可以使用amend来补救一下，我将这里简写为amend -f（修正文件），-f 指 file 文件，这样一看到就挺好理解的：
bash复制代码# 将未提交的代码 添加到暂存区
git add .
# git ci --amend --no-edit
git amend -f
git push
amend 更多操作
amend 直译过来就是"修正"的意思：
只修正文件，不修正提交信息，如提交的时候发现有文件忘记提交，先添加到暂存区，在使用下面的命令进行修正，之后就可以看到提交中已经有了忘记提交的文件
bash复制代码
# git commit --amend --no-edit git ci --amend --no-edit
如果多提交了文件，也可以先通过git rm --cached <文件名>，再通过以上命令修正。
只修正提交信息，如提交时发现写的提交信息不太正确时，可通过以下命令修改
bash复制代码
# git commit --amend -m "feat: xxx" git ci --amend -m "feat: xxx"
修改提交信息和文件
bash复制代码
# git commit --amend git ci --amend
此时，你的 bug 已经修复完，并且代码已经推到远程分支上。但是部署完，找测试看了一下，发现这个 bug 是修复好了，但是又导致出现了另一个 bug，还好你给测试买了一杯奶茶，让她不要在大群里说。然后你立马修复，又得重新提交，可是这要是提交上去，前端老大 review 时看到你的提交记录，"改个bug怎么怎么还多了一个 "，这可怎么办？
这时候教你第四个操作 reset：
 将 HEAD 指向前一次提交 即回退上一次提交到工作区
git reset HEAD~1
# 然后修改代码 重新添加到工作区提交
# git commit -am "fix: 修复线上紧急bug"
git ci -am "fix: 修复线上紧急bug"
此时，再往远程推送代码时，因为你本地的提交记录和远程提交记录已经不同了，需要使用git push -f操作将远程的提交覆盖掉，直接 push 的话因为与远程提交不一致，没法推到远程，所以使用git push -f强制将本地提交同步到远程分支。

切记：慎用 push -f
reset 更多操作
git reset 通过控制 HEAD 应该指向的位置，来达到重置的目的。
软重置 soft
假如已经提交的文件有问题，想撤销提交，但又想保留文件，这时候就可以使用软重置将 HEAD 指向前一次提交，然后可以重新修复并提交； 也可以使用 commitId 退回到某次指定的提交。
bash复制代码
# 撤销上一次提交 HEAD～2/3 撤销前两次/三次提交 git reset --soft HEAD~1` # 退回到某次提交 git reset commitId
硬重置 hard
有时候并不想保留特定提交引入的修改，Git 应该直接将整体状态重置到特定提交之前的状态，使用git reset --hard HEAD~1。
这时候代码已经推到远程分支，需要你提一个 mr 给项目负责人，然后他去合并代码，如果他直接 merge 的话，master 分支会产生一条额外的合并记录Merge branch 'xxx' into 'master'。 如果换我来合并的话，我会选择教你第五个操作 cherry-pick：
 将指定提交拣选到master分支
# git cherry-pick commitId
git cp commitId
cherry-pick 可以帮助我们实现代码迁移，但是需要提交功能明确，不要参杂太多的东西。cp 是 cherry-pick 的简写，copy 复制提交，是不是很好记 。
到这里，一次 bug 的修复过程就算完成了。接着用checkout切回自己的分支继续之前的工作:
bash复制代码# git checkout feat-table
git co feat-table
假设你的分支名称很长：feat-table-wx-230503，你要切回来的话还得复制分支名称，然后再切，不妨试试这第六个操作 checkout -
git checkout - 快速切回上一个分支
bash复制代码# git checkout -
git co -
然后我们将刚刚改 bug 的分支删除：
bash复制代码# -d 只有分支合并并推送后才可以删除
# -D 是 --delete --force 的别名，无论任何情况下都可以删除
# git branch -D fix-xxx
git br -D fix-xxx
如果想要删除远程分支，则可以直接从 gitlab 的分支中删除，或者我们可以通过第八个操作 push origin --delete
git push origin --delete xxx 删除远程 xxx 分支
bash复制代码# 删除刚刚的修改bug分支
git push origin --delete fix-xxx
更多分支删除操作
bash复制代码# 删除分支名包含fix的分支
# git branch | grep 'fix' | xargs git branch -d
git br | grep 'fix' | xargs git br -d
# 删除除feat-table外所有的分支
# git branch | xargs git branch -d feat-table
git br | xargs git br -d feat-table
接着，你先用git stash pop把feat-table分支上储藏的代码先弹出来，接着一顿操作，完了推送代码到远程，当你执行 git push 的时候，发现远程仓库有修改，git 会提示你先执行 git pull 拉代码时，只要有冲突提示你修改，然后改完之后，git 会帮你自动合并生成一次提交，类似这样Merge branch "fix-table' of
https://git.qmpoa.com/fe/qtable_docs into fix-table，提交很丑，那你应该怎么规避它呢？
这时候就轮到第九个操作 rebase登场：
git pull --rebase
这样拉取远程代码时，如果有冲突时，你可以这样做：
解决完冲突后，git add .将代码添加到暂存区；
通过 git rebase --continue 继续执行 rebase 操作；
如果没有冲突后，就可以 push 到远程了。

rebase 更多操作
git rebase --continue # 继续rebase操作
git rebase --skip # 跳过此补丁操作
git rebase --abort # 直接退出rebase
变基（Rebasing）
通过 git merge 可以将一个分支的修改应用到另一个分支，git rebase 可以将一个分支的修改融入到另一个分支。
git rebase 将当前分支的提交复制到指定分支：如当前在 dev 分支，使用git rebase master，可以在 dev 分支上获取 master 上的所有修改。
rebase 与 merge 最大的区别：Git 不会尝试确定要保留或不保留哪些文件。使用 rebase 不会遇到合并冲突，而且可以保留漂亮的、线性的 git 历史记录 git mere 和 git rebase 小结
使用：如果在开发一个 feature 分支并且 master 分支已经更新过，就可以使用 rebase 在此分支获取所有更新，防止未来出现合并冲突。
git rebase 与 git merge 对比：
假如有两个分支:
bash复制代码       D---E test
      /
 A---B---C---F--- master
git merge 后生成：
bash复制代码       D--------E
      /          \
 A---B---C---F----G---   test, master
执行 merge 后，提交点的顺序都和提交的时间顺序相同，即 master 的提交在 dev 之后。 不同于 rebase 的是，merge 如果不选择 fast-forward（快速合并）的情况下，会产生一条额外的合并记录 Merge branch 'xxx' into 'xxx'。
如果遇到冲突时 merge 只需要解决一次冲突即可，简单粗暴。
git rebase 后生成：
bash复制代码A---B---D---E---C'---F'---   test, master
执行 rebase 后，提交顺序变成被 rebase 的分支（master）所有提交都在前面，进行 rebase 的分支（test）提交都在被 rebase 的分支之后，在同一分支上的提交点仍按时间顺序排列。
如果遇到冲突时 rebase 需要依次解决每次的冲突，才可以提交，比较麻烦，所以如果修改太多的情况下还是乖乖用 merge 吧。
假如你有功能分支 feat-xxx，如果 feat-xxx 需要同步 master 代码时，使用 git rebase master；而 feat-xxx 要往 master 合并时，使用 git merge feat-xxx。所以如果不想合并时冲突太多，养成好习惯，每天下班前用你的功能分支 rebase 一下 master，到时候合并的时候就不会有那么多冲突。
交互式变基（interactive Rebase）
在为提交执行变基之前，我们可以使用交互式变基修改它们，交互式变基在当前开发的分支上以及想要修改某些提交时有用
在我们正在 rebase 的提交上，可以执行以下 6 个动作：
reword：修改提交信息
edit：修改此提交
squash：将提交融合到前一个提交中
fixup：将提交融合到前一个提交中，不保留该提交的日志信息
exec：在每个提交上运行我们想要的 rebase 命令
drop：移除该提交
利用交互式变基，我们可以实现很多操作，比如我们最开始的问题合并多个提交到同一个提交

通过 log 我们可以看到，有三次相同的提交，这时候我们可以使用git rebase -i HEAD~3来合并这三个提交；
操作和 vim 的操作一致，按键盘i键开始编辑，将需要合并的提交前的pick改为s（合并提交），然后通过wq来保存；
接着会让你选择使用哪个提交信息，默认第一个，如果不想的话，直接编辑修改就行；
然后再通过 log 看，就会只有一个提交了。
到了需要上线的时候，领导说你改的这几个 bug 中有一个就是“设计如此”，不需要发到线上了，让你把提交的代码给撤销了，愁啊？这怎么撤销了？相信绝大多数人都会把对应提交的代码注释掉，然后重新提交一次，那么为何不试试这第十个操作revert呢！
名如其意，对特定的提交执行还原操作。 假如某个提交添加了一个引用文件 index.js，但之后发现不再需要这个文件，那么就可以使用git revert commitId还原那个提交，然后 push 到远程即可。
git revert commitId
git push
仓库

本地仓库是对于远程仓库而言的。
本地仓库 = 工作区 + 版本区
工作区即磁盘上的文件集合。
版本区(版本库)即.git文件
版本库 = 暂存区(stage) + 分支(master) + 指针Head 以我使用最频繁的git命令为例，即提交到github为例。 git init 原本本地仓库只包含着工作区，这是最常见的工作状态。此时，git init一下，表示在本地区域创建了一个.git文件,版本区建立。 git add . 表示把工作区的所有文件全部提交到版本区里面的暂存区 当然你也可以通过 git add ./xxx/ 一条一条分批添加到暂存区。 git commit -m "xxx" 把暂存区的所有文件提交到仓库区，暂存区空空荡荡。 git remote add origin https://github.com/name/name_cangku.git 把本地仓库与远程仓库连接起来。 git push -u origin master 把仓库区的文件提交到远程仓库里。 一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的。会有这样的信息nothing to commit, working tree clean
提交到GitHub
以前不熟悉git命令的时候，我提交项目到github上都是直接在网页上直接拉取文件提交上去的。有点羞耻。

git init .初始化，表示把这个文件变成Git可以管理的仓库。初始化后打开隐藏的文件可以看到有一个.git文件。
git add . 后面的一个点表示把这个文件全部提交到暂存区。
git add ./readme.md/ 表示把这个文件下面的readme.md文件提交到暂存区。
git commit -m "你要评论一点什么东西" git commit的意思是把暂存区的全部文件提交到本地仓库。-m后接评论。
git remote add origin https://github.com/name/name_cangku.git表示把你本地的仓库与GitHub上的远程仓库连接起来。只需要连接一次，以后提交的时候就可以不用谢这条命令了。name是你的github名字，name_cangku是你的仓库名。注意不要把后面的.git给漏掉了。因为我前面就是这么走过来的，绕了很多弯路。至于如何在GitHub上新建仓库，网上有很多教程，这里不再赘述了。
git push -u origin master 把本地仓库提交到远程仓库。(最后一步)在你的远程仓库上刷新一下就可以看到你提交的文件了。
最后提到的是，在git commit -m ""之前，可以重复git add到暂存区。但是git commit会把你之前存放在暂存区的全部文件一次性全部提交到本地仓库。
版本的回溯与前进
提交一个文件，有时候我们会提交很多次，在提交历史中，这样就产生了不同的版本。每次提交，Git会把他们串成一条时间线。如何回溯到我们提交的上一个版本，用git reset --hard + 版本号即可。 版本号可以用git log来查看，每一次的版本都会产生不一样的版本号。回溯之后，git log查看一下发现离我们最近的那个版本已经不见了。但是我还想要前进到最近的版本应该如何？只要git reset --hard + 版本好就行。退一步来讲，虽然我们可以通过git reset --hard + 版本号,靠记住版本号来可以在不同的版本之间来回穿梭。但是,有时候把版本号弄丢了怎么办？git reflog帮你记录了每一次的命令，这样就可以找到版本号了，这样你又可以通过git reset来版本穿梭了。
撤销
场景1：在工作区时，你修改了一个东西，你想撤销修改，git checkout -- file。廖雪峰老师指出撤销修改就回到和版本库一模一样的状态，即用版本库里的版本替换工作区的版本。
场景2：你修改了一个内容，并且已经git add到暂存区了。想撤销怎么办？回溯版本，git reset --hard + 版本号,再git checkout -- file,替换工作区的版本。
场景3：你修改了一个内容，并且已经git commit到了master。跟场景2一样，版本回溯，再进行撤销。
删除
如果你git add一个文件到暂存区，然后在工作区又把文件删除了，Git会知道你删除了文件。如果你要把版本库里的文件删除，git rm 并且git commit -m "xxx".
如果你误删了工作区的文件，怎么办？使用撤销命令，git checkout --<file>就可以。这再次证明了撤销命令其实就是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
分支
分支，就像平行宇宙，廖雪峰老师如是说。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
创建与合并分支

在没有其他分支插进来时，只有一个master主分支。每次你git push -u origin master 提交就是增加一条时间轴，master也会跟着移动。

创建一个other的分支，通过other提交，虽然时间轴向前走了，但是主分支master还在原来的位置。

理论分析完，看一下命令怎么写。
创建分支other,切换到other分支。
git branch other
git checkout other
查看当前所有分支
复制代码git branch
markdown复制代码* other
  master
当前的分支会有一个*
用other提交
sql复制代码git add ./xxx/
git commit -m "xxx"
other分支完成，切换回master
复制代码git checkout master
此时，master分支上并没有other的文件，因为分支还没有合并。
合并分支
sql复制代码git merge other
合并完成之后，就可以在master分支上查看到文件了。
删除other分支。
复制代码git branch -d other
我由此想到，在以后工作中，应该是一个开放小组共同开发一个项目，组长会创建很多分支，每一个分支可以交给一个人去开发某一个功能，一个小组共同开发而且不会相互干扰。谁的功能完成了，可以由组长合并一下完成了的分支。哦，完美！
解决合并分支问题

假如有这样一种情况，分支other已经commit了，但是此时指针指回master时，并且master没有合并，而是git add / commit 提交了。这样，就产生了冲突，主分支master文件内容与other分支的内容不一样。合并不起来！所以，
修改文件的内容，让其保持一致。
git add git commit 提交。
分支合并了。
git log --graph 查看分支合并图
git branch -d other 删除分支，任务结束。
分支管理策略
git merge --no-ff other 禁用Fast forward模式，因为使用Fast forward模式，删除分支后，分支历史信息会丢失。
BUG分支
廖雪峰老师提到，工作中每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。但如果你手上有分支在工作中，你的上级要你改另外的分支的BUG。你要把现在正在工作的分支保存下来，git stash,把当前工作现场“存储”起来，等以后恢复后继续工作。当你解决BUG后，git checkout other回到自己的分支。用git stash list查看你刚刚“存放”起来的工作去哪里了。此时你要恢复工作：
git stash apply恢复却不删除stash内容，git stash drop删除stash内容。
git stash pop恢复的同时把stash内容也删了.
此时，用git stash list查看，看不到任何stash 内容。
总结：修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场
删除分支
git branch -d + 分支有可能会删除失败，因为Git会保护没有被合并的分支。
git branch -D + 分支 强行删除，丢弃没被合并的分支。
多人协作
git remote 查看远程库的信息，会显示origin，远程仓库默认名称为origin
git remote -v显示更详细的信息
git push -u origin master推送master分支到origin远程仓库。
git push -u origin other 推送other到origin远程仓库。
抓取分支

产生上图的冲突时，
git pull 把最新的提交从远程仓库中抓取下来，在本地合并，解决冲突。在进行git pull
如果git pull 也失败了，还要指定分支之间的链接，这一步Git会提醒你怎么做。然后再git pull。
廖雪峰老师的总结：多人协作的工作模式通常是这样：
首先，可以试图用git push origin <branch-name>推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin <branch-name> 推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
Rebase
git rebase 把分叉的提交历史“整理”成一条直线，看上去更直观.缺点是本地的分叉提交已经被修改过了。
最后在进行git push -u origin master
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
标签管理
比如一个APP要上线，通常在版本库中打一个标签(tag), 这样，就确定了打标签的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针。
tag其实就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。比如tag v2.1就是把历史上的一个版本的东西叫做v2.1
创建标签
步骤：
git branch查看当前分支,git checkout master切换到master分支。
git tag <name> 打标签，默认为HEAD。比如git tag v1.0
默认标签是打在最新提交的commit上的。如果想要打标签在以前的commit上，要git log找到历史提交的commit id.
如果一个commt id是du2n2d9,执行git tag v1.0 du2n2d9就把这个版本打上了v1.0的标签了。
git tag 查看所有标签，可以知道历史版本的tag
标签不是按时间顺序列出，而是按字母排序的。
git show <tagname> 查看标签信息。
git tag -a <标签名> -m "<说明>",创建带说明的标签。 -a指定标签名，-m指定说明文字。用show可以查看说明。
操作标签
git tag -d v1.0 删除标签。因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
git push origin <tagname> 推送某个标签到远程
git push origin --tags 一次性推送全部尚未推送到远程的本地标签
如果标签推送到远程。git tag -d v1.0 先删除本地标签v1.0。git push origin :refs/tags/v1.0删除远程标签v1.0
自定义Git
git config --global color.ui true让Git显示颜色，会让命令输出看起来更醒目
忽略特殊文件 创建一个.gitignore文件，把需要忽略的文件名填进去。Git就会自动忽略这些文件。我也在学习中遇到过这样的问题，比如node_modules文件就可以忽略。
忽略文件原则：忽略操作系统自动生成的文件，比如缩略图等； 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件； 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
强制提交已忽略的的文件。git add -f <file>
git check-ignore -v <file>检查为什么Git会忽略该文件。
给Git命令配别名,这个有点骚，就是你以后想输入git rebase时,你给它一个“外号”，就叫它git nb。以后你可以通过git nb来代替git rebase。具体怎么转换可以去廖雪峰老师的网站看。因为水平有限，我觉得先把正常的Git命令搞清楚来就很不错了。
常用Git命令总结
git config --global user.name "你的名字" 让你全部的Git仓库绑定你的名字
git config --global user.email "你的邮箱" 让你全部的Git仓库绑定你的邮箱
git init 初始化你的仓库
git add . 把工作区的文件全部提交到暂存区
git add ./<file>/ 把工作区的<file>文件提交到暂存区
git commit -m "xxx" 把暂存区的所有文件提交到仓库区，暂存区空空荡荡
git remote add origin https://github.com/name/name_cangku.git 把本地仓库与远程仓库连接起来
git push -u origin master 把仓库区的主分支master提交到远程仓库里
git push -u origin <其他分支> 把其他分支提交到远程仓库
git status查看当前仓库的状态
git diff 查看文件修改的具体内容
git log 显示从最近到最远的提交历史
git clone + 仓库地址下载克隆文件
git reset --hard + 版本号 回溯版本，版本号在commit的时候与master跟随在一起
git reflog 显示命令历史
git checkout -- <file> 撤销命令，用版本库里的文件替换掉工作区的文件。我觉得就像是Git世界的ctrl + z
git rm 删除版本库的文件
git branch 查看当前所有分支
git branch <分支名字> 创建分支
git checkout <分支名字> 切换到分支
git merge <分支名字> 合并分支
git branch -d <分支名字> 删除分支,有可能会删除失败，因为Git会保护没有被合并的分支
git branch -D + <分支名字> 强行删除，丢弃没被合并的分支
git log --graph 查看分支合并图
git merge --no-ff <分支名字> 合并分支的时候禁用Fast forward模式,因为这个模式会丢失分支历史信息
git stash 当有其他任务插进来时，把当前工作现场“存储”起来,以后恢复后继续工作
git stash list 查看你刚刚“存放”起来的工作去哪里了
git stash apply 恢复却不删除stash内容
git stash drop 删除stash内容
git stash pop 恢复的同时把stash内容也删了
git remote 查看远程库的信息，会显示origin，远程仓库默认名称为origin
git remote -v 显示更详细的信息
git pull 把最新的提交从远程仓库中抓取下来，在本地合并,和git push相反
git rebase 把分叉的提交历史“整理”成一条直线，看上去更直观
git tag 查看所有标签，可以知道历史版本的tag
git tag <name> 打标签，默认为HEAD。比如git tag v1.0
git tag <tagName> <版本号> 把版本号打上标签，版本号就是commit时，跟在旁边的一串字母数字
git show <tagName> 查看标签信息
git tag -a <tagName> -m "<说明>" 创建带说明的标签。 -a指定标签名，-m指定说明文字
git tag -d <tagName> 删除标签
git push origin <tagname> 推送某个标签到远程
git push origin --tags 一次性推送全部尚未推送到远程的本地标签
git push origin :refs/tags/<tagname> 删除远程标签<tagname>
git config --global color.ui true 让Git显示颜色，会让命令输出看起来更醒目
git add -f <file> 强制提交已忽略的的文件
git check-ignore -v <file> 检查为什么Git会忽略该文件
总结
本文从一个正常的 git 流程（拉代码、提交、推代码）说起，将其中可以优化或者省略的操作提炼出来。相信这也是大部分人工作中经常用到的一个流程，那么你可以回忆下你的流程，然后读文本文，看看你平时的流程有没有哪些地方可以改进，如果有，我很开心我的这篇文章有帮助到你；如果没有或者说你做的比我更好的地方，欢迎在评论区留下你的足迹，我很喜欢学习更好的姿势。
以上就是本文的全部内容，希望这篇文章对你有所帮助，欢迎点赞和收藏 ，如果发现有什么错误或者更好的解决方案及建议，欢迎随时联系。