A bit of clarification regarding workflows

Abhinav Gauniya

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.