- 主题:请教大家一个git的使用技巧
不把远程的删掉以前的commit还会再pull下来的
【 在 eric8888 (eric8888) 的大作中提到: 】
:
: 【 在 irroy 的大作中提到: 】
: : 怎么感觉应该弄一个远程分支myBranch？然后再远程分支上测试，
: : 最终没有问题之后，dev-merge-myBranch, --squash,
--
FROM 117.136.0.*
看官网的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.*
所以你在本地只commit，等本地测试好了再rebase再push再merge过去不就行了？你不会是本地commit一次就push一次吧
【 在 feed (鳄鱼) 的大作中提到: 】
: 知道了，所以我现在遇到的问题是源自公司的系统问题
: 因为我们很多问题，只有merge到了dev branch之后，才能部署，才能测出问题来。
: 自己的私有分支是不能进入dev测试环境的，只能本机测试。
:
--
FROM 124.202.217.*