My GitHub Workflow for Improved Productivity

Branches

When creating a repository, GitHub will set your default branch to the main branch (previously master branch prior to October 1, 2020). My goal is to keep only deploy-able and tested code in the main branch.

Branch Workflow

These branches will work together in the following process. Feature branches will be merged into develop branch when the changes are ready and tested. Develop branch will be merged into the main branch once the changes in develop are deployed and tested.

Issues

GitHub issues allow you to keep track of various bugs, tasks, and enhancements related to your project. At the start of every project, I will usually create issues for the various tasks that need to be done and label them appropriately. I will create a label named requirement for issues that are project requirements and I will also create a label named testing for any testing related tasks. When I find a bug, I will create an issue and label it correctly with the bug label. After a team discussion, issues can be assigned to the appropriate developers.

Project Boards

One of my favorite organizational tools are the integrated project boards in GitHub. I will usually create a project board with the automated kanban template. This will give me three columns: To do, In progress, and Done. I will also make sure that all existing issues and any new issues are linked to this project board. Open issues will automatically be inserted into the To do column once linked. When I am working on an issue, I will make sure I have myself assigned and I will drag the issue to the In progress column. When the issue is closed, it will automatically be moved to the Done column. This flow is simple and lends itself to quickly completing the tasks at hand in an organized manner. This is a powerful technique when paired with pull requests and issue references.

Pull Requests

Pull requests (PRs) allow other developers to review and approve your work before merging changes. In my PRs, I describe changes being made and link relevant issues. You can have an issue closed when a PR is merged into the default branch by using a keyword like “closes” or “resolves” and selecting the issue using the # key. For example, my PR from develop to main would include something like “Closes #1” if I want the issue with the key #1 to be closed. I also like to include screenshots of the changes if applicable along with instructions for testing the changes. This can be further streamlined if you setup a template for pull requests that developers should follow. Moreover, you can look into setting up GitHub Actions if you would like to automate builds, unit tests, and deployments.

Putting It All Together

I mainly apply the following workflow in large projects while collaborating in a team. However, to help illustrate my workflow, I have created an example repository and went through the flow from the beginning to a single feature being implemented. For this example, I have created a repository for a Tic Tac Toe game.

Steps

  1. I created a repository named tic-tac-toe in all lower case separated by dashes because this naming practice makes navigating in my terminal easier.
GitHub repository name
Branches
Automated kanban template setting
Project board with issues added
Feature branch created
PR from feature branch to develop branch
PR merged into develop
PR from develop branch into main branch
PR and issue are closed and automatically moved to Done in the project board

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abraham Yepremian

Abraham Yepremian

Software Engineer / Tech Entrepreneur with interests in full stack development, web3 technology, software scalability, fitness, and finance — abeyep.com