5 ms·

How much time do people spend messing with their source control that extreme tools like this become necessary? I commit like, once a day. What am I doing wrong

How much time do people spend messing with their source control that extreme tools like this become necessary? I commit like, once a day. What am I doing wrong?

jolmg 8y ago
To each his own, but I'd say committing once a day. That's unless I'm wrong in thinking that doing so means your commits are quite big and could be broken up into smaller, more manageable changes. Personally, I like it when `git diff` displays only one or at most three screenfuls of changes that haven't been committed.
- kchoudhu 8y ago
  Maybe I'm one of those low productivity types that interview processes are trying to permanently weed out, but I rarely write more than 40-50 good lines of code per day. Commits any smaller than that would just look like code Hemingway.
yyx 8y ago
Not fixing several tickets a day.
nickbarnwell 8y ago
I commit dozens of times a day, make half a dozen branches, pick commits between them, and generally (ab)use git as a normal part of my workflow. I will generally push one or two of those commits in the end, typically a Frankenstein creation comprised of all that has come before. There are so many ways to approach a problem in any given codebase, and I rarely know which will be the best without experimenting. Having tools that reduce the burden of experimentation and branching is incredibly powerful.
kissgyorgy 8y ago
You should commit waaaay, waaaay more often than once a day. Every small piece of logically fitting together change should go into one commit, so the git history tells a story, it's easy to revert and easy to understand how the code get to the current state and why. you also should write elaborate commit messages to all commit.
drb91 8y ago
I commit dozens of times a day with zero aliases, and it never really gets in my way. If you’re comfortable with git, leveraging it can almost certainly improve your productivity—if you can rebase, splitting a branch into two branches is a fairly trivial task. Even if all you do is commit often, you can do things like aggressively refactor without worrying that merging will be a costly endeavor—just rewind to the last manageable commit if you stick your neck out too far. On the day to day work, git use is simple; it’s with large major version upgrades, refactors, merging many branches together, and spiking/research where the more advanced features really shine.

How much time do people spend messing with their source control that extreme tools like this become necessary? I commit like, once a day. What am I doing wrong?

jolmg 8y ago

To each his own, but I'd say committing once a day. That's unless I'm wrong in thinking that doing so means your commits are quite big and could be broken up into smaller, more manageable changes. Personally, I like it when `git diff` displays only one or at most three screenfuls of changes that haven't been committed.

kchoudhu 8y ago
Maybe I'm one of those low productivity types that interview processes are trying to permanently weed out, but I rarely write more than 40-50 good lines of code per day. Commits any smaller than that would just look like code Hemingway.

yyx 8y ago

Not fixing several tickets a day.

nickbarnwell 8y ago

I commit dozens of times a day, make half a dozen branches, pick commits between them, and generally (ab)use git as a normal part of my workflow. I will generally push one or two of those commits in the end, typically a Frankenstein creation comprised of all that has come before. There are so many ways to approach a problem in any given codebase, and I rarely know which will be the best without experimenting. Having tools that reduce the burden of experimentation and branching is incredibly powerful.

kissgyorgy 8y ago

You should commit waaaay, waaaay more often than once a day. Every small piece of logically fitting together change should go into one commit, so the git history tells a story, it's easy to revert and easy to understand how the code get to the current state and why. you also should write elaborate commit messages to all commit.

drb91 8y ago

I commit dozens of times a day with zero aliases, and it never really gets in my way. If you’re comfortable with git, leveraging it can almost certainly improve your productivity—if you can rebase, splitting a branch into two branches is a fairly trivial task. Even if all you do is commit often, you can do things like aggressively refactor without worrying that merging will be a costly endeavor—just rewind to the last manageable commit if you stick your neck out too far. On the day to day work, git use is simple; it’s with large major version upgrades, refactors, merging many branches together, and spiking/research where the more advanced features really shine.