4 ms·

Many (mediocre) programmers see/use git only as a tool for sharing code with collaborators. These people can be easily identified by leaving traces of meaningle

by ktpsns 5y ago

Many (mediocre) programmers see/use git only as a tool for sharing code with collaborators. These people can be easily identified by leaving traces of meaningless commit messages. The key is to convince these people that the git history can be very worthful if edits are commented appropriately. Rapid committing in small steps comes after.

lalwanivikas 5y ago
I feel attacked. Jokes aside, what advice would you give to such developers? Asking for a friend.
- acemarke 5y ago
  I'm a _very_ big believer in maintaining an informative Git history. I have some suggestions for practical Git usage patterns in a blog post I wrote last year: https://blog.isquaredsoftware.com/2021/01/coding-career-git-usage/#git-patterns-and-best-practices https://blog.isquaredsoftware.com/2021/01/coding-career-git-... TL/DR for that section: - Write Good Commit Messages - Make Small, Focused Commits - Clean Up Commit History Before Pushing - Only Rewrite Unpushed History - Keep Feature Branches Short-Lived followed by some thoughts on "Git Archeology" as a useful concept.
- postingposts 5y ago
  If you see Git as a dumb sharing tool you are correct. It’s also correct to see it as a Global Information Tracker (git) whereby you are able to share the functional state of a program. Let’s say you make a commit of a program and tag it with a version, and also leave a message to yourself which explains what that commit or version accomplishes. By doing so, you’re going beyond “saving the text” and into “saving the state” which is valuable!
mmastrac 5y ago
For other developers: Please don't look at comments like the above and think that you are doing something wrong. Git is a tool, like any others, and you can be a good programmer using it in the way that makes you most productive. Make small commits, make descriptive commits, whatever.
- jzm2k 5y ago
  I don't think it's that simple when you're collaborating with others on a large project. I think Wine [0] is a great example of how small and atomic commits can create a very nice history that allows to you track down weird regression without having to read 1000+ SLoC commits or bunch of "chaff" that is just noise when you're trying to understand the bug. But it requires effort both from the developer to make actually good commits and from the maintainer to enforce these rules. [0] https://source.winehq.org/patches/ https://source.winehq.org/patches/

by ktpsns 5y ago

lalwanivikas 5y ago

I feel attacked. Jokes aside, what advice would you give to such developers? Asking for a friend.

acemarke 5y ago
I'm a _very_ big believer in maintaining an informative Git history. I have some suggestions for practical Git usage patterns in a blog post I wrote last year: https://blog.isquaredsoftware.com/2021/01/coding-career-git-usage/#git-patterns-and-best-practices https://blog.isquaredsoftware.com/2021/01/coding-career-git-... TL/DR for that section: - Write Good Commit Messages - Make Small, Focused Commits - Clean Up Commit History Before Pushing - Only Rewrite Unpushed History - Keep Feature Branches Short-Lived followed by some thoughts on "Git Archeology" as a useful concept.
postingposts 5y ago
If you see Git as a dumb sharing tool you are correct. It’s also correct to see it as a Global Information Tracker (git) whereby you are able to share the functional state of a program. Let’s say you make a commit of a program and tag it with a version, and also leave a message to yourself which explains what that commit or version accomplishes. By doing so, you’re going beyond “saving the text” and into “saving the state” which is valuable!

mmastrac 5y ago

For other developers: Please don't look at comments like the above and think that you are doing something wrong. Git is a tool, like any others, and you can be a good programmer using it in the way that makes you most productive. Make small commits, make descriptive commits, whatever.

jzm2k 5y ago
I don't think it's that simple when you're collaborating with others on a large project. I think Wine [0] is a great example of how small and atomic commits can create a very nice history that allows to you track down weird regression without having to read 1000+ SLoC commits or bunch of "chaff" that is just noise when you're trying to understand the bug. But it requires effort both from the developer to make actually good commits and from the maintainer to enforce these rules. [0] https://source.winehq.org/patches/ https://source.winehq.org/patches/