==== Contribute New Code in Branches Uninterrupted ====

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 [[http://www.git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging|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 [[https://confluence.atlassian.com/sourcetreekb/branch-management-785325799.html#BranchManagement-CreateBranch|SourceTree Create Branch]].

**Git command line**

Branch like this

<code>
> git checkout -b issue3
</code>

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.

==== Contribute New Code in Branches Interrupted ====

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.

=== Someone else pushed to origin/develop before you ===

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**

FIXME

**Git command line**

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

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**

FIXME

**Git command line**

<code>
> git pull --rebase
</code>

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

=== The Software Architect suggest some new modifications before the pull request can be accepted ===

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

==== Push Branch to Origin ====

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.

{{ :developer-manual:branch-push-origin.png |}}