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.
Summary
- Sprint Planning – Prioritize tasks
- Pull to update your local master
- Create a feature branch
- Do work in your feature branch
- Keep Feature Branch up-to-date with master
- Complete your Feature
- Create a Pull Request & Review Pull request
- Delete Feature Branch
- 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.
git checkout master git pull origin master
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
git checkout -b Dev-1-short-feature-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)
git add -p or git add . git commit -m 'Useful commit message'
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.
git fetch origin master git rebase origin/master
Another way of doing this is as below, where the master is checked out, and then rebased. But it has a few extra steps.
git checkout master git pull git checkout Dev-1-add-comments git rebase master
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 rebase -i origin/master
- Git will display an editor window with a list of the commits to be modified. For instance:
pick 3dcd85 Add comment model, migrations, spec pick 9f5c62 Add comment controller, helper, spec pick dcd413 Add comment relationship with article pick 9ea8e3 Add form on article show page
- Now we tell git what we need to do. Change these lines to:
pick 3dcd85 Add comment model, migrations, spec squash 9f5c62 Add comment controller, helper, spec squash dcd413 Add comment relationship with article squash 9ea8e3 Add form on article show page
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:
[#Dev-1] User can add a comment to a post * Adding comment model, migrations, spec * Adding comment controller, helper, spec * Adding comment relationship with article * Add form on article show page
- And Push your changed feature branch
git push origin Dev-1-short-feature-name
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.
git checkout master git pull origin 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.
Conclusion:
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!!
