Agile Project Workflow involving Github - Agile Project Management
loader image
Technical Tips & Tricks

Agile Project Workflow involving Github

Introduction on Agile Project Workflow

In this article, we will see in detail, the Agile project workflow… which means that we will see how we need to plan our tasks/bugs efficiently on a step-by-step basis, and how git makes Agile project workflow development easier.


  1. Sprint Planning – Prioritize tasks
  2. Pull to update your local master
  3. Create a feature branch
  4. Do work in your feature branch
  5. Keep Feature Branch up-to-date with master
  6. Complete your Feature
  7. Create a Pull Request & Review Pull request
  8. Delete Feature Branch
  9. Verify and close the feature

The above rules make an efficient Agile project workflow for developers in Agile teams to handle features / bugs to keep a clean and sane history.

Sprint Planning – Prioritize Tasks

Initially, the team or Product Owner will need to decide what it is that we are going to do and what are the priorities.
In order for this workflow to be effective, we recommend that all work be iteratively broken down into smaller units which can be accomplished relatively quickly by a single team member or pair, and for this document, we shall use the term Features.
The Features should be expressed in some ordered form in some system. In this article, we will use GitHub and go about executing the Agile project workflow.
When implementing a workflow for the team, it is always better to start simple since complex workflows usually face criticism and restrain, at least initially, from team members, since it is not easy to adapt. Therefore, we recommend these basic workflow phases/states:

  • To do – work that has not been started
  • In progress – work that is actively being looked at by the team
  • Review – work that is completed, but awaiting code review
  • Done – work that is completely finished and meets the team’s definition of done

No matter how it is achieved, each Features should have a short unique identifier (typically an integer or other code), which (Features Id) should be referenced in the Commit Messages and Features Branches.
A sprint is a group of such many Features.

Pull to update your local master

Never work on master branch. So, pull the latest updates on to your local repo.


It is important to never commit a merge at this point because we are NOT working directly in the master branch, and so should it be always. Tests should be run directly after performing pulls, merges or rebases. Just because Git does not show any conflicts, it does not mean that changes are compatible. And, as obvious as it may sound, always run tests before a commit.

Create a feature branch

For this, first make sure you are on master. Create a Feature Branch. Make sure you follow a certain naming convention while naming your branch name:

  • It should include the Feature Id or the GitHub Issue Number – This is a unique Id

It could be a hyphenated lowercase understandable concise name


The id (Dev-1) is used to identify the feature from which the branch has forked.

Do work in your feature branch

Now, the feature branch is ready for coding and test cases… and you can do that. It is advisable to commit frequently (for example, every time your tests pass the test case)


All your Commit Messages should have the Feature Id (Dev-1) referenced in it.

Keep Feature Branch up-to-date with master

This is called rebase. You will be working on the branch in order to rebase. As and when you come to know of changes made to master and also when your feature is complete – Fetch the remote master and rebase your Feature Branch with it, so that all changes are cohesive.


Another way of doing this is as below, where the master is checked out, and then rebased. But it has a few extra steps.


Complete your Feature

In general, a completed feature (in this case, Dev-1) will have a branch that has several smaller commits.
Although smaller commits are useful while developing, it is only larger commits that are easier to maintain. For this purpose, we will squash some of the commits together so that your feature can be appear as a single commit in the remote repo. This is done using an interactive rebase.

  • Begin the squash:

  • Git will display an editor window with a list of the commits to be modified. For instance:

  • Now we tell git what we need to do. Change these lines to:

Save and quit.

  • Now all these smaller commits are squashed into one commit. We can give a message in the new editor window, for the new commit. We will also use the feature id (as always) and a short message indicating the title or so as the subject, and for the body, we can list the original commit messages. Doing this will give a comprehensive description of what is being squashed:

  • And Push your changed feature branch

Create a Pull Request & Review Pull Request

On GitHub, create a pull Request to the master branch.
Usually, the team lead, or anyone authorised, needs to review the code. Based on the code review, we will have to do the following changes:

  • Obviously fixes will have to be made locally on the feature branch. Next, it has to be pushed again with: git push origin Dev-1-short-feature-name
  • This will automatically update the pull request

Once again the code is reviewed. Finally, after all changes are satisfactorily made, the pull request is approved.

Delete Feature Branch

Once the pull request is approved, it is advisable to delete the feature branch(Dev-1). This is in order to keep the repo tidy and clean.

  • Use the following command locally: git branch -d Dev-1-short-feature-name
  • On GitHub – Using the option on the Pull Request

Verify and close the feature

Pull the master and verify the feature by checking out and pulling master.


Run the test suite on the master branch. If problems are found then fixes are to be made on a new bug Branch like Bug-1. The steps will then have to be followed similar to updates. If everything is fine, close the issue and move on.


Do the same for all features and their sprints. In our experience, this Agile project workflow manages all our projects effectively. It helps us work efficiently as a team, makes the progress quicker and thereby helps us handle issues better without confusions. Try following this workflow to better your project management too. For more details, Check our github repo agiratech. Enjoy Agile Project Workflow!!

The following two tabs change content below.
Bharanidharan Arumugam

Bharanidharan Arumugam

Technical Architect | Tech Lead | Mentor | - An enthusiastic & vibrant Full stack developer has 7 plus years of experience in Web development arena. Owns legitimate knowledge in Ruby, Ruby On Rails, AngularJs, NodeJs, MEAN Stack, CMS Services. Apart all, A Modest human who strictly says "No To Harming Humans".

Leave a Reply

Your email address will not be published. Required fields are marked *