3 ms·

Some best practices for using Git

25 points by dolftax 8y ago

deleted 8y ago
[deleted]
Sourya 8y ago
Great pointers. However, I have found that even though quite a few people know this, it takes special effort to enforce it. For example, the single-purpose commits. My commits often tend to get a bit large, and include more than one "unit" of work, even though I know the best practices. Any pointers on how to avoid that?
- wodenokoto 8y ago
  It is not ideal, but ... Get a GUI and pick out lines and files and multi-commit your changes.
- sanketsaurav 8y ago
  YMMV, but when I'm working on a feature branch that can take some time, I try to break it into pieces to merge into master often. One way to think about this is breaking away from the compulsion to commit the entire thing together in a branch. So I have `feat-x-part-1`, `feat-x-part-2` and so on. It's important to resist the urge to do push things only on perfection. It works for me.
- gglitch 8y ago
  I try to emphasize that commits should not be thought of as "save points," which seems to be a seductive way to think of them, but as "undo points."
  - Sourya 8y ago
    That is a good way to think. Thanks.
- WorldMaker 8y ago
  `git add --interactive` can be a great tool to learn in this case: https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging In particular, the ability to only stage specific "hunks" at a time (interactive "patch" in the nomenclature of git) can make it possible to "untangle" multiple changes in your working directory into separate commits.
  - Sourya 8y ago
    Didn't know about that. Thank you.
sys_64738 8y ago
Every git commit should have a ticket ID. Squash all commits! No development commits in master branch.
- wodenokoto 8y ago
  Once squashed, how do you go back to the dev commits?
  - zdwolfe 8y ago
    My dev commits are usually of the form "Add test for Foo.bar", and every master commit has a dozen or so of these dev commits squashed together. Dev commits are not usually immediately useful to anyone other than the author.
    - WorldMaker 8y ago
      Lots of different opinions here. I prefer seeing how the sausage was made, just as much as I know that unsettles some folks. Git has a DAG for multiple reasons, but a DAG also gives options for not sweeping everything under the rug in rebase/squashes. I think graph traversal options like --first-parent are more interesting ways to get "clean" commit history logs in "master" than rebase/squash. I've seen (and had to help junior devs fix) far more broken branches due to rebase/squash commits than merge commits in git, that I've almost considered finding ways to entirely disable rebase/squash on projects I work on. They are useful tools that I still sometimes use locally during development myself, but I'd much rather see someone's messy laundry in their commit history than a clean history with an accidental merge bomb lurking under the surface where it isn't even obvious a rebase/squash went bad until you've got the regression report and angry users.

25 points by dolftax 8y ago

deleted 8y ago

[deleted]

Great pointers. However, I have found that even though quite a few people know this, it takes special effort to enforce it. For example, the single-purpose commits. My commits often tend to get a bit large, and include more than one "unit" of work, even though I know the best practices. Any pointers on how to avoid that?

wodenokoto 8y ago
It is not ideal, but ... Get a GUI and pick out lines and files and multi-commit your changes.
sanketsaurav 8y ago
YMMV, but when I'm working on a feature branch that can take some time, I try to break it into pieces to merge into master often. One way to think about this is breaking away from the compulsion to commit the entire thing together in a branch. So I have `feat-x-part-1`, `feat-x-part-2` and so on. It's important to resist the urge to do push things only on perfection. It works for me.
gglitch 8y ago
I try to emphasize that commits should not be thought of as "save points," which seems to be a seductive way to think of them, but as "undo points."
- Sourya 8y ago
  That is a good way to think. Thanks.
WorldMaker 8y ago
`git add --interactive` can be a great tool to learn in this case: https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging In particular, the ability to only stage specific "hunks" at a time (interactive "patch" in the nomenclature of git) can make it possible to "untangle" multiple changes in your working directory into separate commits.
- Sourya 8y ago
  Didn't know about that. Thank you.

sys_64738 8y ago

Every git commit should have a ticket ID. Squash all commits! No development commits in master branch.

wodenokoto 8y ago
Once squashed, how do you go back to the dev commits?
- zdwolfe 8y ago
  My dev commits are usually of the form "Add test for Foo.bar", and every master commit has a dozen or so of these dev commits squashed together. Dev commits are not usually immediately useful to anyone other than the author.
  - WorldMaker 8y ago
    Lots of different opinions here. I prefer seeing how the sausage was made, just as much as I know that unsettles some folks. Git has a DAG for multiple reasons, but a DAG also gives options for not sweeping everything under the rug in rebase/squashes. I think graph traversal options like --first-parent are more interesting ways to get "clean" commit history logs in "master" than rebase/squash. I've seen (and had to help junior devs fix) far more broken branches due to rebase/squash commits than merge commits in git, that I've almost considered finding ways to entirely disable rebase/squash on projects I work on. They are useful tools that I still sometimes use locally during development myself, but I'd much rather see someone's messy laundry in their commit history than a clean history with an accidental merge bomb lurking under the surface where it isn't even obvious a rebase/squash went bad until you've got the regression report and angry users.