4 ms·

We prefer patch-based workflow. It makes Git history pretty. What is wrong with the feature branch approach? Before you merge a feature branch, you can squ

by TekMol 8y ago

We prefer patch-based workflow. It makes Git history pretty. What is wrong with the feature branch approach? Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.

lima 8y ago
That's basically the same thing, just with less bells and whistles.
maktouch 8y ago
I don't find it as pretty as Phabricator's "Merge branch 'dev-hello' into 'master'" Phabricator makes it so that the squashed commit summary is the summary of the diff (merge request)
- lima 8y ago
  GitHub has a similar workflow - you can use "squash and rebase" as merge strategy, which adds a reference to the PR to the subject and combines the text of all commits into one. But like the parent said, it's not nearly as fancy.
  - jen20 8y ago
    Of note is that in this workflow, the commit message is not subject to the same review process as the code and (hopefully) documentation etc, since it's in effect written by the user merging rather than the user committing.
CGamesPlay 8y ago
This is basically how you use Phabricator locally. Phabricator looks at patches to do code review, but the "arc land" CLI command takes your feature branch, squashes the commits, rebases onto master, and pushes that. So local development can use feature branches and the main repo has a normal git history. (Github added support for "squash and merge" maybe a year or so ago; same idea)
u801e 8y ago
> Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too. With Github, you'll end up with a history like: Implement feature A Merge #1 Implement feature A Implement feature B Merge #2 Implement feature B ... you basically end up with twice as many commits than you would otherwise. The other problem is that each commit ends up being rather big and the commit message is a combination of all the commits that were squashed, including ones that don't really contain any useful information (e.g., "Addressing comments"). A big commit is harder to revert (without encountering conflicts).
- unfunco 8y ago
  Use squash and merge instead. It's built right into GitHub, that way your history will look like: Implement feature A Implement feature B
  - u801e 8y ago
    In either case, you end up with commits that have large diffs and touch many parts of the code base. Most features require multiple commits to implement. As far as I know, Github does not provide a facility to squash into multiple commits.

by TekMol 8y ago

lima 8y ago

That's basically the same thing, just with less bells and whistles.

maktouch 8y ago

I don't find it as pretty as Phabricator's "Merge branch 'dev-hello' into 'master'" Phabricator makes it so that the squashed commit summary is the summary of the diff (merge request)

lima 8y ago
GitHub has a similar workflow - you can use "squash and rebase" as merge strategy, which adds a reference to the PR to the subject and combines the text of all commits into one. But like the parent said, it's not nearly as fancy.
- jen20 8y ago
  Of note is that in this workflow, the commit message is not subject to the same review process as the code and (hopefully) documentation etc, since it's in effect written by the user merging rather than the user committing.

CGamesPlay 8y ago

This is basically how you use Phabricator locally. Phabricator looks at patches to do code review, but the "arc land" CLI command takes your feature branch, squashes the commits, rebases onto master, and pushes that. So local development can use feature branches and the main repo has a normal git history. (Github added support for "squash and merge" maybe a year or so ago; same idea)

u801e 8y ago

> Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too. With Github, you'll end up with a history like: Implement feature A Merge #1 Implement feature A Implement feature B Merge #2 Implement feature B ... you basically end up with twice as many commits than you would otherwise. The other problem is that each commit ends up being rather big and the commit message is a combination of all the commits that were squashed, including ones that don't really contain any useful information (e.g., "Addressing comments"). A big commit is harder to revert (without encountering conflicts).

unfunco 8y ago
Use squash and merge instead. It's built right into GitHub, that way your history will look like: Implement feature A Implement feature B
- u801e 8y ago
  In either case, you end up with commits that have large diffs and touch many parts of the code base. Most features require multiple commits to implement. As far as I know, Github does not provide a facility to squash into multiple commits.