Skip to content

Git Thoughts, Git Resources

We use Perforce at work, and that’s my only serious version control experience. Some thoughts about getting started with Git in the context of my at-work workflow:

-Both Git and Perforce have a staging step, but Perforce’s step happens prior to file edits, while Git’s is after file edits. This results in a time-wasting checkout of any file that I ‘might’ want to edit: since I can’t make any edits until I go through a checkout step, I usually might as well do it if I think I might have to edit a file. So if I’m trying to resolve an issue and I’m not sure where it is, I wind up having a bunch of unedited files checked out when I’m finished, that I then have to go through and check back in, purposelessly-or I wind up opening a bunch of files but not checking them out, and then having to go back and check them out in a separate step when I know that I need to edit them. Git’s philosophy is, keep source control out of the way until you need to deal with it. Perforce is in my face from the very beginning.
-Git is centrally concerned with changes to files; Perforce is centrally concerned with files. This is surely a change that will have wide-ranging impact on the way that I conceive of my projects. I’m just getting started, though, and since I barely have any real work in a Git repository yet, it’s hard to say exactly what those changes will come to. It’s something that I’m going to keep in mind as I continue working.
-git commit –amend allows you to add changes to an already submitted changelist, rather than submit a new one. An example of how this would be useful at work: our css/js is usually served as static assets from our cdn; so you have to remember to make changes to the separate files that bust caching so that your css/js changes are picked up. It’s easy to forget to do this; then you get two changelists, one with your actual changes, and one with the static asset cache-busting, that you have to relate to the original list via a comment. This is somewhere between pretty lame and very lame depending on my mood; with git, it would be a non-issue.
-Branching for us with Perforce involves much handwringing: managing branches is difficult for us and it’s not something we do lightly. With Git, branching is trivial. Precisely what impact that has on workflows (besides “a big impact”), isn’t clear to me quite yet, but it’s something that I’ll be keeping an eye on.

Git Resources

I worked through Edgecase’s Git Immersion lab, and it’s been the most useful resource for me so far. I think that I learn best while my fingers are doing something as I hear about what it is that they’re doing. I think a lot of people learn best that way, and that’s what you get to do with that tutorial.
I found that link through Git Ready, which has the best collection of Git resources that I’ve found so far. The other one that I’ve worked most of the way through from that site is Pro Git; it’s pretty good, but aimed a little shallowly for what I needed. I’ll be working through a lot of the other links on Git Ready and I’ll have more to say about them as I go. The other noteworthy resource, for specifically getting started on managing kevinpaulconnor.com development with Git, is Abhijit Menon-Sen’s guide. I think that one is a good jumping off point for how to set up your Git hooks. This is not a use case where Git is supposed to excel (a website managed exclusively by one person), so I’ll try to pay attention to places where things seem a little sticker than would be ideal.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*