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.

After this chapter you will be able to:

  • Understand why we use pull requests
  • Understand the branches structure
  • Understand the feature implementation cycle.
  • Be able to work with us in a team, ask for help, and do a peer review.

Why pull requests.

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. After that code has been tested in isolation we merge it into the master branch. Where people start branching of and start building new pull requests.

We use pull requests to:

  • Develop features seperately from our master stable branch
  • Test and review the code seperately
  • Keep track of different features in progress before merging it back to the master codebase.
  • As a means of communication.

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 as a team to keep track of all the questions, code and helps us to write sample code in the pull request if you need help.

Branches structure

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

  1. Get an item from the backlog.
  2. Assign it to yourself.
  3. Move it to in-progress.

Making the pull request as early as possible

  1. Make sure that you have your master up-to-date using git pull.
  2. 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: feature/implement-signup, bug/fix-reset-password. Wrong ones: fix/all-the-bugs. Use this prefixes:
    • feature/ prefix for features.
    • bug/ for bugfixes.
    • refactor/ for refactoring.
  3. Make the change to the file
  4. Commit this, push your branch to Github.
  5. Create a pull request, comparing with master. Yes, this is even before you started your real work.
  6. Fill in the pull request template
  7. Create a meaningful title for the pull request. For instance: Implement login #WIP. Add a WIP tag to the pull request title in order to indicate that the work in this pull request is in progress.
  8. 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

  • @mention someone 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.
  • @mention people 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.
  • Check if there are new dependencies introduced. Maybe a new gem? Maybe a new Javascript library. If so, what are the reasons and do they match the requirement. Are they maybe to bloated? Try to have as least dependencies as possible and use balance between requirements and lines of code. Are the gems, libraries still being maintained? Do they have critical issues? Alwas be wary of introducing new dependencies.
  • 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