Development workflow

Introduction

Our development workflow depends on git to coordinate work and handle changes, for which we normally use GitHub. Another provider would likely function approximately the same.

This chapter describes the main processes in our development lifecycle.

Startup locally

Before starting development we need a copy of the source, which we will acquire by forking the source repository from GitHub and cloning it to the local development machine.

Forking a repository can be done from the GitHub user interface by clicking the “fork” button in the upper right corner. We then clone the repository locally and point our upstream to the project location to support synchronization.

For this example, we assume that we are working from a feature branch which will contain our new addition and should be available on our fork (hence the push --set-upstream).

Step by step we are going to execute the following commands locally:

git clone git@github.com:DEVELOPER/REPOSITORY.git
git remote add upstream git@github.com:ValueAConsultancy/REPOSITORY.git
git checkout -b my_feature_branch
git push --set-upstream origin my_feature_branch

Fetch upstream changes

After some time you may want to sync up your repository with the upstream changes, the process for this looks as follows:

First we are going to fetch and merge all changes from our earlier defined upstream target (the source), when our master branch is in sync with upstream, we are going to push our changes back to our own fork (repository).

git checkout master
git fetch upstream
git merge upstream/master
git push

Rebase feature branch

Now with our master branch in sync, we can rebase our feature branch and stack our changes on top. When the rebase is successful we need to make sure our fork repository is aligned.

git checkout my_feature_branch
git rebase upstream/master
git push -f

Warning

Be very careful with push -f it forces your version of the truth as being the absolute truth for the other end, which in this specific case should be harmless (as being the same data, but a different path). On the source repository itself you might up with lost commits.

Create pull request

Now that our feature branch is in sync with our upstream and contains the code needed for our new feature we can ask the upstream to pull our changes using a “pull request”.

In the GitHub user interface there is a button available next to the branch selector for this purpose.

Note

Please be aware that commits added after the pull request will automatically appear in the upstream request, since the pull request is open to the feature branch. Always make sure the other end knows your intentions.

Cleanup

When the feature is merged, you might want to remove the local branch. This can be done using the following commands. The same branch on GitHub can be deleted from the branches tab.

git checkout master
git branch -D issue_001

Practical tips

Undo the last commit:

git reset HEAD~

Use git push -f to force the same trickery on the upstream repository, but like stated before handle with extreme care.