When I first started programming in school, Git seemed to me a mysterious and potentially dangerous tool. We were encouraged to use it, but also warned that certain commands were dangerous and could monumentally mess up a project. Consequently I felt hesitant to use it. When I did, I stuck to simple, “safe” commands. At some point I did do some reading on the structure of Git (most notably John Wiegley’s ‘Git from the Bottom Up’, which I recommend) but reading doesn’t give the same sort of understanding that working with something day in and day out does. Here at my internship I have been given that opportunity, and it has drastically changed how I feel about-and consequently utilize-Git.

Within the first week or two of the internship I found myself needing to branch out from the same commit/add/push commands that I had stuck to in school. I also found myself needing to think much more strategically about how often and what to commit, as others were reviewing my code. After submitting a massive PR that my poor mentor had to spend hours parsing through, I changed how I approached committing. I began to commit more often, and try to group code changes logically. This came in handy the the next week when, after making changes on dozens of files spaced out over about 5 commits, I realized I hadn’t run the tests in quite awhile. Of course once I realized and ran them they failed. Catastrophe! But where had I introduced the errors? Fortunately, thanks to the magic of Git, I was able to go back through my commit history, switch to individual commits based on their hash, and run the tests. Thus I was able to identify which commit caused the tests to fail, and since the commits were small, it was relatively trivial to determine what changes were causing the problems and fix them. Success!

Determining how and where to branch also became part of my learning with Git-after basing some changes on a branch rather than main, I had to spend an hour cleaning up merge conflicts on the second branch when the first branch was merged. This both brought more confidence in managing something that had previously seemed ominous and difficult (merge conflict sounds so dramatic!) and was also boring/painful enough that I vowed to really think through how to branch and where to branch in the future, as well as when to just wait for a pull request to be merged before doing any more work on related changes.

So getting more familiar with Git has not only allowed me to feel more confident as a programmer (I can take more risks with code now that I trust that I can get back to a working state easily) but it has also helped me with structuring my thought and structuring how I approach code and programming in general. And what is code if it is not structured thought?