Git实际应用场景分析

区域的状态切换

• git reset file：把文件从暂存区状态重置为工作区状态，仅仅是一个状态的改变，文件内容以工作区的为准。
  • file：文件名

场景：有些提交对文件的类型有作出要求，比如一些程序代码文件为一个提交，一些依赖文件为一个提交，一些压缩包为一个提交，这样后续查看历史提交时就会清晰明了。所以当本次提交是准备提交程序代码文件时，但不小心把xxx.so或xxx.tar.gz等一些无关文件也git add了，此时就可以用git reset file把不需要的文件从暂存区状态重置回工作区状态。

• git checkout -- file：撤销工作区中对该文件的修改，它会用暂存区或者最近一次提交中的文件版本来覆盖工作区中的文件，也就是修改文件后退出且不保存的效果。
  • file：文件名

场景：改错文件了，可以使用这个恢复。有其它特殊用途再回来补充。

• git checkout SHA -- file/：将某个文件夹的内容重置回它最初被提交时的样子，同时保持其他文件夹的当前状态不变。
  • SHA：某个文件夹最初提交时的哈希值
  • file：文件名

场景：对于需要公开发布的源码，若想对部分文件执行闭源操作，通过让需要闭源的文件夹回到最初的状态从而实现闭源。

撤销提交

• git reset --soft SHA：用于撤销之前的提交，但保留所有更改在工作区中。
  • SHA：撤销到某个提交的哈希值

场景：当你想要将多个小的提交合并成一个大的提交时，比如目前有A -> B -> C三个提交，其中B、C提交是属于同一类提交，现在想把B、C提交合并成一个D提交，从而便于管理。则可以使用git reset --soft <A的HASH值>回到A提交后的状态，此时工作区就是B、C的修改记录，对这些修改进行提交即可实现把之前的B、C提交合并成一个新提交了。

修改提交

• git commit --amend -m ""：更改最近一次提交的提交信息。
  • ""：新的提交信息

场景：一般是加上-m参数，即git commit --amend -m ""，仅用来修改提交信息，这是比较实用的用法。

• git rebase -i HEAD~n：允许修改历史中的一系列提交，使它们基于新的基准点。
  • n：要修改的提交数量

场景：主要用于修改某次提交的提交信息或提交内容，比如上上次提交时，多提交了一个不同类型的文件，现在需要把这个文件从那次提交中移除，就可以使用git rebase -i HEAD~2，这时会打开一个编辑器，可以为每一次提交指定一个操作，因为我们要修改提交内容，则操作选择为edit。保存退出后，git会按照你指定的操作开始重基过程，这可能会涉及修改提交的内容、合并提交、修改提交信息等，若过程中遇到冲突，则解决冲突。每修改完一次提交后，使用git rebase --continue命令继续重基过程，或使用git rebase --abort命令取消重基。
操作参数：
pick：保留该提交，不做任何修改。
reword：保留该提交，但修改其提交信息。
edit：保留该提交，但在重基过程中暂停，允许你修改该提交的内容。
squash或 s：将该提交与上一个提交合并。
fixup：类似于squash，但会丢弃该提交的提交信息。
drop或d：删除该提交。

推送

• git push origin <local-branch>:<remote-branch>：推送本地的一个特定分支到远程仓库的某个分支。
  • local-branch：本地分支名
  • remote-branch：远程分支名

场景：任务开发完成，推送本地仓库至远程仓库。

复制分支

• git cherry-pick SHA：将单个已存在的提交应用到当前分支上。
  • SHA：提交的哈希值
• git cherry-pick SHA1 ... SHA2：将多个已存在的提交应用到当前分支上。
  • SHA1：起始提交的哈希值
  • SHA2：结束提交的哈希值

场景：在想要复制某个提交的内容到当前分支时非常有用。

同步远程仓库

• git fetch：用于从另一个存储库或本地分支获取（下载）最新的对象和数据；

场景：多人协作开发一个项目时，在个人任务开发前，应该先使用git fetch同步远程仓库。

补丁

• git format-patch -1 HEAD：生成最新提交的补丁；
  • -1：表示生成一个补丁文件
  • HEAD：代表最新的提交
• git format-patch SHA1..SHA2：生成多个提交之间的补丁；
  • SHA1：起始提交的哈希值
  • SHA2：结束提交的哈希值（不包括这个提交本身）

场景：可以将生成后的补丁文件给其他开发者使用，这样开发者在不进行完整的代码库更新或拉取的情况下，快速修复问题。

解决冲突

场景：多人协作时，复制提交或合并到分支时，可能会出现冲突，比如我修改的test.txt和别人修改的test.txt冲突，此时git会将冲突的文件移至工作区，解决完冲突（修改完文件）后，git add和git commit再次提交，就会直接提交到主分支。

快进合并

• git merge --ff-only origin/master：快进合并命令

场景：在git fetch同步远程分支后，若远程分支领先本地分支，可以使用该命令快进合并，合并后，本地分支就会与远程分支齐平。若使用git merge，则多出一个合并提交。

其它

• git rm --cached file：会从git的索引（即暂存区）中移除，但它的物理文件仍然保留在工作区中，并且git将不再追踪该文件的变更。
  • file：文件名

场景：修改源码并编译后可能会产生一些中间件，这些中间件是不需要被追踪且提交的，若.gitignore文件中对于新代码编译后产生的新的中间件没有作忽略处理，那么这些中间件会被git列为“Untracked files”，这时用git status查看工作区是不干净的，这时就要更新.gitignore的内容以达到git可以忽略中间件的追踪。如果发现.gitignore对中间件不产生作用，看看中间件是否被git add到了暂存区或是否曾经提交过仓库，这时就要使用git rm --cached file取消git对某个中间件的追踪，如果是被提交过仓库，则需要在git rm --cached file后将此次删除更改提交，.gitignore中的条目才会生效，阻止git再次跟踪该文件。