Introduction to Github
When I was first exposed to Github, I was completely confused as to what value it brought to the table. But now that I’ve become more comfortable with it, it’s easy to see why companies from GE to Google use it to collaborative on projects, and why it’s a great fit for something like the Deep Roots Library project.
I wanted to give everyone a quick overview and rationale behind using Github because I know that the lingo is weird at first and the process a bit more complicated than you’re probably used to. But better a small learning curve now than a million headaches with different versions down the road!
Github is, by their own definition, “the best place to share code with friends, co-workers, classmates, and complete strangers.” It’s primarily in the programming world for code, especially in open source projects, but it’s also being increasingly used for other shared and collaborative documents and information.
By using a tool that’s built for large, distributed teams to collaborate on massive projects, it gives us the ability to work together in a very orderly and efficient manner. We’ll all be able to see what the others are doing, have a place to discuss problems we run into, etc etc.
I think the best way to explain the benefits would be for me to give a quick example of how it will work.
- You create a Github account and download their desktop app.
- You “fork” the Deep Roots book repository (commmonly shortened to “repo”).
- The entire project is downloaded to your computer (your local repo).
- You make a few changes to one of the books and “commit” those changes to your local repo.
- You submit those changes via a “pull request” to the Deep Roots account.
- Someone with admin rights (Luke for now) logs in, see your pull request, and accepts it, thereby pulling your changes into the master version (hence the title “pull request.”).
- Now everyone has access to your changes, can see who did them, what they were, double-check your work, revert back as necessary, etc.
Hopefully that isn’t too much info and weird lingo, and I hope it illustrates the efficiency of this system. It’s controlled collaboration - unlike something like Google Docs or a Word document, there is no way one person can make bad edits, or worse yet accidentally delete part of a book!
Instead, it’s a clear process, with the differences between the old and the new clearly marked, notes of who made the changes, when and why. You make a change to the version on your own computer, then say via a pull request, “Hey everyone, here’s my changes” to the larger project.
So that’s a super brief overview of how things will work within Github. It’ll give us an organized homebase to work on the project, as well as discuss any problems that we run into.
From here you can read more about the file format the books are in, Markdown, or you jump right in with Github!