Github as a Communication Tool for Web Developers

Github was created in 2008 with an intention to offer a web-based service for software development. Particularly, it takes advantage of Git, the code management system that allows to keep track of version changes, makes it easier for a team of developers to work on code together and thus efficiently handle large projects.

There are also many other features that Git offers and which become especially handy with GitHub, making it possible to access code literally anywhere and work with it. However, in this article we’d like to talk about Github as a communication tool for web teams.

This article may be useful for project managers and web teams that are looking into ways to improve the way they interact and work together on different parts of the project. That doesn’t mean that GitHub is an all-in-one communication solution, but in some situations it appears to be handy.

Code review

One of the first features that come with GitHub are the ones that are related with code review. If you are examining the code submitted by another person, you can leave a comment in any place, discuss the solution and generally create a talk around any piece of code.

There's actually no better alternative to this approach. Emails, separate communication tools, PM applications require at least a few additional actions in order to use them, not mentioning the time and efforts required to maintain another communication tool.

The same goes for immediate communication like meetings. Unlike face-to-face verbal communication, texts and messages related to the development provide time necessary to think them through before responding.

Pull request

Once you or your team member has updated the code, a pull request can be created in GitHub to list the changes made.While this approach is obviously necessary in generic development, the feature itself allows team members to further discuss the modifications. If something in the changes is missing or the reviewer found an error in the code, pointing it out right on request page is the quickest and easiest way to tell about it.

Issue tracking

Since Github is also an issue tracker, its functionality can be used for discussing any kinds of details around the project, whether it’s a bug found by a QA engineer, enhancement idea that came from the marketing team, the problem requires brainstorming and discussion, or simply the code improvement request from a developer to its colleague.

And while code review and pulling requests is usually something used by developers (and technical managers), issue tracking that can be used by any person or team if it finds it handy for his/its needs.

Notification & Feeds

The extremely flexible notification system in GitHub allows to adjust what kinds of emails you want to receive when changes happen to the project.

Different roles in the project require different kinds of involvement. Maybe you’re the company’s CEO and you want to stay aware of the changes made to the project, though you’re not going to dive deep into each of them. Maybe you’re the lead developer following the discussions around code changes. The notification system can be adjusted in order to notify you about the changes you need, and that’s pretty handy. Especially if to compare previous ways of communication, when files were sent over email to dozens of colleagues 'just FYI' and the conversation quickly turned into a mess.

Moreover, if you don’t like to have your email to be filled with automated notification emails, with GitHub you can take advantage of its feeds. For example, your personal News Feed on Github will show you all the latest news on the repositories you watched: who opened, commented or closed an issue, a pull request, a commit, who created or deleted a branch, etc. It will also report the news on the people you follow: specifically, what repository they have started or created, whom they have followed, and so on.

Each organization also has its own news feed about repositories, and even your profile has three different feeds, but here we go too specific already.

Wiki

GitHub Wiki is a Wikipedia-like place for your repository that you can use for creating and structuring long-form content on your product. For developers it is pretty flexible, since allows writing technical info in RST, Markdown, Textile and a few other formats. We at RubyGarage find it useful to write and store technical documentation for each other, especially when getting back and extending our projects after a while.

Webhooks

Webhooks are a great way to integrate your Github repository with other internal development and communication services, like continuous integration servers, issue trackers, backup mirrors, wiki systems etc. For each event GitHub allows setting up to 20 webhooks, which is more than enough even for the most sophisticated integrations.

It works pretty simply: whenever something happens, say, a comment was written for a commit, an HTTP POST payload is sent to the configured URL (and here you must set up your software to process this payload).

Thus, webhooks allow GitHub to be integrated into your communication scheme, which makes it extremely useful.

Gists

Finally, gists are Git repositories that allow sharing snippets of code for discussions. You can set up their privacy, fork and clone gists and generally manipulate them in any way you want. Since gists are a part of GitHub, they are tightly integrated with all its other communication features and appear to be extremely handy for development teams when it comes to information and data exchange.

As you see, GitHub perfectly fits for internal communication in the web development team. We’re not saying that it satisfies everybody’s needs. Not at all. But if we’re saying about all things related to the code of the project, GitHub is the best place to communicate about them.