Git workflow: submitting pull requests to upstream and using the commits in the meantime

jon_wu

I've just started working with Git and I'm trying to figure out the best workflow for maintaining a forked repository and committing changes upstream via pull requests on Github.

I've been reading for a while, but haven't figure out the best practice. Let's use this one specific example, but this is a general workflow question.

Similar to the suggestion at Git workflow: forking a project and maintaing a local modified copy, but keep up to date, I've created a fork of magiclabs/alchemy_cms (upstream), off the 3.0-stable branch and then created another branch based off 3.0-stable to hold all custom changes. Let's call that branch custom.

Now the question is, when I want to make a new change and commit it back to the upstream magiclabs/alchemy_cms repo, what's the best way to do that so that I can create a pull request to merge to master AND also start to use that commit in the custom branch immediately. The PR may not be merged immediately, might needs changes, or might not be accepted.

What I've been doing is creating a feature branch off of master in the forked repo to get a clean pull request to submit upstream. Once I submit the pull request, I git cherry-pick that commit to get it into the custom branch.

This seems unclean since it creates a duplicate commit hash and I'm not sure what will happen when the pull request is accepted.

Is there a better way to do this?

Steve Clay

What I've been doing [to contribute to upstream] is creating a feature branch off of master in the forked repo to get a clean pull request to submit upstream. Once I submit the pull request, I git cherry-pick that commit to get it into the custom branch.

This is the correct way to do this. I manage projects on "custom" branches this way. When you periodically merge the upstream branch, it'll have 2 commits for the same operation... no big deal.

If your PR had to be reworked and no longer matches, you'll have a conflict at merge time, but that's an unavoidable cost of sailing ahead in a direction unapproved by the project leaders.

本文收集自互联网,转载请注明来源。

如有侵权,请联系[email protected] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章

来自分类Dev

Can git split a commit that was upstream using a revert?

来自分类Dev

magit for`pull --rebase upstream`(not origin)

来自分类Dev

How to squash commits in a Pull request

来自分类Dev

Implementing TFS Pull Requests

来自分类Dev

git pull requests -- 如果旧的 PR 不被接受,是否应该创建新的 PR

来自分类Dev

Trying to understand the Git Workflow

来自分类Dev

错误计数git commits

来自分类Dev

editing commits with git rebase

来自分类Dev

折叠git commits

来自分类Dev

How do I pull upstream changes of a remote GitHub repository?

来自分类Dev

Git的@ {upstream}和@ {push}有何区别?

来自分类Dev

Git Pull不做Git提取

来自分类Dev

检查git pull更改

来自分类Dev

关于git pull机制

来自分类Dev

Git Pull请求的Findbugs

来自分类Dev

git pull命令的输出

来自分类Dev

MATLAB git Pull

来自分类Dev

git pull 指定作者

来自分类Dev

Git Pull vs.Pull请求

来自分类Dev

What is the intended pull request rejection workflow in TFS/Team Services?

来自分类Dev

How to update the repository with unaccepted pull requests?

来自分类Dev

git -q pull和git pull有什么区别?

来自分类Dev

git pull和git pull origin master之间的区别

来自分类Dev

git pull在撤消git pull后说“已经更新”

来自分类Dev

git pull在撤消git pull后说“已经更新”

来自分类Dev

git -q pull和git pull有什么区别?

来自分类Dev

git pull 和 git request-pull 的区别

来自分类Dev

Jenkins Workflow插件中的Git变量

来自分类Dev

Git Pull Windows Azure网站