Code review in Bitbucket using Git

Question

We are moving from the Visualstudio.com/TFS combination and we are studying the possibilities. I am very excited with the Jira/Bitbucket combination.

Many of our developers are not used to Git development, so we do not the have concept of private branching and so on, everybody is working on a single branch from which we get the code to make the deploys.

We have a major requirement when it comes to code review: we would like to have code reviewers assigned to projects/folders in the project and they would be notified of every commit to that project/folder and, only after the approval, the changes would be commited to the branch.

I know that one could create their own branch and then create a pull request, but this process seems to have many steps, including accessing bitbucket website and using its GUI. I would like to have something automatic (each commit => one notification to the responsible).

Is this possible to do?

Our process is not carved in stone, but I would rather change it smoothly so we have low barriers to the changes we are implementing.

Thanks!

oscar albrecht · Answer

That is a lot of resources, thanks a lot!
I will take a look into everything. I think we are going to "start slow" so our team get used to git and improve our experience as we get experienced.
Just for sake of completeness, if anyone is looking for some resource to learn git, I gound  this link very useful: http://pcottle.github.io/learnGitBranching/

Seth · Answer

Also, you will see references in some places to "Git Flow". Please know that Git Flow is a Git extension to support a popular workflow/branching model, but it is not required as part of Git. My company uses Git Flow, but it isn't a perfect fit. You can ignore it completely and use a completely different branching model if that is what's right for your team.

Seth · Answer

I mentioned SourceTree, which is another Atlassian product, integrates well with Bitbucket, is completely free, and works well (at least in my experience).

On a separate note, you should encourage your team to read/skim the Git Book, especially sections 1.1-1.3 and all of chapters 2 and 3.