A bit of clarification regarding workflows

[Abhinav Gauniyal]

My team is new to bitbucket and infact we are using Git for very first time. I am following the Git Flow that is integrated in Source Tree and want to clarify a few things about common terms.

1. First , if I have created my repository , and want my team-members to join it , should I ask them to clone it or fork it so that they get updated with whatever changes I'm pushing to remote.

2.I know they will need to pull changes , but will both methods provide notifications to them for newer content? Also there is an option to Checkout Branch in bitbucket website. How are these 3 different?

3.Is there any method so that they do not work on whole repository and just on 'develop' branch?

4. Now I have 3 roles in my team( A, B and C) . A= admin , that is me. B= developers , they should be able to push changes and pull changes. And C should be able to pull changes , but on pushing , A should get notified before commiting those changes. How to achieve this?

[Seth]

Let's start with number 4, which also answers 1.

The main difference between forking and cloning relates to contributing changes. I would recommend that you have your developers (B) clone, which will allow them to push their changes directly to the main bitbucket repository. Role C should fork, which means that they will push changes to a forked repository, then will initiate a "Pull Request", which is basically a notification for you to review their changes and , if accepted, pull them from the fork into the main repository.

Question 2: Regardless of what software you use on the client side, an end user will be able to see that there are remote changes to pull after issuing a "Fetch" command. Some GUIs (like SourceTree) have an option to automatically fetch periodically.

Question 3: There is not a simple way to limit which branches your developers work on.

Before answering any other questions (especially pull vs checkout), I strongly recommend you read some of the excellent Git documentation. Many behaviors of Git/Mercurial seem counterintuitive if you don't understand the model. Try the Git Book (freely available online at that link) for starters. Especially make sure you read section 1.1 and chapters 2 and 3, keeping in mind that all of SourceTree's operations (except a few of the extended integrations) are directly translated to git commands.