Source control systems like GIT are targeted at helping developer teams work together and indeed, they allow massive productivity gains in these scenarios.
However, it is important to note that even working solo, source control systems like git can be extremely useful. Here are some of the key benefits
- Source code history - no matter how good you are in development, there are times where you need to go back to a previous state. By incrementally commiting and commiting often, you have multiple stages to which you can revert and this can be done fast
- Multiple branches for multiple features - you can work on different features in different branches. Experiment all you want and even compare out easily different versions of the same code by alternating between branches.
- Auto push to production server- it is possible to push code to the production server easily when you feel there is a positive change. Not only the process can be made easier but because it is less of a hassle, you will be encouraged to commit more often. Further, when changes are made on the server, it is easier to incorporate them back transparently. It is also less risky because you can always revert back
- It helps with documentation - if you add a meaningful message with every commit, you can track what you have done more easily and remember later
- You can get a feel for progress - not only you get a list of commits but many benchmarks can be used to feel how you are doing (#of commits)
- Custom code - many times code needs to be developed for a custom client. Other times, you are extending an existing open source project... the custom code can be merged easily
- Better disaster recovery -because it is so easy to commit to different servers, there is no central code repository... at every commit to a remote repository, a backup is made. Even if the hard drive dies... either on the server or on the development machine, instant recovery can be made
Of course, when you are in a team, it helps even more
- Code sharing - everyone can get the latest code. they also can check out each other's branches and help each other without necessarily messing up their own code or having to be on your server
- Conflict resolution - Sometimes two people will change the same code and a potential conflict will be introduced... the software can flag some of these changes and prompt you to merge everything or only partially.
- team awareness - if a developer is not available, another can always pick up in case of emergency, knowing what was changed and the file's history
- robustness - the application ends up more robust because it is integrated more often and conflicts are identified early.
- increased productivity - when working individualy, team will often develop the same code either knowingly because they need a working version or unknowingly because they do not know what others have done. Working in this way, not only this is avoided but a fresh pair of eyes on each other's code can make things more robust.
- Flexibility in code sharing - Since there can be more than one repository. It is easy to imagine a tree of repositories where code is shared among the team and merges are done only when needed. Sensitive parts can be kept out of the main repository while allowing collaboration among the people who need it
- Better problem handling - When working in a team, many problems can arise. Whether it is the rare malicious intent or it is simply forgetting who did what, it is a lot easier if you can pinpoint the origin of a particular change. This can be used in a positive way too: if someone comes out with a really clever fix, it is easier to know who to praise.