Tags: programming
A couple weeks ago we switched from svn to git for our version control. My initial reaction was that it was acccomplishing the same thing as we were doing before only with more commands that made less sense. Oh, also fear. I was very afraid after having read various comments in helpful articles about git that I should make sure never to do some commands that I didn’t understand or I could erase history or make life miserable for everyone else using the remote repository.
The fear drove me to approach with trepidation. We had a wiki page explaining how to use git with the workflow we’d been using with svn and so I followed that for a while and got comfortable with it. I still managed to enter some command sequences that left me calling for help from our local git experts every now and then.
Yesterday I ran into my first conflict by stashing, pull —rebase-ing and then popping off the stash. This was the equivilent of svn updating my source prior to checking in. The conflict was no big deal (someone had turned an if else into a turnery) but after I resolved it in the file git still marked it as red when I ran gig status, indicating that it was conflicting . I don’t recall the exact output from the status but I think it wanted me to add the file in order to indicate that the conflict was resolved, but I was on my local master and not ready to check this file in. (I wanted to make a quick change to a properties file and commit/push that) I called for help and after some time it became evident that my brief success with svn-ized git needed to come to an end and I needed to dive head first into the true gitflow. Using it like svn got me comfortable that git wouldn’t arbitrarily lose my data and introduced me to some tools and commands, but it wasn’t a long term solution. Ultimately we fixed the problem I had at hand by making a local feature branch off master and popping my stash off there and committing to the feature branch. Now I’ve adopted the feature branch workflow.
I also resolved to stop living in fear! If git’s the way we’re going then I’m not going to sit helpless while our git master confuses me with his talk of squashing multiple commits to one before merging and how this command or that will either merge successfully onto the end of master or insert my change into the middle of the history and force everyone pulling to perform an out of order merge because of what I’ve done.
No. I’m going to own it. I’m going to master git and truly understand its workings so that I can navigate the history tree at will and bend commit points around my finger. So far I’m on chapter 3 of Git Pro and everything’s making good sense. It’s absolutely true that at its core git is straightforward. It’s just these random edge cases that seem to pop up with some frequency. Like one of my other coworkers on a Mac updated and git got upset because someone had change the name of a file and just changed its case, so the case insensitive Mac and git didn’t get along. Git was warning that it noticed an unversioned change to the file, if I recall, and after trying a bunch of things on master it just would not give up. I wasn’t there when they found the solution but it involved switching to a branch and resolving the problem there then merging back onto master, I believe. Mental note: Double check what happened there.
Anyway, soon git shall call me Master…. Muahahaha!