![]() ![]() ![]() Git’s branching and merging, though very powerful, flexible and useful, is quite difficult to comprehend unless the person has burnt their hands at a central version control system. The command line interface for Git isn’t easy to use for first-timers, people who are used to SVN GUIs in particular would find it difficult to get used to. SVN has many well-built GUIs, which make it easy for beginners to pick it up Git, on the other hand, does not have any GUIs that can match the quality of those available for SVN. Git isn’t without problems, though - it has a complex branching and merging model, its commit tree structure is hard to understand, DVCS concepts are difficult to comprehend, etc. Git also preserves history when branching, which SVN doesn’t do. Git branching is also cheap and quick, unlike SVN in which a branching creates a new copy of code. Git is a distributed version control system so, unlike SVN, creating a branch does not make it available to other people. Switching contexts is quite easy with Git - just create/switch to a branch, continue working and, when the work is done, just merge them back into the central master branch. Git branching is so powerful, and yet so cheap, that it becomes difficult not to use it, and branching is well complemented with Git’s superb merging feature. Git to the rescue Git was specifically designed to solve this problem. So, in order to bring back sanity, locks are introduced and, just like threads, developers enter deadlocks too and everything just falls apart. Although subversion’s branching helps quite a bit, it too deteriorates over a period of time. Stable and Development branches will help improve this situation. The real problem starts when other developers get the unstable code and start working with it. Eventually, the repository will have incomplete and unstable codes and quickly spiral out of control. Developers working in SVN would simply commit the changes they make before switching to working on something else. Developers need to have the ability to constantly switch between fixing bugs and working on features. SVN doesn’t last long SVN was designed with the inherent assumption that the context of a developer within any single codebase would be linear but, as a team scales, bugs arise and features are added to a product, that assumption quickly ceases to be true. GIT vs SVN - The real reason to move away from SVN ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |