8 ms·

> 6. Perform a final rebase cleanup after the pull request has been approved I understood everything except this step. Could someone clarify this for me? Espec

> 6. Perform a final rebase cleanup after the pull request has been approved I understood everything except this step. Could someone clarify this for me? Especially this part: "In some cases ... you can rebase also during development, but I strongly advise against it." Isn't the entire article about rebasing during development? Why did this become a "in some cases" thing now in step 6, when step 4 (rebasing during development) seems like the critical step in the whole process? Otherwise, this is a great step-by-step (especially seeing the commands that get run for each step -- up until now I only understood the rebase process conceptually, but was always scared to try it due to not knowing the exact commands to run in the exact order, or which branch to run them on). Thanks!

crazygringo 13y ago
[Edit: removed confusing paragraph.] "Rebase also during development", I'm assuming they actually mean "squash" commits, since step 4 was all about rebasing. But if the whole point of rebasing instead of merging is to keep the feature branch clean as you go along, why wouldn't squashing "less tidy" commits also be strongly encouraged? Man, you think you know git well enough, you've got git-flow down, then you read an article like this, and realize there are people who use it in a totally different way, and you're confused all over again.
saosebastiao 13y ago
I think he is talking about a cleanup rebase, where you squash all the commits you made where you fixed a typo in your docstrings or fixed your lowerCamelCased acronym keyword.
- michaelmior 13y ago
  That's how I interpreted it too. Although personally I think all that should be done in the development stage. I prefer to only approve pull requests once they're ready to be merged. It helps avoid the possibility that some of your "cleanup" accidentally introduced changes in behaviour. Also, a clean pull request is easier to review.

crazygringo 13y ago

[Edit: removed confusing paragraph.] "Rebase also during development", I'm assuming they actually mean "squash" commits, since step 4 was all about rebasing. But if the whole point of rebasing instead of merging is to keep the feature branch clean as you go along, why wouldn't squashing "less tidy" commits also be strongly encouraged? Man, you think you know git well enough, you've got git-flow down, then you read an article like this, and realize there are people who use it in a totally different way, and you're confused all over again.

saosebastiao 13y ago

I think he is talking about a cleanup rebase, where you squash all the commits you made where you fixed a typo in your docstrings or fixed your lowerCamelCased acronym keyword.

michaelmior 13y ago
That's how I interpreted it too. Although personally I think all that should be done in the development stage. I prefer to only approve pull requests once they're ready to be merged. It helps avoid the possibility that some of your "cleanup" accidentally introduced changes in behaviour. Also, a clean pull request is easier to review.