This repository uses two main branches: develop and master.
The first one is the one you should use to work on a new feature, even more, it's the one that we use on a daily base to commit and discuss our work.
The second one is the one we cut from develop every time that we reach a milestone. You should use master as the base branch of pre-release or production bug fixes.
Whenever you begin work on a new feature or bugfix, it's important that you create a new branch from develop or master; particularly, you should create a new branch from master only to fix issues identified in production or in the pre-production environment.
Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
To create a new branch and start working on it:
# Checkout the master branch - you want your new branch to come from master
git checkout master
# Create a new branch named _TICKET-NUMBER-short-feature-description_
# (give your branch its own simple informative name)
git branch feature/TICKET-NUMBER-short-feature-description
# Switch to your new branch
git checkout feature/TICKET-NUMBER-short-feature-descriptionNow, go to town hacking away and making whatever changes you want to.
To distinguish features, bugs and minor updates such formatting, versioning, and so on please prefix the branch name with bugfix or minor.
Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.
If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
# Fetch upstream master and merge with your repo's master branch
git fetch upstream
git checkout master
git merge upstream/master
# If there were any new commits, rebase your development branch
git checkout feature/TICKET-NUMBER-short-feature-description
git rebase masterNow, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
# Rebase all commits on your development branch
git checkout
git rebase -i masterThis will open up a text editor where you can specify which commits to squash.
Once you've committed and pushed all of your changes to git, go to the page for your fork on git, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.
Open up the .git/config file and add a new line under [remote "origin"]:
fetch = +refs/pull/*/head:refs/pull/origin/*
Now you can fetch and checkout any pull request so that you can test them:
# Fetch all pull request branches
git fetch origin
# Checkout out a given pull request branch based on its number
git checkout -b 999 pull/origin/999Keep in mind that these branches will be read-only and you won't be able to push any changes.
Especially when you are working on develop, we strongly encourage to create a small pull request.
We understand that this can prevent you to progress at the desired pace, so we decided that when a pull request is stale for more than 24 hours, you can merge it by yourself.
In this case, it's important that you squash all the commits in a single one so that we can eventually rollback to a previous state of the develop branch.
Once the pull request gets merged, please don't forget to delete your branch to keep the code line clean and well organized.
LGTM