3 ms·

I disagree, git is my favorite VCS by far because of the power it gives to truly craft a record of ones development history. A finely crafted development histo

I disagree, git is my favorite VCS by far because of the power it gives to truly craft a record of ones development history. A finely crafted development history pays major dividends as a project ages. I just got a thank you note for commit messages I wrote 4 years ago on a previous project. A lot of devs see commit messages and rebasing as useless pedantry, but once you start to take it seriously it only takes a little bit of extra time, and it provides so much future benefit via git-bisect and general spelunkability. I also think it's worth investing more time in a tool based on its longevity in ones workload. In that regard I put git at the top of the food chain, as I expect to use it even longer than Linux, for example in my case: Git > Linux > Vim > Ruby/Python > OS X / GUI tools. A side effect of being this good at git is the ability to bail out your colleagues when they royally fuck up a merge or rebase.

pacala 10y ago
For development history, we're using good PRs and good PR comments on GitHub. We've started using GitHub squash commits, but not enough long term usage to say how reliable it is. No need to manually rebase or fix someone else's broken rebase. The workflow is directly inspired by git-as-a-wrapper-around-Perforce used at Google.
- dasil003 10y ago
  I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've used personally in GitHub. I think squashing, especially automatically, has big tradeoffs. It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code). Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.

pacala 10y ago

For development history, we're using good PRs and good PR comments on GitHub. We've started using GitHub squash commits, but not enough long term usage to say how reliable it is. No need to manually rebase or fix someone else's broken rebase. The workflow is directly inspired by git-as-a-wrapper-around-Perforce used at Google.

dasil003 10y ago
I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've used personally in GitHub. I think squashing, especially automatically, has big tradeoffs. It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code). Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.