by
Join the DZone community and get the full member experience.
Join For FreeFor the last week or so I’ve worked my way through about half of Pragmatic Version Control using Git with a mixture of excitement and terror. In random order, as it comes from my mind, are some thoughts:
- Git treats branches and tags as first-class citizens. They are attributes of the repository. Git can easily give you a list of branches in one single git branch command. Coming from the world of Subversion, where branches and tags are tenuously related to trunk, I have to say this is refreshing. I almost said “Of course! It should be this way!”
- Subversion makes you organize your branches and tags by paths. Git, following from the above, does not. I’ve never much liked having to babysit the Subversion repository hierarchy, even though it is extremely malleable.
- Going in, I was not aware who authored Git. After I typed out a few commands, I joked to myself that it seemed made for Linux command-line lovers. Spot on.
- Git operates on file contents rather than files. It knows when code moves from one file to another. It knows when code is duplicated. It doesn’t balk at files being renamed or moved. If you frequently refactor your code, this should produce at least one little tear of joy in your eyes.
- I wonder how well Redmine, Jenkins, and other heavily-VCS based systems work with Git. I’ll have to find out.
- Perhaps it’s just this book, but I think I’m seeing inconsistencies in naming. For example: staging, cache, and index. Are they the same? Are they different? How do they relate? I’m not satisfied the book isn’t confusing me. It could be my fault, though.
- Those familiar with Subversion may see the .git directory as an analogue to .svn. It’s not; the .git directory is the repository.
Git
Published at DZone with permission of Mike Christianson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments