Development Workflow - mestafrica/mkoo GitHub Wiki

Development Workflow

This is a documentation of steps to be taken whiles working with the codebase. This is documented for all team members to be aware of the processes to go through for the code written to be qualified to ship.

The team uses a shared repository for development. Each team member has write access to the repo. The following sections describe a typical git workflow used on this project.

The initial setup requires that every developer clones the remote repository or adds the remote repository as additional remote to his local repository. Then checkout the develop branch to contribute code to the repository.

$ git clone [email protected]:mestafrica/mkoo.git
$ git checkout develop

To develop a change and integrate it into the code repository, you would:

  • Create a new local branch for the feature/bug fix
  • Change content in the working tree, add and commit your changes
  • If required, switch to other branches to do other work
  • Once the development in the branch is complete, rebase (or merge) the commit history onto the relevant remote-tracking branch (develop) to allow a fast-forward merge for your changes
  • Run the Unit & Browser tests to make sure they are not failing.
  • Push your changes to the remote repository; this results in a fast-forward merge in the remote repository

Testing, Testing and Testing

Before checking in your code to the remote code repository, run all tests to make sure they are not failing neither are they throwing warnings.

Using branches

There are already two remote tracking branches (develop and master). You can create additional branches for your features and bug fixes.

master

This branch is read only. You must not push directly to this branch, if it becomes necessary to do so, 1 person should be responsible for that.

develop

Your changes will get merged into develop after review. Essentially, changes contained in pull requests end up being merged into the develop branch for further testing before merging into master.

Typically, you would create a local branch for every feature or bug fix you work on. Once you are done with the feature, you push your changes upstream. You can then open a PR for your new changes.

Git emphasizes the creation of branches for feature development or to create bug fixes. During this development you may fetch and merge or rebase the changes from the remote repository at any point in time. The developer may use the pull command instead of the fetch command.

Note: Always remember to pull changes from the remote repository (to get latest changes from other team members) before pushing.

References / Further Reading