git工作流误解

Question

我正在尝试使用生产master和dev for development 在这里描述。来实现工作流。

1. 从原始dev创建分支
   • git push --set-upstream origin dev

​

1. 从dev分支创建票证分支并切换到它

- `git checkout -b 1234_short_description`

​

1. 在当地工作和承诺

- `git commit -am "description of the changes for this commit"`

​

1. 有时间将我的票务分支1234_short_description推到远程dev存储库，这样团队负责人就可以检查做出了什么，并拒绝或批准，然后将我的工作合并到dev分支中。

我正在尝试，但git唯一想做的事情是创建origin/1234_short_description。

请向我解释如何从dev分支创建分支，并根据给定的git流推送到远程dev分支。

也许在那个工作流中，dev分支和master都是远程存储库，而不是像这里所说的dev分支？

Answer 1

我建议您按在本地工作的同一分支，而不是在dev中，否则您可以简单地在dev分支上工作。

当你推到原产地/分支123时，你应该从这个分支创建一个拉请求(PR)到dev请求。团队领导将审查公关，并合并，如果它是可以的。如果不是的话，你只需在修理后再推一次你的树枝。

在bitbucket上，您还可以在PR上添加审阅器，并创建像PR这样的规则，这样的规则必须由2 dev批准才能合并。

Answer 2

您可以通过执行以下操作来检查配置的上游分支

git branch -vv --list 1234_short_description

可以将分支1234_short_description的上游分支设置为dev/1234_short_description，方法是：

git branch -u dev/1234_short_description 1234_short_description

您可以通过执行以下操作之一将默认的推送行为设置为推送到配置的上游分支：

git config --global push.default simple
git config --global push.default upstream

这两种情况都将导致默认的推送行为推送到配置的上游分支。如果远程分支的名称与本地分支不同，“简单”将拒绝推送，而“上游”将始终推送到配置的上游分支。

在此之后，只需执行git push就可以进行推送。

可供选择的方法，不改变配置

您还可以指定要推送的完整重构规范。与其只做git push，不如做：

git push dev 1234_short_description:1234_short_description

这意味着“将本地分支1234_short_description推到dev回购中的远程分支1234_short_description。