Git 工作流程理念将未完成的本地分支推送到远程以进行备份
假设我目前正在开发一个新功能，该功能是从“dev”分支中分支出来的，并且已经工作了几天，但它尚未准备好与“dev”合并并推送。
尽管我已经进行了多次提交，并且一直在将更改拉到开发中，然后将开发合并到我的功能分支中以保持更新。
这是我的问题。将我的功能分支推送到原点（例如 GitHub）上的新分支（与我的本地分支同名）只是为了备份目的，稍后当它合并到“dev”和/或“时，这是一个好主意吗？” master' 将其从源中删除。
Say I'm currently working on a new feature which I've branched off of the 'dev' branch and I've been working for several days and it's not yet ready to be merged with 'dev' and pushed.
Although I have made several commits and have been pulling changes to dev and then merging dev into my feature branch to keep myself updated.
Here's my question. Is it a good idea to push my feature branch to a new branch (with the same name as my local branch) onto origin (say GitHub) just for back-up purposes and later on when it's merged into 'dev' and/or 'master' delete it from origin.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为出于备份目的推回您自己的远程存储库没有什么坏处，但是如果您正在构建那么大的功能分支，您可能会检查您的开发方法：
您可能一次构建太多，并且应该破坏您正在构建的功能将您的功能分支开发为许多较小的任务。这将使合并回您的开发分支变得更容易。
I see no harm in pushing back to your own remote repository for backup purposes, but if you're building feature branches that big, you might examine your development methodology:
You might be building too much at once and should break the feature you're developing in your feature branch into a number of smaller tasks. This will make merging back into your development branch a bit easier.
听起来很有道理。
如果没有人从该分支中提取数据，我建议 在 dev 之上重新建立功能分支，而不是直接将 dev 合并到 feature 中。
这可以避免 混乱的历史（如果在开发上开发了多个功能）
但抛开这个细节不谈，将其推送到 GitHub 存储库是一个可行的工作流程（如果没有人尝试拉取并合并该分支，也就是说，需要一个良好的命名约定）。
如果您的 GitHub 存储库是主项目的分支，那么您绝对可以可以推送你自己的分支并稍后删除它。
That sounds reasonable.
If nobody pulls from that branch, I would have recommended to rebase your feature branch on top of dev, instead of merging dev directly in feature.
That can avoid a messy history (if several features are developed on dev)
But aside that detail, pushing it to the GitHub repo is a viable workflow (if nobody try to pull and merge that branch, that is, so a good naming convention is in order).
If your GitHub repo is a fork of a main project, you definitively can push your own branch and delete it later.
每个开发人员都应该有自己的克隆远程存储库。这样他们就可以分支和标记到他们想要的任何内容，并将其备份到远程位置。
当开发人员的更改经过质量检查并批准发布时，它们应该合并到
主存储库中，即使它们位于不同的分支上。这样，您就可以在所有分支上获得所有更改的本地/远程副本，但只有已完成/批准的更改才会进入生产存储库，因为它是合并，所有提交历史记录都包含在内，您将获得一个很好的工作流程。
Each developer should have their own clone remote-repository. This way they can branch and tag and to whatever they want and have it backed up on the remote location.
When a developer's changes are QA'ed and approved for publish, they should be merged into the
master repository, even if they're on a different branch.This way you have a local/remote copy of all your changes on all branches, but only completed/approved changes make it into the production repo, because it's a merge, all commit history is included and you get a nice workflow.