[ This post is the first post in the Managing Source Code at 8BIT series. ]

For one reason or another, budding developers tend to shirk the responsibility of source control until it’s too late. Motivation for putting a system in place usually occurs when:
- Another person has joined the team and it’s difficult to track who is working on what
- Code is overwritten and can’t be reclaimed
- Days were spent working on a feature for a client that completely misses the mark and it’s not impossible to rollback to previous state.
- A hard drive fails and the entire codebase is lost
Sure, there are other scenarios but the above are not at all uncommon.
When it comes to source control, I take a pretty strict stance: If you’re a large team, small team, or a one-man team, then all of your code should be kept in a source control system.
This is especially true if you’re working on a product that you’re planning to sell or if you’re working on a product for someone else.
In fact, the first thing I did when joining the team was put source control in place. Over the next few posts, I’ll share our current process, how it came to be, and where we’re headed in the coming year.
But first, a quick heads up on source control…
Continue Reading…