For a while now, I’ve needed to really just wade through git (see: http://git-scm.com/) . to that end, I took the Code4Lib preconference workshop on Git.
Why?
First, all the cool kids are using it.
But seriously, many of the people who are working on projects that matter to me in the world - open-source projects in particular - use git (and often have links to their publicly accessible code repositories) on github. So if you want to take advantage of, build upon, or work collaboratively in an open-source software development project, you usually use git.
git is version-control software.
What that means is that git saves information about changes you’ve made in the code that you’re writing. This way, you track your progress and/or roll back to earlier code states (e.g., if new work you’ve done has the unintended consequence of introducing a bug). It also allows you to compare versions so if that dreaded bug introduction occurs, you can zoom in on where it may have arisen. It creates a record - a kind of documentation - with each commit of the code, moreover, so you can leave little notes for yourself (or, if working collaboratively with others, for them) as to why you’ve made a change. This way, even if you don’t touch the code you’ve worked on for a long time, you’ll be able to recall why you made certain design/development decisions.
Traditionally, you worked with git using a command-line interface. It’s very easy to work with command-line in either Macs or linux machines and not have a certain kind of funkiness that can occur in today’s Windows machines. But even in Windows machines, you can work with Git via command line. Also, there are graphical user interfaces for git. But if you’re doing the type of code work that benefits from git usage, you’ll probably eventually have to get more comfortable working in the command-line. That’s just a heads up.
Never forget, working in the command-line builds character (bonus points if you learn something like command-based vi/vim for editing files on your machine). Plus, all of the “cool kids” are doing it. And imagine how empowered you’ll feel as you grow more comfortable in the high-tech environment of textual displays. You’ll feel all old-school hipster-ish.
But seriously, when it comes to git use - you might ask why it’s taken off. Well, there is a style of code development common in website work today that is “agile” and “iterative”. This means that feature sets are designed in small pieces and the coding is done in short cycles by teams. Using version control systems like git makes that workflow easier to manage. It also makes collaboration with other code developers easier to manage than it otherwise might be.
Git, you see, is a distributed version control system. I don’t really care to get too far into this because while I think I understand the difference between centralized, local, and distributed version control systems, I didn’t rise up through the ranks of computer programming and I don’t want to describe these systems incorrectly. But the bottom line is that you can get a copy of a code repository on your local machine to do development work. You can do so by making your copy a separate “branch” from the original/”pristine” codebase. This makes it easier to develop off of the original codebase at the same time as someone else is, too, on their own branch.
Anyhow, there are much better explanations out there than I am providing. But suffice it to say. git is worth learning for librarians who are moving into the world of code (and many of you should at least try to do so).
Basic git commands for git can be found in this “simple” site (there’s also a link to a cheatsheet here) - http://rogerdudler.github.io/git-guide/
About heated debates on how to use git http://readwrite.com/2014/04/03/git-three-most-heated-debates#awesm=~oAu2iixc2DohLB
No comments:
Post a Comment