Create git rule #19
Create git rule #19
Conversation
| ``` | ||
| 更多介绍可参考[这篇文章](https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history) | ||
| ### Commit messages | ||
| commit信息可以让其他开发者无需阅读代码便快速了解你做了哪些变动。commit信息的主题应该简洁明了，我们希望它包含如下信息： |
There was a problem hiding this comment.
平时开发的时候也可以不断的 git commit -a --amend 保持只有一个commit，但是这样的话，push的时候需要加上-f参数，这样就不需要rebase -i了~
There was a problem hiding this comment.
开发时保持多个commit还是有必要的，出现bug方便追踪和回退。Commit Often, Perfect Later, Publish Once
|
这个项目里半角和全角字符中间有空格 |
| `****`：认为此pr会有较大改进空间； | ||
|
|
||
| 项目的负责者要维护好项目的`Label`，为开发者提供便利。 | ||
|
|
There was a problem hiding this comment.
developing：pr依然在开发状态，不要做无谓的review；
need review：开发完毕，希望合作者提出意见；
release：测试通过并且已经安排进最近的发布计划，随时可以发布；
has released：已发布，希望尽快合并；
****：认为此pr会有较大改进空间；已经发布了但因各种原因不能被合到master；
|
我觉得想覆盖的点太多了，比如 |
|
@klamtlne 一哥今早让我加的这一块，这一块只是举例，并不是作为规范。 |
|
个人比较反对rebase，rebase会破坏代码提交的时间顺序，而且隐藏掉rebase冲突时的merge操作——因为rebase的merge没有单独的commit，一旦merge出问题难以快速回退，甚至无法知道merge时的代码改动。rebase后还经常出现需要push -f的操作，这与sudo rm -rf一样非常危险。 @YanagiEiichi @coffeexu @klamtlne 求喷 EDIT：还有一点，如果出现冲突，pull / merge 只需要把冲突整体解决一遍；而 rebase 有多少 commit 就得解决多少遍 |
|
|
||
| `developing`：pr依然在开发状态； | ||
| `need review`：开发完毕，希望合作者提出意见； | ||
| `testing`：非常重要，打上这个表情，当使用`make testing`发布到测试环境进行测试时，所以带该标签的pr都会合并在一起进行测试，共用测试环境。 |
| 每次开始工作前，请确保你的代码是基于合并目标分支（一般是发布分支主分支）的最新代码，因此推荐从该主仓库该分支拉取最新代码新建一个分支： | ||
|
|
||
| ``` | ||
| $git fetch origin master:newbranch |
|
@LiuXiangyu 文档书写参考 https://github.com/ElemeFE/style-guide/blob/master/copywriter.md 中英文之间没空格感觉好难受 😂 |
@YanagiEiichi @coffeexu @klamtlne 先喷一波。