These days GIT seems to be the main version control system people are using, especially with github being the defacto standard for hosting projects.
I have a limited understanding of Subversion, but I believe it's not really a case of 'GIT is better than SVN', it's more that they just handle things in slightly different ways, with GIT perhaps just being more suited to a distributed nature of working.
Something like GIT isn't going to necessarily speed up development. That's because it's not really about making _development_ faster, it's about tracking changes and making it much easier for multiple developers to work on the same codebase.
If you are lone developer, something like GIT is only really going to help you track versions of your software, effectively like snapshot backups. It could also be handy to track particular versions of your code.
But where GIT shines is when more than one developer is in the mix. By pushing your code up to to git server, another developer can than create a 'fork' and work on that copy. You both can then create branches and work on separate things. Then when you commit the code back to the main copy of the code base, you can safely merge the separate branches of code back together. It will also flag any files that you've both worked on, giving you the opportunity to review and resolve any conflicts. Working this way means that many developers can comfortably work on separate features simultaneously.
If you didn't use version control in this way and did something like store just a master copy on a shared drive it would be a nightmare - everyone would be overwriting each other's changes and you'd never know if you needed to update your version of the code - GIT solves these kind of problems, you can't actually ever destroy someone else's code inadvertently, everything can always be rolled back.
The question whether to add version control to your workflow comes down more to 'what problem are you wanting to solve'?
If you are wanting to allow multiple people to work on the same code base at the same time, if you wanting to open source a project and invite others to contribute code, or you need to have a more formal mechanism for reviewing and checking code before committing to a master codebase, then something like GIT will help you.
If on the other you are really just looking for ways to speed up development, things like writing more maintainable code, having a better editor/IDE, using frameworks, basing new work on existing work, using code generators and preprocessors and simply having another look at the tasks that are taking you the longest to complete are the kinds of things that are likely to speed up your actual development.
Code
Post Reply
Delete Post
You are allowed to delete your post for 5 minutes after it's posted.
Copyright
Portland Labs
· All Rights Reserved
I have a limited understanding of Subversion, but I believe it's not really a case of 'GIT is better than SVN', it's more that they just handle things in slightly different ways, with GIT perhaps just being more suited to a distributed nature of working.
Something like GIT isn't going to necessarily speed up development. That's because it's not really about making _development_ faster, it's about tracking changes and making it much easier for multiple developers to work on the same codebase.
If you are lone developer, something like GIT is only really going to help you track versions of your software, effectively like snapshot backups. It could also be handy to track particular versions of your code.
But where GIT shines is when more than one developer is in the mix. By pushing your code up to to git server, another developer can than create a 'fork' and work on that copy. You both can then create branches and work on separate things. Then when you commit the code back to the main copy of the code base, you can safely merge the separate branches of code back together. It will also flag any files that you've both worked on, giving you the opportunity to review and resolve any conflicts. Working this way means that many developers can comfortably work on separate features simultaneously.
If you didn't use version control in this way and did something like store just a master copy on a shared drive it would be a nightmare - everyone would be overwriting each other's changes and you'd never know if you needed to update your version of the code - GIT solves these kind of problems, you can't actually ever destroy someone else's code inadvertently, everything can always be rolled back.
The question whether to add version control to your workflow comes down more to 'what problem are you wanting to solve'?
If you are wanting to allow multiple people to work on the same code base at the same time, if you wanting to open source a project and invite others to contribute code, or you need to have a more formal mechanism for reviewing and checking code before committing to a master codebase, then something like GIT will help you.
If on the other you are really just looking for ways to speed up development, things like writing more maintainable code, having a better editor/IDE, using frameworks, basing new work on existing work, using code generators and preprocessors and simply having another look at the tasks that are taking you the longest to complete are the kinds of things that are likely to speed up your actual development.