ReasonNumber.com

Ruminations of a child-free couple living in a child-full world

Come back every Monday for a new comic

Re: 10 things I hate about Git

Posted on 8/5/2012 at 10:39 am

This is in response to Steve Bennett's blog post: 10 things I hate about Git.

I'll openly admit I am a big fan of Git. I have used 3 source control systems in my day, and each has had a distinct flavor. ClearCase was my first... it was terrible, but it opened my eyes to source control. Subversion showed me how source control could be pleasant, with atomic commits and a workflow that involved interacting with files in a repository just like any other file in your file system (unlike the ClearCase model of requiring a checkout before editing). Git has since supplanted Subversion as my go to source control by showing me how a source control system can be pleasant and easy to use from initial repository setup through use, and yet provide power beyond my imaginings as I got deeper and deeper into the more powerful features.

So, I feel like the reasons why Steve hates Git all stem from jumping in the deep end. I can totally understand hating Git if your initial experiences are trying to work with an existing repository using their established branching and pull request workflow. My experiences with Git started out simple, and worked incrementally towards the more powerful features, enabling the more complicated workflows he describes. As a result, I enjoyed Git along the way, and never felt overwhelmed.

I started out with a very simple usage of Git on my own local repositories for my own personal projects. I only needed to commit to a repository, nothing more. No remotes, no branches, no rebasing... nothing but the basics. Git excels at this. I created a new directory and typed git init. That's it?? Really??? Yes, really. Maybe I was doing it wrong, but Subversion was always a pain for me to initiate a new local repository. A single command to get going felt worlds better than configuring a new subversion repository in a separate location, nevermind the user setup and making sure I could interact with the repository. The DVCS model means my local directory IS the repository, and I am up and running in no time.

Committing to my new repository meant learning a very small handful of commands that all made perfect sense. I had to "add" changes I wanted to commit, but these added changes didn't have to include everything... cool! Then I "commit"ted those things I had just added. That's it. Init to get going, then add and commit and I am done. I am up and running in no time! This was so shockingly simple when I started out that I felt my world had completely changed. I had a basic grasp of the distributed part of Git, but I hadn't needed to dive in yet for my usage, so I was free to play with a very simple and easy to use version control system.

The next jump came when I wanted to start pushing and pulling to a remote repository. This lead to another equally simple set of commands to get used to remote repositories. It also lead to some more pleasant surprises about the simplicity and elegance of Git. I learned that I could interact with Git out of the box over ssh. This was especially heart-warming to me after painfully muddling through getting Subversion set up with users and passwords on a remote server, never feeling like working over ssh was quite as simple or easy to use. I muddled through getting my repository on my remote server with my local copy pointing to it as a remote. Then, when I was done with my commits, I did a "push" to sync up my remote repository. Now I had an automatic backup of everything that was very easy to interact with. If I wanted to work on a new computer, I could "clone" the repository, then push changes from there, and "pull" from my original development machine. Everything still makes sense, and knowing that I had a complete copy of the repository on every machine involved was pretty cool.

By this time, I was using Git "like Subversion" and it was all fun and easy. I have since learned branching, merging and rebasing (along with variations of these and previous commands I had learned), each adding a new set of tools to my Git toolbox that has been a pleasant to learn and use. Scratch that... rebasing is the only tool that I can't say that with a straight face. Rebasing is extremely painful, but only when done improperly. It makes complicated actions possible, which is awesome. You just have to realize that you are changing history. If you are really trying to change history, it is the best thing in the world. If you don't really want (or need) to change history, it can be a painful mistake.

This has been my experience, and why I have come to love Git. I am extremely thankful I didn't need to dive in to the deep end of Git on my initial usages, because I would probably hate it just as much as Steve did. Instead, I started in the kiddie pool and worked my way up. Because of this, Git has become one of my favorite pieces of software that I've ever used, and I wouldn't trade it with any other version control system on the market.

One last note... once you start getting more comfortable with Git branching and merging, a successful Git branching model is required reading.