关于git, 第一印象往往是代码管理工具。在使用一段时间后，我感悟更深的是：如何利用git让自己的工作流程更加清晰。

2019.11.08 Update

最近回顾半年前写的关于git的用法，简直难以下咽。。。当是也是一知半解，面对工作情况下mark下记录的，
随着项目经验的增长（离开了老东家），对git的用法也有更深刻的理解。 当然这些流水账式的记录不能当
技术文来看待，但若干年以后再进行回顾，或许也是一件挺有趣的事情嘛。

关于git rebase -i HEAD～n

其实半年有写到这个用法，只不过因为理解不深就简单略过了，最近有了更深的理解，于是记录下。

当你开发一个新功能，一般是从dev分支checkout一个feature分支进行开发，然后通过Pull Request团队负责人code review;
如果ok了，就合并到dev。简单的feature可以通过一个commit完成，但面对复杂的功能或者完成后需求有更改，开发者需要通过不断提交完善保证开发过程思维的清晰。这时就会产生多条commit，对与code reviewer来说，多条commit其实是很不友好的，需要code reviewer一条条查看commit的修改记录，我们应该避免这种情况，Pull Request产生一条commit，提供所有更改记录。

如果你遇到上面我说的情况，不妨在提Pull Request之前，用git rebase -i HEAD～n合并你的commit记录。

运行命令后，会出现如下交互界面，提供多个可操作功能，通过描述可以了解各自功能的意思，操作时需将commit前面的标签改为对应的功能符号即可。如将需将999298a, 5e9377b合并到a603830,将999298a, 5e9377b前面的pick改为squash, 接着wq退出交互界面，git自动进行合并。然后再看看git hitstory, 是不是被合并成一条啦。如果commit已经被推送到远程仓库了，需要 git push orgin <branch> -f强制更新远程仓库。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

pick a603830 fix(MT4LIST): trading_server_id不能为空
pick 999298a feat(Global): 导出CSV文件时，手动类型账户的TA Status、Parent、Trading Group字段内容需要为空
pick 5e9377b fix(IB&Member): 用户列表导出控制

# Rebase 3aaaf38..a6908ec onto a603830 (6 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.

生成authors信息到根目录

1

git log --format='%aN <%aE>' | sort -u > AUTHORS

2019.4.12 Update

项目临近上线，为了保证代码质量，leader增加code review环节，意味着小弟我不能随便向master分支提交代码，转变了git-flow工作模式，也在这个时候更深一步学习了git。

code-review开发流程：

• 在远程仓库创建两个分支，分别命名master, dev
• 开发成员各自从dev分支上面fork一份代码到自己仓库
• 进行feat/bug时候, 本地从fork仓库chekout一个分支, 如feat/aa，此时在自己fork的仓库创建feat/aa远程分支，分支命名最好与code改动的目的相同
• 完成开发，将本地feat/aa内容push到自己远程仓库的feat/aa，同时在git/git lab页面发起merge request, 请求将改动的分支合并到dev分支，团队讨论
  觉得code没问题了，leader确定merge request，
• leader将dev合并到master分支
• 版本发布，直接从master分支打tag

more

上面的流程貌似说得有点乱，主要明白code review的目的是为了让产品更加稳定，要求开发者对自己的code负责，增加了团队对改动code进行review，讨论的环节，减轻测试人员的压力。

常用语法

更新远程代码

1
2
3
4

git fetch 
git stash 
git rebase
git stash pop //本地修改可能与远程仓库代码存在冲突

以上是我早上回到公司常做的一个操作，git fetch更新远程代码，如果你本地工作区
有修改过，没有和远程仓库保持绝对的一致，则需要用git stash，这个命令会将你的本地修改暂时缓存起来，
并使你的本地代码指向最近一次的远程更新快照。其实这个命令就是保证git rebase能够顺利进行，在rebase
完成之后，再运行git stash pop将之前的本地修改过的代码检出，在这个时候如果你的本地代码修改比较大，
会出现冲突，需要手动合并冲突，因为git并不知道哪一些代码是你最终需要的。

创建分支进行开发，完成后合并到主分支

1
2
3
4
5

git stash (in 'master')
git checkout -b 'dev' (create and switch to 'dev')
git checkout master
git merge dev

在此之前，我一直有个疑问，在master主分支开发不就行了吗？为啥要多此一举创建一个分支？
直到在工作中慢慢摸索，才理解当中的意义~ 在实际开发中，有些bug或者新功能需要并发处理，
当这些需求改动比较大具有破坏性，一下子无法完成的时候，会影响当前项目稳定版本的时候，
不妨试下以上操作，创建一个新的分支进行开发，完成开发后再将代码merge回主分支。
我个人觉得这种一种良好的开发习惯，通过创建分支保持代码的干净，至少能让自己在开发中
保持清醒的思维。

回退代码

本地仓库回退

1
2
3

git reset HEAD~n

git reset --hard HEAD~n

n代表需要回退的第几个版本

以上命名适用于本地代码有修改并提交，但还没推送到远程仓库。

如果你只是想撤销本地提交，运行第一条命令就行了，这条命令仅仅撤销提交历史记录而已，你修改的代码依然会保存到本地仓库；
如果发现自己写的代码一团糟糕，想要完全清空修改记录，则需要带上**–hard**参数，提醒一下，这条命令需要慎用，它清空你的
工作区。

远程仓库回退

1

git revert COMMIT_ID

以上适用于不小心错误提交代码，并且推送到了远程仓库。这个时候你可以选择把错误代码删除，重新提交推送到远程仓库；又或者使用
git revert进行版本回退，你需要找到错误提交的commit id，运行后，如果本地有代码冲突，需要手动解决冲突，冲突解决
完了，你需要手动创建一个提交，这个时候才算真正完成revert。建议使用git revert, 而不是直接修改提交推送到远程仓库，
毕竟良好的使用规范会让git的整个提交历史树更加清晰。

更多使用语法

简单说下在实际工作中有遇到的情况

1

git commit --amend

对已经进行了本地提交，但有新的修改文件，想将这些修改的文件整合到这个提交。在此之前，你需要运用git add将文件添加到暂存区

1

git rebase -i HEAD~<n>

将多条提交整合到一条。该命令有很多可选项，理解不深就不详细阐述了。。。

1
2

git tag 'beta.1'
git push origin bata.1

为仓库打标签，创建一个代码版本标记，相当于历史快照，QC(测试)可以根据整个tag进行测试，而开发可以在测试期间愉快地进行后续的开发，测试报告出来后
根据这个快照方便追踪解决问题

【以上为个人在工作中对git用法的一些理解，仅供参考】