Back to all articles

Effective project management with Github

Artem Rudenko

Artem Rudenko

Software engineer, founder of ottofeller.com

During years of work on projects of varying complexity, I tried a number of project management tools. Starting from simple TODOs to more serious tools like Asana, Trello or even Jira. Today I want to explain why I ended up using Github and show how we use it in our company.

Very close to the code

GitHub is a code repository hosting platform first, and then it is all the other tools around it. Github project management and task management tools are very close to your code, which means that you can seamlessly add a reference to a commit or a particular line in a commit, or to a pull request in every comment or message you add on Github.

You can even paste a reference to a bunch of code from your codebase , and Github automatically transforms this reference into the widget with real highlighted code!

Paste a reference to a code
Paste a reference to a code

It also works in another direction. In your commit messages, Github parses into a link any reference to an issue/comment/PR.

Cross-referencing is what Github does well. For example, it tracks all the references to an issue/PR from comments to other issues/PRs. So, you can always find related tasks while observing a single issue.

All the mentions of an issue will be shown on the issue page.
All the mentions of an issue will be shown on the issue page.

Has enough project management features

When Github started, its goal was not project management but code hosting. Github Issues back then were the way to submit a bug or suggest a feature to a hosted software. It wasn't aimed to be a fully featured task management tool. However, it has evolved, and now it has enough features to provide to those who are looking to implement different project management approaches and techniques on top of Github.

Issues (or call it tasks) are at the core of Github project management. While creating an issue, you are allowed to use markdown syntax. You can assign an issue to multiple developers. It can also have multiple labels assigned to it. Moreover, you can filter issues by these labels.

In Issues, you can post whatever type of content you want
In Issues, you can post whatever type of content you want

When you find that you have too many issues that are related to the same feature or to a release you can group them into milestones . Grouping issues into milestones make the tracking of progress much simpler - fewer things in front of your eyes. Also milestones UI shows a nice progress bar.

Notice a progress bar in the right
Notice a progress bar in the right

Github even tracks editing history of issue description or comment. With diffs provided!

You can change history!
You can change history!

Milestones are an excellent way to group things, but there is another thing which is traditionally aimed to help in tracking a state of tasks. Github Projects allows one to represent issues in the form of kanban. It is not a replacement for milestones, but a perfect amendment. One of the approaches may be like this - use milestones to group things which belong to the same feature or same release, and use projects for presenting each of your scrum sprint (one project per sprint) with columns for each of the states of an issue - todo, in progress, done.

Github projects are perfectly suited for sprints.
Github projects are perfectly suited for sprints.

Has primitive automation

With Github you can manipulate a state of an issue in the following ways:

  • you can close an issue by sending a commit with a special message into the main branch. A commit with the word “closes” or “fixes” (and few others ) following with a number of an issue in its message closes an issue. E.g., “Change the color of the button. Fixes #123” closes the task #123.
  • the same thing works if you mention magic words in the description of a Pull Request. After you merge the PR into the main branch, an issue closes automatically.

Automation doesn't end up at the closing of an issue with a magic word. You can manipulate the position of an issue in a column of a project. E.g.,  you can pick a column where to put newly added issues. You can pick a column where to put closed or reopened issues. You can also create a column called Wrong and set the automation to put all reopened issues into this column.

Not perfect but constantly improves

In conclusion, I need to say what everyone who has been using Github already noticed. After Microsoft acquired it, it started to improve rapidly. There was some period when new features were coming every week! Usually far from major, but rather some small helpful improvements.

It seems like people from Microsoft see much potential in Github, and this is good news! Github as a platform is here for a long time, and it is definitely worth giving it a try.


Other articles

Gradual rollouts with AWS Lambda

Learn how to mitigate deployment risks using AWS Lambda's gradual rollout feature, enabling safer, incremental updates to your product's backend.

Using Tailwind to fill in the gaps in your team's CSS knowledge

Many engineering teams are favoring Tailwind CSS over plain CSS for its ease of styling web frontends with utility classes, addressing scalability issues encountered with traditional CSS as project size grows.