GitHub, not just for software developers
If you’ve ever heard of GitHub and you’ve never ever coded a line in your life, or you dabble in coding but don’t consider yourself a software developer, you will most likely say something like “GitHub is for those computer guys…” Well that’s not entirely true. What? Why? Stay tuned! What if you’ve never heard of GitHub? If you’ve never heard of GitHub, keep reading, because everyone can do with a little organization and a great collaboration environment in their lives.
GitHub is for anyone and everyone!
How many times have you worked on a document and titled it ‘My-doc-today’s-date-time’ or ‘My-doc-v1’? If you are a meticulous organizer, you would have most likely created a folder to store all these related documents. This naming convention approach effectively identifies the latest version of a document. But depending on the type of document, you may not be able to easily track the changes between the versions. (For the computer savvy, diff isn’t necessarily always a hero!) This is especially a limitation when the document has not been accessed for a while. In software engineering and development, the term ‘version control’ defines the tasks of organizing and chronicling the versions and configurations of a piece of (developing) software. Not only is it useful for working on solo documents, but it also documents with inputs from others. Consider the scenario of sharing a document or set of documents with a number of persons for their individual feedback. Each individual returns the document(s) with their edits, as the filename(s) with their name appended. Your painfully tedious task is to combine these changes into one final document - a process referred to as merging collaborators’ edits. Now, suppose you can leverage software - a ‘version control system’ - that would systematically identify changes between two documents as you combine one file into the master file at a time? That would significantly reduce the pain factor! This is where ‘version control systems’ such as GNU RCS, CVS, Apache Subversion and Git are useful to manage the version control process. These systems keep track of changes in the files, allow for easy exploration of differences between the files (irrespective of type), and provide easy methods to merge collaborators’ edits. Version control systems are extensible to any type of file - code, manuscripts, presentations, etc. - hence they can be adopted by all to aid with organization and collaboration. But they are not made equal! Version control systems are differentiated by the methods they implement to manage the process, their ease of use, and the size of the projects they best align with, amongst other factors.
GitHub can be thought of a platform built around Git. Let’s revisit the previous scenario of sharing documents with a number of persons for their individual feedback. Suppose each person could observe when another in the group made changes and thus can apply those changes to the most recent document? To implement this high-level functionality, firstly the files must be available at a location that all persons can simultaneously access, a stepping stone of creating a collaborative environment. Such a location can be, for example, on a physical server or within a cloud. This shared access location concept contrasts that of the latest files being available to only one person at a time, for example, in their inbox or on their personal computer, thus placing the task of (re)distribution at their convenience. Secondly, with file availability, the assumption is that before an update occurs, each individual will check for the latest version of that file to apply their changes to, and, upon completion of these changes, the file(s) will be (re)written to the shared location. In this scenario, the changes between an individual’s edits converge on the final document more naturally as all are aware of each other's contributions, thus avoiding repetition of corrections, suggestions or rewritten sections.
How advantageous and pain-free is that!
GitHub administers a web-based graphical interface of Git (ease of use), provides access control (shared repository for files), and furthers a collaborative environment through tools such as task management widgets and wikis (added value to the version control system). Let’s explore the collaborative environment in GitHub a bit more.
At all stages of product development (e.g. a manuscript, code, presentation), empowering all team members to contribute through adding content, reviewing content, discussing approaches, and suggesting upgrades, encourages the success of the product. GitHub supports delivering a successful product through its suite of task management widgets, one of the most powerful of which is the 'creation of issues' . Creating an issue in GitHub is analogous to adding a comment or a ‘To Do’ to a document, with the additional capabilities to add multimedia, to annotate the issue using predefined tags (for example, upgrade or new feature or user-defined tags), to format text, to ask for particular team members’ inputs, to elicit discussion on the issue and potential approaches, and to assign tasks, while leaving a history that can be reviewed at will. Through monitoring the creation of issues, discussions on them, and solutions implemented, team members can have an understanding of the health of the project and the roles of team members. New team members can also be easily integrated into the project, as an extensive history of the product, as well as issues and discussions, are all available. In terms of the product development itself, GitHub’s task management widgets also support all team members to seek assistance through tagging team members, to discuss the project in realtime via chatroom integration, to review content before merging, and to request changes. The integrity of the product between merges can be ensured by adding user-defined tests to be automatically run before merging. These user-defined tests vary according to the nature of the project, for example in presentation-based project this may be automatically running a spell checker each time a collaborator attempts to integrate content.
“But I work mostly solo on projects. Should I even consider using GitHub?”
The answer is emphatically yes. On a solo project, you will assume the roles of creator/designer, implementer, tester, and leader/manager. As such, you can effectively use the task management widgets throughout your project, to leverage the README file, to describe and roadmap your project, to identify your ‘To-Do’ list as a series of issues which you (or potential collaborators) can address at any time, and to merge content into the project intermittently. This not only creates great project organization, but also creates a healthy history of tracking project progress and self-updates on project status, as needed. The biggest advantage of using GitHub for solo projects is that it lowers the bar for future collaborations because the history generated through merging, issue generation and updates can easily be accessed by (new) members allowing them to quickly come up to speed.
Although most of the projects I have contributed to on GitHub are code-based repositories, that does not mean all of my contributions have been code-related! I’ve contributed updates to documentation, created issues for new features, and participated discussions on existing issues. I’ve observed team members (both in with students projects where I’m a stakeholder, and professional projects) who never write a line of code be able to actively contribute to the project content and thus be truly integrated into the project. All contributions on GitHub are noted in the project’s history and thus help individuals with building up their profiles - like a resume! On my solo projects, I’ve experienced the successes of others finding my (public) project and contributing as they use the project for their purposes. Collaborations like these not only assisted with addressing existing issues (from the project’s roadmap), but also grew the projects as persons add/ suggests new functionality. Hopefully, this blog has inspired you to give GitHub a try, or at least explore it a bit. A good resource for diving in, is the infamous Hello World project. If you are seriously going to use GitHub for your projects, be sure to explore the plans available to determine the best for you. Some affairs you may wish to consider in choosing a plan are is it a concern if your project is public facing? If it is public, do you need to consider licensing your intellectual property?
Credit
Image taken from: https://www.cdc.gov/foodsafety/images/flexslider/group-with-hands-together-large.jpg