3 ms·
It's an issue of having more data / insight into your codebase. Ideally your software has a fitness function that it must pass or which it is compared with oth
by fleitz 14y ago
It's an issue of having more data / insight into your codebase.
Ideally your software has a fitness function that it must pass or which it is compared with other iterations of your software. With each change made to the software it ideally becomes more fit, however we know that some changes cause bugs, reduce fitness, etc.
Source control allows regular human beings to revert to an earlier more fit stage and progress from there.
If it were possible to write a correct version of a program on the first try and never would the fitness function change then there would be no use in source control.
Frequently small programs will be created with out source control. Like a script to print the numbers 1 to 100, Fizzbuzz, etc. These kinds of software generally don't benefit from source control and thus it is not used. Software of simple complexity usually can be written correctly in a few iterations.
When working with multiple programmers the primary added benefit is file syncing and visibility into who made what change so it can be inquired as to the purpose/impact of the change.
In short if someone isn't using source control tell them that the prototype they showed you last week was perfect for a new client, you need what was built last week in the next 15 minutes to demo for a client, but the menu color should be blue instead of red.
OT:
I've been trying to figure out a way to auto-create commits everytime a file is saved, then quickly quash those commits into a single new commit when substantial changes have been made. Anyone know of a readymade solution?
- steeleduncan 14y agoOT: seconded. If anyone knows of a way to commit to a "staging" repository, then bundle my broken wip commits to the main repository, I'd love to know. I'd like to keep the main repo clean with one commit per feature/bugfix, but still be able to commit regularly and walk back/bisect changes whilst working on the feature.
- cheald 14y agoYou can do this with git and squashed commmits, but while it seems like a good idea, it's really not - when you're bug-hunting, smaller single-change commits make it far, far easier to track down and kill the bug. Having to crawl through a 3000-line squashed commit to find where a bug was introduced is awful. A better workflow is to use feature branches to work on a feature, when when you're done with it, rebase and merge it back to master and create a tag for the feature. This gives you an easy timeline of what features or fixes were introduced when, lets you commit often without breaking master, and doesn't destroy your valuable commit history.
- steeleduncan 14y agoThank you. This looks like it will work well. The only problem is remembering not to push. It would be nice to be able to work with two repositories in parallel. One repository for my development and the other one the "official" repository with larger commits, better commit messages and the guarantee that all commits work.
- cheald 14y agoYou might be interested in git-flow[1] which is a formalization of this workflow. [1] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo...
- maw 14y agowhen you're bug-hunting, smaller single-change commits make it far, far easier to track down and kill the bug. This is true, but with the caveat that each of those commits needs to basically work. If you have untestable commits, things work less well, and maybe it's worth having slightly larger commits so that they will be testable.