Git-flow is a branching strategy that allows development teams to effectively move their

code through the delivery life cycle.

SourceTree has Git-flow support built in, so it makes it very easy to manage
development and delivery of your features.

It's important to understand the purpose of each branch/branch type in the Git-flow
process:

 master - The master branch is the "gold standard". It represents the code that's
currently deployed to production.
 develop - The develop branch is used as the common branch shared by all
developers. Once code is merged into the develop branch, other developers can
see it by pulling down changes to refresh their local develop branch.
 feature - Each developer creates their own feature branches off of their local
develop branch. By creating your own local feature branch, you can work on your
code in isolation of other features. When your code is complete, you merge it to
the develop branch via pull requests.
 release - Each production release has a release branch that contains all of the
code for that particular release.
 hotfix - A hotfix branch is used to patch production; only used for critical and
urgent fixes.

It's also important to understand what a Pull Request is. A Pull Request in Git is used to
request other developers to review your code and provide feedback prior to merging
(pulling) it into the develop branch. The Branch team requires 3 approvals on all pull
requests; one by yourself (you should always review your own work & ensure everything
is included in the pull request) and 2 others. Once 3 approvals are in place, the pull
request can be completed and the code will auto-merge into the develop branch.

These are the basic steps each developer should take when working on a new JIRA
ticket.

1. In SourceTree, make sure you're on the develop branch. Pull the latest changes
down from TFS. Then click the Git-flow button.
2. Click the Start New Feature button.
3. Enter in the ticket # and a brief description for your feature branch. Example:
BR_4301_Modify_Customer_Tab.
4. Click the OK button to create the new feature branch.
5. SourceTree should create the new feature branch and automatically check it out
(switch you to that new branch).
6. Switch to PB 2017. Right click on your Branch target and choose "Refresh".
7. Right click on your target and do a "Full Rebuild". This is not required, but is
recommended so you know everything is in a clean state.
8. Make your code changes. Right click on modified objects and choose "Git
Commit" to commit your PB changes to the local Git repository.
9. Switch to SourceTree.
10. Click on the "File Status" option in the upper left corner (beneath WORKSPACE).
11. You should see your modified object(s). Move them all from Unstaged to Staged.
12. Enter in your check-in comment and click the "Commit" button in the bottom
right corner.
 13. Once everything is committed, click the "Push" button on the toolbar to push
your changes up to TFS. You'll have to click the checkbox next to your feature
branch the first time so it knows what to push.
14. Click the "Remote" button on the SourceTree toolbar. This will open up TFS in
your web browser.
15. If you see a link to create a new Pull Request, click it. If not, click on "Pull
Requests" in the toolbar, then click the "New Pull Request" button to the far right.
16. By default, the Pull Request will populate the Title and Description with your
feature branch name. It's recommended to update one or both to make it more
descriptive to other developers that may not know what your changes are for.
17. Review your changes by clicking the "Files" link at the bottom of the Pull
Request. Every object you've modified (PB or non-PB, such as rules scripts, etc.)
should be showing here. It also allows you to compare your changes. If
everything checks out, click the "Create" button. If not, cancel the pull request &
return to PB or your text editor (for scripts, etc.) and make the necessary
changes. Push them up to TFS and create a new pull request and repeat the
same steps to verify.
18. Once your Pull Request is created, review it and ensure it looks good. If so, click
on the "Approve" button to let other developers know you've signed off on your
changes and they can now review and approve. If they find any issues with your
Pull Request, they will add comments and reject it - your signal to make the
corrections and re-approve.
19. Click the Auto-Complete button (optional). By setting Auto-Complete, the Pull
Request will automatically complete itself after the 3rd and final approval and
merge to the develop branch. If you do this, be sure the checkbox to
automatically delete the feature branch is unchecked (you'll do this later in
SourceTree).
20. After the Pull Request is complete, return to SourceTree.
21. Click on the Git-flow button, and click the "Finish Feature" button.
22. It will prompt you to delete the local and remote feature branches. Make sure
both are selected and click OK.

These are a lot of steps, but they're easy to learn and repeat after you've done it a few
times. Just be patient and read through carefully step-by-step as you're learning.

One final note on feature branches - they are always intended to be temporary. The
only permanent branches are develop and master (and sometimes release branches).
So the best practice is to finish your features as outlined above and delete your feature
branches (locally and remotely) once a Pull Request is completed. Once your code is
merged to develop, there is no need for the feature branch any longer. If you have a
bug fix later, you can always create a new feature branch and follow the same
processes to get it into TFS via Pull Request.