161003 – 161016 — Total classroom hours – Less than 10
I think the biggest event that’s happened in the last two weeks is that I gave a Beginners Track talk at the Boulder Ruby Group’s Presentation Night (I don’t think I’ve typed that out until now, it’s a mouthful). I’ve been wanting to give a presentation for a while now, but didn’t think I had anything to contribute, being that I’m kind of a noob. I had recently gotten positive feedback on my standardized git commit message formatting, and it occurred to me that not only would an audience of developers appreciate it, the ‘beginners’ might like to know how to set it up.
Now, I’m not going to claim that one day the clouds parted and I had this vision of the perfect commit message, of course I had help, as is the nature of web development, and most of life. One of my now many mentors, Corey Davis, introduced me to this concept a while back when we were working on a group project. He send me a
.txt file and then I dug around the interwebs to figure out how to configure it with git. At this point in my coding path I even more green than I currently am, so it took some trial and error to get the message to properly configure. As I found out again recently, testing changes to git configuration can be a beast. Unless I’m missing something obvious, the only way I’ve found is to have a burner file, make a change to it, work through the git add and commit process, and confirm that everything is how it should be. The caveat, especially when dealing with the commit message, is that if something’s not configured properly it can hang the whole process in limbo, which requires an entirely new trial and error process to figure out how to fix that. This is all that to say that I felt like it would benefit some people to give a quick tutorial on how to efficiently setup a standardized git commit message.
I’ve heard from other people how beneficial giving a presentation is for both the audience (obviously) as well as the presenter. I have to say that this couldn’t be more true. I started putting a GitHub Gist together the night before the presentation and quickly realized that although I knew the general workflow of how to create and configure the commit message file, there were a lot of little details that I didn’t know and should probably read up on before I gave the presentation. Because of this I now have a deeper understanding of git and why the
.txt file that Corey sent to me was configured as it was.
Before I started the presentation I informed everyone that this was simply my workflow, not the gospel, and that I welcomed any and all feedback. I’m always trying to improve my workflow, which is another reason I wanted to present. What better opportunity to see if you’re doing something right than to show a room full of other developers? I did get some great feedback, in fact there was quite a bit of back and forth during the entire presentation, which to me makes for a better presentation than me just jabbering the entire time. One nugget I received was about another technique on how to stage files for commit.
My previous workflow, mostly because I was mainly only working on one feature or bug issue at a time, was to use
git commit -a. Thiswas staging everything for commit. I’ve quickly come to learn, from both my internship and this presentation, that this is the lazy way to stage. I’ve also learned that I should be more thoughtful about what gets staged and what doesn’t. For this I’ve been staging each file manually, then performing a
git diff --cached, which essentially shows you all the changes made to each staged file. Then, if there was a file staged that shouldn’t be for that particular commit I would have to go back and manually unstage it. That is, until now! During the presentation I was informed of the command
git commit -p, which I’m pretty sure is the
patch option. Basically, when this command is run it shows the changes of every file that has been altered since the last commit, and gives the option to stage, not stage, quite the staging process, and about 10 other commands. (here’s a stackoverflow link showing all the commands). This is now my workflow. It handles the code review and staging in one go, which is exactly what I want.
All in all the presentation went very well. I did a little live coding with VIM (with sweaty, shaky hands), had a great dialogue about how/when/why to commit certain things at certain times, and checked a few items off of my programmer-in-training to-do list. I adamantly recommend to every student I meet to attend meetups in their area, and I can now recommend from experience that everyone give a talk as soon as they feel comfortable doing so. This is the link to the Gist, if you have any interest in standardizing your own commit messages. At the bottom of the Gist are some more git references if you want to dive even deeper.