- This topic is empty.
December 14, 2013 at 12:28 am #158320nixnerdParticipant
I’m working on a REALLY simple project. It’s just a few page site with some custom widgets. That’s it.
Chalk it up to my anal nature… I have like a million commits. And by a million, I mean 23. But I only created the repo yesterday and I’ve changed literally nothing important. Only trivial stuff like colors, transitions, etc.
Is there such a thing as too many commits?December 14, 2013 at 1:50 am #158327__Participant
Any state worth saving is a commit. More commits is great. As long as they get finer-grained and have good messages, they’re useful.
In the middle of a line? no. Nothing important, but you cleaned up some formatting and that’s all you’re doing today? sure. Just finished a function def? absolutely.December 14, 2013 at 11:37 am #158341TheDocMember
If you’re working with other people, there’s definitely a chance that you can have too many commits that make the history difficult to read. For example:
* Fix typo 'Dorp' to 'Drop' * Fix typo 'fucntion' to 'function' * Update marketing copy 'buy now' to 'install now' * Update marketing copy to 'Now only $59!' to 'Now only $49!' * Fix typo 'featrues' to 'features'
Now let’s say all of those commits happening on a single page, say,
marketing.html. I would much rather see this after you push:
* Update marketing copy and fix typos
Locally, you can have as many commits as you want, but it’s much better when working in teams to figure out a great way to
squashrelated commits together.
git rebaseis super powerful, though can be really intimidating at first:December 14, 2013 at 11:41 pm #158380__Participant
Making a branch is like …a branch
Normally, when you commit, your project history keeps going in a straight line:
init ----- commit1 ----- commit2 ----- commit3 ...
Making a new branch is a lot like forking, except you stay on the same repo instead of creating a new one:
commit3 - \ branchA ----- commitA1 ...
If you switch back to the master branch, everything is still like you left it (in this case,
commit3). You can even keep working on master (or create/work on other branches):
commit3 ----- commit4 ... \ branchA ----- commitA1 ...
When you’re done working on whatever you branched for, you can merge it back in. If master has changed in the meantime, you might have to fix things if there are conflicts. If it’s only you, however, you can keep branches task-specific (i.e., don’t work on the same features/files on different branches) and it won’t be an issue.
I think this is the git talk I’m thinking of. It’s broad, and long, but it explains things nicely. (About 45min in he talks about branching, but I’d recommend watching the whole thing.) I’ll post if I find another one.
- The forum ‘Other’ is closed to new topics and replies.