4 ms·

We prevent force pushes to the remote, so if you need to rebase commits that are on the remote already, you'd have to delete the branch from the remote and re-p

We prevent force pushes to the remote, so if you need to rebase commits that are on the remote already, you'd have to delete the branch from the remote and re-push, and that closes the PR, which confuses reviewers and causes spurious notifications. Do you merge master into feature branches between the time the feature branch is first pushed to the remote and when they are reviewed and ready to merge? Can your command line tool handle creating a squashed commit when master has been merged into the feature branch a few times?

zethraeus 12y ago
git diff?
rwong48 12y ago
In your flow, how would you update a pull request branch to fix a typo? Make extra commits and normal push? and how would you update a pull request branch to contain the latest master? Merge back and forth? From the looks of it, this tool is made for the force-push flow, which doesn't suit you. See https://github.com/reenhanced/gitreflow/issues/52 https://github.com/reenhanced/gitreflow/issues/52
- nhance 12y ago
  Squash merging is only of the feature branch to master. If your feature branch makes it through code review and acceptance and you still need to update the typo, then you make the commit to master directly. It would be great if we could be perfect, but sometimes small commits to master do have to happen. All we do is make sure we subject every feature to code review and acceptance before it gets to master. If it slips through, then it's technically a new change request in our eyes
nhance 12y ago
Yes, master is merged into the feature branches before going upstream. We consider it to be the responsibility of the feature branch owner to make sure their code will work with master. Because we don't care about the commits on the feature branches, we prefer doing a regular merge, not a rebase of the feature branch, so that there's no need for force pushing at any point. We consider a force push of any kind to be unnecessarily dangerous. The tool will handle the merge up for you, but if there are conflicts you'll have to resolve them before you can release the feature.

zethraeus 12y ago

git diff?

rwong48 12y ago

In your flow, how would you update a pull request branch to fix a typo? Make extra commits and normal push? and how would you update a pull request branch to contain the latest master? Merge back and forth? From the looks of it, this tool is made for the force-push flow, which doesn't suit you. See https://github.com/reenhanced/gitreflow/issues/52 https://github.com/reenhanced/gitreflow/issues/52

nhance 12y ago
Squash merging is only of the feature branch to master. If your feature branch makes it through code review and acceptance and you still need to update the typo, then you make the commit to master directly. It would be great if we could be perfect, but sometimes small commits to master do have to happen. All we do is make sure we subject every feature to code review and acceptance before it gets to master. If it slips through, then it's technically a new change request in our eyes

nhance 12y ago

Yes, master is merged into the feature branches before going upstream. We consider it to be the responsibility of the feature branch owner to make sure their code will work with master. Because we don't care about the commits on the feature branches, we prefer doing a regular merge, not a rebase of the feature branch, so that there's no need for force pushing at any point. We consider a force push of any kind to be unnecessarily dangerous. The tool will handle the merge up for you, but if there are conflicts you'll have to resolve them before you can release the feature.