从GitLab或BitBucket中的一个空git repo开始。可能在其他git工具中也一样，我只是没有尝试过。
(它在BitBucket中的工作方式有点不同，因为它没有相同的功能集，但基本原理保持不变。(
创建2个GitLab问题：；第1期"；以及"；第2期"；。
使用问题上的按钮"；创建MR"；在两期中(将创建分支((在MR中留下"关闭"注释(
编辑"；代码"；在issue-1分支中。承诺/推动你的改变。
现在，开始处理问题2分支"你很快就会意识到这是建立在问题1的基础上的；要获得issue1的更改，您可以合并或重新基于issue1分支。合并/重基都表现出相同的行为。
git merge issue-1
git push
现在"重要人物；打电话，告诉你发出1"；必须立即释放"；。所以：离开CLI/IDE，在浏览器中，转到issue1MR，"；标记为就绪"；说服某人批准并合并。
现在您已经修复了问题1，您希望完成问题2的工作。有一个分支机构为您准备好了，一个草稿MR正在等待。正确的因此，您查看了您的未付机票列表，第2期已关闭"是的，当我拿到第1期发行的时候，别人帮我完成了它；
检查MR2和issue2以及issue2分支：
- MR2已合并(尽管仍为草案且未批准(
- issue2通过合并分支issue2而关闭
但现在你因为没有做你的票而被斥责(当你检查时，票已经关闭，MR也被合并了，所以你为什么还要做更多的工作？(
(在这种情况下，如果您为问题2添加了另一个提交，它就不会被合并。(
我发现这个是因为我做了一些工作，其他人打电话给我寻求帮助，他们需要我所做的。他们将我的更改合并到中，没有抽出时间做任何其他事情。我完成了我的工作，所以我得到了MR的批准并将其合并。我的同事除了将我的更改合并到他的分支机构之外，没有添加任何内容，然后打电话给："；你什么都没做，为什么要把我的票关上？当MR仍处于草案状态且尚未获得批准时，你是如何将其合并的">
tl；drMR不是一个有自己状态/生命周期的对象吗
如果提交是否在目标分支中，这不应该改变MR的状态，是吗？MR可能会有完全不同的评论等。
是否存在"；"更好"；让我的同事把我的工作包括在内而不让他的票关闭的方式？(除了在我开始合并我的更改之前做更多的工作，(可能需要几分钟(，或者等待(可能需要好几天(我合并它们，然后从master重新建立基础/合并(。
(这类似于：我合并了一个pull请求，GitHub自动合并了另一个请求。但他们从分支a创建/合并分支B，我从/到master创建/合并我的两个分支。(
是否存在"更好"；让我的同事把我的工作包括在内而不让他的票关闭的方式？
如果可能，他们应该在issue2分支的顶部重新设置自己的分支"myBranch"的基础
如果他们已经从分支main(或他们开始工作的任何其他分支(创建了自己的分支，他们会这样做：
cd /path/to/repo
git fetch
git rebase --onto origin/issue2 $(git merge-base main myBranch) myBranch
git push --force
这将更新他们自己的MR(假设他们确实在团队之间交流了新的分支机构历史(