部署后使 Git 开发分支与主分支保持一致

问题描述 投票：0回答：2

在部署静态站点之前，我使用 GitHub 来托管它们的文件。有2个分支，

master
和
development
。工作是通过 
development
的分支完成的，然后提出拉取请求以将这些更改合并到 
development
中。当所有开发更改都合并后，会提出拉取请求以合并到 
master
，然后启动站点的自动部署。

dev-branch
-> 
development
-> 
master

两个拉取请求完成后，

master
分支比
development
分支（这是附加拉取请求）提前 1 个提交。我想让 
development
分支与 
master
保持一致，并具有相同的提交次数，因为 
development
是新分支源于以进一步开发的分支。

我当前的流程是签出本地

master
，然后拉取远程更改：

$ git checkout master
$ git pull origin master

然后我检查本地 

development
并拉动远程 
master
再次更改：

$ git checkout development
$ git pull origin master

这会将远程 

master
、本地 
master
和本地 
development
置于同一点。然后，我将本地 
development
推送到远程 
development
以对齐远程和本地分支：

$ git push origin development

是否有更简单的方法可以将 

master
分支更改反映在 
development
分支中？这两个分支都受到保护，以防止未经授权的更改，我正在使用我的管理员权限来完成最后一次推送。

我的流程基于此模型：https://nvie.com/posts/a-successful-git-branching-model/并希望拥有

development
分支以允许我在拉取之前检查内容向 
master
请求，因为批准会导致站点自动部署。

git github version-control branching-and-merging
2个回答
1
投票

我之前将更改从每个远程分支拉到本地分支。我认为更好的选择是拉出 

master
分支，然后在本地合并剩余的分支，然后再将这些更改推送到远程。

$ git checkout master
$ git pull origin master
$ git checkout development
$ git merge master
$ git push origin development

可以对每个单独的功能开发分支重复此操作，然后将其与开发分支合并。

0
投票

3年过去了，我确实学到了一些东西。我已经改变了这种开发方式，拥有一个 

main
分支，然后在 
dev-some-feature
分支上进行所有新功能开发。工作完成后，我会将功能合并到 
main
分支中。

此处的更改是，在此合并时不会自动启动部署，我剪切了带有新版本号的标签，并使用该标签来指示要部署的内容。这意味着我可以轻松回滚到标签版本而不是特定提交，并且知道哪个标签当前正在生产中。这也意味着 

main
分支是工作代码的最新版本（通常已经部署到 
test
环境中以在合并之前检查功能），可用于每个后续功能分支。

强烈建议使用标签来管理这一切。一个简单的：

git tag -a v1.4.3 -m "the awesome new feature is here"
不会在开发工作流程中添加太多内容，我的部署脚本使用此标签来检查正确的存储库版本（在该标签处！）

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.