- 主题:请教大家一个git的使用技巧
Rebase不影响别人的提交，只amend自己的提交
【 在 nikezhang () 的大作中提到: 】
: 在develop上rebase？这个分支又不是只有他自己的commit
:
: 【 在 mopo (Fred Li) 的大作中提到: 】
--
FROM 124.64.18.*
每次我提交新的申请的时候，我当然不想让人看见我之前的文件的修改。
但是我需要等我这个大feature做完了之后，我用一个统一的PR的link，就能给大家看到我所有的曾经的修改。这样别人参照我的代码可以做他的feature。
如果我给后来人一堆PR，别人会看不过来，很晕。
【 在 nikezhang 的大作中提到: 】
: 你到底是不想让人看到你之前的文件修改还是不想让人看见？前面你的描述是想让人看见，现在成了不想让人看见？
--
FROM 120.244.236.*
我的需求是：
1：等我这个feature完成之后，我想用一个PR link，就能展示我所有的修改，以供后来人参考。
2：开发的过程中，每次commit，我想让reviewer 只看到最新一个commit的修改
而这两个需求确实有矛盾的地方。但大家都是怎么解决的呢？
难得大家都没有我这样的需求吗？
我觉得这个需求是很常见的呀
【 在 SlO 的大作中提到: 】
: 那就不好办了。
: 试试cherrypick，只把你的修改提出来。不过有可能会有冲突。
--
FROM 120.244.236.*
我们公司的规定比较符合你的第一条需求，所以统一要求每一个br只做rebase，不要merge。所以每一个PR都只包含自己的修改。
第二个需求就费点劲了。我们目前对这个需求不强，feature通常都是已经拆解的比较零碎的，review每一个PR的都会看到这个PR所有的commit而不是最后一次的commit，当然reviewer也可以指定commit进行对比。
【 在 feed (鳄鱼) 的大作中提到: 】
: 我的需求是：
: 1：等我这个feature完成之后，我想用一个PR link，就能展示我所有的修改，以供后来人参考。
: 2：开发的过程中，每次commit，我想让reviewer 只看到最新一个commit的修改
: ...................
--
FROM 106.121.184.*
我这边现在流程是这样的
测试环境使用一个指定分支名，发布时系统每次以master为基础，合并需要发布的一个列表里的所有分支，变成最新的测试分支内容，名字永远不变。冲突自己想办法手动解决
所以不存在你的PR流程
你现在这种反复merge的流程，没有办法把所有自己的commit提到一起
【 在 feed (鳄鱼) 的大作中提到: 】
: rt
: 目前我是开发一个大的feature，但一次commit肯定是做不完的。
: 我新建了一个自己的branch，叫 myBranch
: ...................
--
FROM 222.64.17.*
先分多个commit，每次提交前要先rebase，不然就像你说的，最新提交会包含所有（上次rebase前的）历史提交。
最后功能做完，squash成一个pr合并到主分支。
假设dev是大家都在上功能的分支，那么你还需要一个临时的review分支，以及一个用于修改代码的工作分支。
【 在 feed 的大作中提到: 】
: 我的需求是：
: 1：等我这个feature完成之后，我想用一个PR link，就能展示我所有的修改，以供后来人参考。
: 2：开发的过程中，每次commit，我想让reviewer 只看到最新一个commit的修改
: ...................
--
FROM 115.193.182.*
知道了，所以我现在遇到的问题是源自公司的系统问题
因为我们很多问题，只有merge到了dev branch之后，才能部署，才能测出问题来。
自己的私有分支是不能进入dev测试环境的，只能本机测试。
【 在 webhost 的大作中提到: 】
: 先分多个commit，每次提交前要先rebase，不然就像你说的，最新提交会包含所有（上次rebase前的）历史提交。
: 最后功能做完，squash成一个pr合并到主分支。
: 假设dev是大家都在上功能的分支，那么你还需要一个临时的review分支，以及一个用于修改代码的工作分支。
--
修改:feed FROM 120.244.236.*
FROM 120.244.236.*
看官网的pro git介绍，rebase适合还没有push到自己的远程分支的时候使用，如果一旦push了，你不知道会不会有人基于你的远程分支开发，当然，一切都沟通好了是没事的
【 在 SlO (S10) 的大作中提到: 】
: 我们公司的规定比较符合你的第一条需求，所以统一要求每一个br只做rebase，不要merge。所以每一个PR都只包含自己的修改。
: 第二个需求就费点劲了。我们目前对这个需求不强，feature通常都是已经拆解的比较零碎的，review每一个PR的都会看到这个PR所有的commit而不是最后一次的commit，当然reviewer也可以指定commit进行对比。
: 【 在 feed (鳄鱼) 的大作中提到: 】
: : 我的需求是：
--
FROM 124.202.217.*
对，merge和rebase是两种风格，merge是保留所有历史修改，rebase想保留哪些历史就保留哪些历史，适合有洁癖的人
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: 我这边现在流程是这样的
: 测试环境使用一个指定分支名，发布时系统每次以master为基础，合并需要发布的一个列表里的所有分支，变成最新的测试分支内容，名字永远不变。冲突自己想办法手动解决
: 所以不存在你的PR流程
:
--
FROM 124.202.217.*
review可以不在develop上进行吧，在他自己的分支进行就没有干扰了
【 在 webhost (webhost) 的大作中提到: 】
: 先分多个commit，每次提交前要先rebase，不然就像你说的，最新提交会包含所有（上次rebase前的）历史提交。
: 最后功能做完，squash成一个pr合并到主分支。
: 假设dev是大家都在上功能的分支，那么你还需要一个临时的review分支，以及一个用于修改代码的工作分支。
:
--
FROM 124.202.217.*