New development work on a software project is either of maintenance (fixing bugs, addressing security issues) or construction nature (adding new features). Regardless of the type of work, all new work should first be documented through an “Issue” on bitbucket where it can be discussed by the team first if needed, a new branch must be created based on the branch origin/develop to do the work and should take the name of its respective issue (e.g. issue81).

For example, let's say we're tackling issue #3 from the issue tracking system you should create a branch called issue3 locally on your machine branches from origin/develop. If you are new to git's branching and mergin start here.

All branches for new features, bug fixes, maintenance work, etc. are then merged into origin/develop which in turn gets rolled into origin/master for release cycles.

In SourceTree

See SourceTree Create Branch.

Git command line

Branch like this

> git checkout -b issue3

Work on the issue, add relevant tests so it does not occur again (proper test will be mandatory in the future for new features or bug fixing), all the while only committing locally on your branch. After all this is done you can go ahead with publishing your new fix following our defined standard procedure.

In the ideal scenario, you create your branch, do you work and prepare a PR all during which time nobody committed their work in origin/develop since you first branched from it. In real life when several developers work together at the same time things will get a little more complicated. The following two scenarios are the most likely to happen and here is how one can deal with this while still aiming to keep that nice linear history clean with squashed messages.

There is always the chance someone will get a pull request accepted before you. In that case, the proper procure is to get your own branch updated with this latest changes before you can proceed. One way to achieve this fairly easily is to track the branch origin/develop for those team changes.

In SourceTree

Git command line

> git branch --set-upstream-to=origin/develop issue3

Now our branch issue3 is tracking what ever our team merge to origin/develop. You can pull those new changes in and rewind history in a way that all those new changes are included before your own, since in the grand scheme of things (i.e. with regards to origin/develop) they were.

In SourceTree

Git command line

> git pull --rebase

If you are lucky and with good developer coordination this should be automatic. But if you happened to be working on the same thing as somebody else then this will require you to manually fix some merges not automatically possible.

From here you can continue squashing your own commits as in Contribute New Code in Branches Non-Interrupted above

Or issueX is pushed to origin/issueX to be pull requested and merged but is found out to be in need of further work.

Sooner or later you need to push your branch to origin. Maybe you are ready to start your pull request or you want to have someone else review your work. For others to access your branch it must be on origin otherwise it is only locally on your own computer. This can be done easily in SourceTree as shown in following image.