在部署静态站点之前,我使用 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
请求,因为批准会导致站点自动部署。
我之前将更改从每个远程分支拉到本地分支。我认为更好的选择是拉出
master
分支,然后在本地合并剩余的分支,然后再将这些更改推送到远程。
$ git checkout master
$ git pull origin master
$ git checkout development
$ git merge master
$ git push origin development
可以对每个单独的功能开发分支重复此操作,然后将其与开发分支合并。
3年过去了,我确实学到了一些东西。我已经改变了这种开发方式,拥有一个
main
分支,然后在 dev-some-feature
分支上进行所有新功能开发。工作完成后,我会将功能合并到 main
分支中。
此处的更改是,在此合并时不会自动启动部署,我剪切了带有新版本号的标签,并使用该标签来指示要部署的内容。这意味着我可以轻松回滚到标签版本而不是特定提交,并且知道哪个标签当前正在生产中。这也意味着
main
分支是工作代码的最新版本(通常已经部署到 test
环境中以在合并之前检查功能),可用于每个后续功能分支。
强烈建议使用标签来管理这一切。一个简单的:
git tag -a v1.4.3 -m "the awesome new feature is here"
不会在开发工作流程中添加太多内容,我的部署脚本使用此标签来检查正确的存储库版本(在该标签处!)