Some best practices for using Git
deepsource.io
Some best practices for using Git
1–10 of 13 posts
Re: Some best practices for using Git
#2[deleted]
Re: Some best practices for using Git
#3Great 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?
Re: Some best practices for using Git
#4Great 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?
It is not ideal, but ... Get a GUI and pick out lines and files and multi-commit your changes.
Re: Some best practices for using Git
#5Great 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?
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.
Re: Some best practices for using Git
#6Every git commit should have a ticket ID.
Squash all commits! No development commits in master branch.
Re: Some best practices for using Git
#7Great 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?
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."
Re: Some best practices for using Git
#8Great 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?
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."
That is a good way to think. Thanks.
Re: Some best practices for using Git
#9Great 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?
`git add --interactive` can be a great tool to learn in this case: 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.
Re: Some best practices for using Git
#10Every git commit should have a ticket ID. Squash all commits! No development commits in master branch.
Once squashed, how do you go back to the dev commits?