Live data from Hacker News

Git Best Practices

programmerfriend.com

1–4 of 4 posts

Re: Git Best Practices

#2
I'm a big fan of atomic committing. "Commit early and commit often," was one of my first lessons I was taught while learning gitiquette. It tends to be a point of contention sometimes when developers get into the nitty gritty of what constitutes enough of a change for a commit, but I personally have always felt like you can never have too many commits. (As long as you write good messages. Without those you're gonna have a bad time.)

Re: Git Best Practices

#3

I'm a big fan of atomic committing. "Commit early and commit often," was one of my first lessons I was taught while learning gitiquette. It tends to be a point of contention sometimes when developers get into the nitty gritty of what constitutes enough of a change for a commit, but I personally have always felt like you can never have too many commits. (As long as you write good messages. Without those you're gonna h…

I second that, especially about the good commit messages. At work we have very different work ethics when it comes to commit message.

Another dev working on a different code base was blown away on how I was able to reconstruct a requirement change 6 months ago. Just looking at the last 3 commit messages where the file was involved.

Since then I see him writing better commit messages too :) Think it was one of these eye-opener moments for him.

Re: Git Best Practices

#4

I'm a big fan of atomic committing. "Commit early and commit often," was one of my first lessons I was taught while learning gitiquette. It tends to be a point of contention sometimes when developers get into the nitty gritty of what constitutes enough of a change for a commit, but I personally have always felt like you can never have too many commits. (As long as you write good messages. Without those you're gonna h…

I'm more in the camp of just committing often... But not with good messages... Once I'm ready to merge though, I rebase and clean up commits... Seems like more work, but I like knowing that I have a fallback position if the idea I'm trying falls flat