I don't "Git" it... Git for dummies =P
I've noticed time and again developers who don't quite grok what value there is to using Git for revision control of source. I've witnessed even more developers twist themselves in knots trying to explain and/or defend using Git, or rail against it proclaiming, "What's the big deal? I don't get it...".
Here then is my take on Git in a nutshell:
The point of GIT, and what it's trying to solve basically boils down to this:
1) The repository lives on your local OS file system. What that offers is a way to version control anything you want (more on text vs. binary ahead), and can sneaker net the entire repository with the copy command without losing version information of changes! All of the deltas and history are all contained in a nice neat folder named .git.
2) You can also (instead of sneaker net) host the source code on a remote server, which allows anyone with the necessary privileges to pull or commit changes.
3) You can apply filters on what files are committed (checked-in for SVN/SourceSafe users) using the .gitignore file. This text file lets you filter out compiler files (e.g. .objs) and auto-generated files (e.g. files that change by the build process and cannot/should not be modified).
4) The real power comes in with the versioning. Every commit from the first repository creation is demarcated with a SHA. Git SHAs are unique identifiers for commits, files, and other objects in a Git repository.
5) What can you do with SHAs? You can branch off of anywhere to create a separate set of commits unique to that branch. Example: You might want to branch at a project release point, so that development can continue while changes are frozen.
Here is where real power lies. Developers have the ability to continue to make commits to the branch (e.g. a QA branch when developers get feedback on bugs to make fixes), while development continues along the main line. When the QA branch is blessed and has all of the fixes necessary to promote to release, the changes can be merged back into the main line. While most of that can be automated, some user interaction might (often will) be necessary to resolve conflicts.
6) In projects of 2 or more developers, typically there are multiple concurrent branches. Example: Development, QA and Release. Depending on the shop, some choose to branch to make a latest QA, some merge the latest developer line into a separate QA line. There are variations on the theme, but the takeaway is that you can make Git adapt to your developer's culture, and not the other way around.
7) Lastly, there are "stupid Git tricks" that can make life easier (and more complicated, depending on your perspective). Example: One can Rebase to get to a "clean" state. A Rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch. Rebase, along with Merge, are just Git commands that specialize in integrating changes.
8) There are many 3rd party utilities for integrating with Git. You mention Visual Studio as one example, but there are many GUI interfaces (e.g. SourceTree) as well as command line (e.g. Tortoise Git). The beauty of Git is that, once again, devs aren't locked into using only one Git tool... you can choose the GUI you like, or drop down to the command line. The changes, commits and pulls still behave the same.
9) Git is typically used to provide revision control on text files, but can be used on binary files as well. Once could imagine a watermark or binary file where the actual bytes matter. You would then want to revision down to the byte level.
Git is a relatively straight forward tool for revision control management that is deployed across many OS platforms to provide uniformity. You only need to learn Git once -- you then know how it works on Windows, Linux and the MAC (or any other OS/machine environment that supports it).
Comments
Post a Comment