rt
目前我是开发一个大的feature，但一次commit肯定是做不完的。
我新建了一个自己的branch，叫 myBranch
然后会merge到 develop branch上，然后部署测试，测出问题，继续在 myBranch修改，继续merge继续测。
现在问题来了：我不断的从myBranch merge到 develop，每次提交的PR，都会看见之前的commit记录，最新提交的commit仅仅是众多commit的末尾一个，review的人 file compare的时候，把之前的file的改动都看到。
如果想让review的人清净点，就看到本次的改动，那么我需要每次重新新建一个 branch，但我觉得太麻烦，毕竟没有正式的release，这些改动都不对应具体的bug。而且将来通过一个PR就能看到我为这个feature做出的所有的改动，也是非常必要的。
这个问题大家会不会也经常会遇到？大家都是怎么解决的？
谢谢
--
FROM 120.244.236.*

我以前也是和你一样认为的
但最近做实验才发现：
除非你新建一个全新的branch，否则你一直复用之前的branch，commit新的PR，那么reviewer看到的是这个branch曾经修改过的所有的记录。我最新的commit仅仅是在所有commit的末尾一个。
不知道你明白我的意思没有。

【 在 eric8888 的大作中提到: 】
: 第一次的100个修改review完了之后并且PR merge了之后，再commit就可以提一个新的PR了啊，新PR应该只会包含当前commit的内容。
--
FROM 120.244.236.*

我们现在的pipeline逻辑必须进入develop分支才能自动部署到 dev 环境。我只有在dev环境测试才能发现新的问题，于是又进行新一次的修改。

【 在 irroy 的大作中提到: 】
: 怎么感觉应该弄一个远程分支myBranch？然后再远程分支上测试，
: 最终没有问题之后，dev-merge-myBranch, --squash,
: 然后发送review申请提交到dev。
: ...................
--
FROM 120.244.236.*

每次我提交新的申请的时候，我当然不想让人看见我之前的文件的修改。
但是我需要等我这个大feature做完了之后，我用一个统一的PR的link，就能给大家看到我所有的曾经的修改。这样别人参照我的代码可以做他的feature。
如果我给后来人一堆PR，别人会看不过来，很晕。

【 在 nikezhang 的大作中提到: 】
: 你到底是不想让人看到你之前的文件修改还是不想让人看见？前面你的描述是想让人看见，现在成了不想让人看见？  
--
FROM 120.244.236.*

知道了，所以我现在遇到的问题是源自公司的系统问题
因为我们很多问题，只有merge到了dev branch之后，才能部署，才能测出问题来。
自己的私有分支是不能进入dev测试环境的，只能本机测试。

【 在 webhost 的大作中提到: 】
: 先分多个commit，每次提交前要先rebase，不然就像你说的，最新提交会包含所有（上次rebase前的）历史提交。
: 最后功能做完，squash成一个pr合并到主分支。
: 假设dev是大家都在上功能的分支，那么你还需要一个临时的review分支，以及一个用于修改代码的工作分支。
--
修改:feed FROM 120.244.236.*
FROM 120.244.236.*