The aim of this chapter is to introduce you to our way of work in regards to the software implementation cycle. This is a core task you need to understand when working with us. We use a pull-request cycle much the same as how Github uses pull-requests to build Github.
We use pull requests as an implementation and means of communication. Development questions are not asked in mails or skype but in pull requests. This allows us to keep track of all the questions, code and helps us to write sample code in the pull request if you need help.
After this chapter you will be able to:
- Understand the branches structure
- Understand the implementation cycle.
- Be able to work with us in a team, ask for help, and do a peer review.
We use a pull request based workflow, which means that we create pull requests for every piece of code we add to our code base. This can be features, bugs or overhaul refactorings. The benefit of this approach is that all code changes are isolated, easy to detect and manipulate in git history and visible to others.
The branch master is always stable and tested. It should be able to deploy it at any time on any server without breaking the product. Therefore we develop our features in so called feature branch. You can push to your feature branch as often as possible, but only merge when the feature is done and testing done.
Push often but for sure end of day
Be sure to push your changes every day end of day.
Picking something to build from the backlog
- Get an item from the backlog.
- Assign it to yourself.
- Move it to in-progress.
Making the pull request as early as possible
- Make sure that you have your
- Create a branch with meaningful name off
master. To clarify: Let’s say you are building login functionality. Then you’d call the branch:
feature/implement-user-login. Valid examples of meaningful names are:
bug/fix-reset-password. Wrong ones:
fix/all-the-bugs. Use this prefixes:
feature/prefix for features.
- Make the change to the file
- Commit this, push your branch to Github.
- Create a pull request, comparing with
master. Yes, this is even before you started your real work.
- Fill in the pull request template
- Create a meaningful title for the pull request. For instance:
Implement login #WIP. Add a
WIPtag to the pull request title in order to indicate that the work in this pull request is in progress.
- Write a task breakdown that need to be done in the Pull request description using the github tasks notation
Implementing the feature
- Code, commit and push as often as you can. Be transparent to others on the team on what you are working on. Push daily many times, so everyone can see your current progress.
- Use meaningfull commit descriptions. Start with a capital. A meaninful commit can be: “Adding styling for login screen.” or “Fix for failing login test.”
- Prevent double or lazy commits. Squash double or redundant commits
- Rebase with master often in order to ease merging with master in the end.
Asking for help on the pull request
@mentionsomeone if you need help. Tell what you are struggeling with, be clear an concise.
- Make the problem visible. In case its something you need to show, please have it deployed for other people to see or make s Jing screencast or Licecap in order to demonstrate the issue.
Submitting for pull request and asking for review
- Make sure the task is done according to the definition of done.
- Check your own pull request. A lot of things are missed easily.
- Make sure that there are tests and that they succeed if there is a test policy in place.
- Make sure that the code is deployed on Heroku App Reviews and visible for other people to see.
- Make sure that the current branch is up to date with master in order for an easy merge. The prefered method is rebasing with master. It is your responsibilty that we can merge without issues or conflicts with master.
@mentionpeople telling that you want to merge and ask them for a peer review and announce your merge in Slack so other people can start the peer review process.
- After all is feedback is implemented your ready to merge.
Merging a pull request
- Press the github merge button
- Delete the remote branch
- Ensure that it is deployed to staging environment and make sure staging works.
- Celebrate and drink!
Rinse repeating the process
Repeat the cycle for all items in the backlog.
How to do a pull request review
Often you need to do a review on your collegues code, here is a handy guide on what to be aware of.
Please check the following:
- Are the conventions followed?
- Check the code quality, can the intent of the code be read easily, is the code simple and easy to read? If this is not the case, please make line comments indicating what is wrong.
- Are the tests correctly implemented. Do they pass?
- Has the styling been applied in the right way?
- Does the code match the general architectural style of the project?
- Is there no dead code? Unused code, or code commmented out? Remove that.
Getting your topic branch up to date
Rebasing with master to get your topic branch up to date
First checkout the master branch and make sure its up to date:
git checkout master git pull
Then start the rebase:
git checkout feature/my-feature git rebase master
In case there are any conflicts, please solve them and then
git rebase --continue to continue the rebase.
When done with the rebase use the following command to force push your topic branch:
git push -f
Merging from master to get your topic branch up to date
Sometimes its just to messy or to painful to do a rebase. Especially if you have a lot of commits. Just go for a master to topic branch merge then.
git checkout feature/my-feature git merge master
when all conflicts are resolved, if any
git commit git push