1.
Collaboration with Git
& Bitbucket
Pikicast R&D
Jack Pham

2.
Pull Request and
Code Review

3.
Anatomy of a Pull Request
source repo
target repo
source branch
target branch
Reviewers
Reviewers
Merge
pull request

4.
Pull request process
A developer creates the feature in a
dedicated branch in their local repo. feature
The developer pushes the branch to a
public Bitbucket repository.
local repo
public repo
push
feature
The developer files a pull request via
Bitbucket.
file a pull request
feature
master
master
Reviewers
The rest of the team reviews the code,
discusses it, and updates it.
The project maintainer merges the feature
into the official repository and closes the
pull request. public repo

5.
Workflows with Git

6.
feature
master
feature
Centralized Workflow Feature Branch Workflow
Gitflow Workflow Forking Workflow

7.
Centralized Workflow

8.
Working Workflow
- Everybody working on the same
branch$ git pull # Update latest code
# Edit files
$ git add <file> # Stage file
$ git commit # Commit change
$ git push # Push to remote repo
pull
pull
push
origin/master
origin/master
push
Cannot push because
the base has changed
origin/master
master
pull
merge
rebase +
fast-forward merge
origin/master
master
origin/master
master
push

9.
When to use
- Everybody working on the
same branch
- Simple flow
- No review or feature
request allowed
- More conflict if many devs
+Easy to manage
+Good for less prone to
change project
+Good for maintaining
project
Infra Team ?

10.
Feature Branch
Workflow
feature
master
feature

11.
Feature Branch Workflow
- There are:
- One master branch
- Many feature branches (each for a feature)
- Each feature is developed on a dedicate branch
- A pull request is filed when feature is completed
- Feature branch is closed (delete) after finish
feature
master
feature

12.
Working on crazy_feature
# Implement the feature
$ git add <file> # Stage file
$ git commit # Commit change
$ git pull # Update latest code
$ git checkout -b crazy_feature
$ git push -u origin # optional
master
feature
master
feature
master
crazy_feature
Local Remote
crazy_feature
master
crazy_feature
master
crazy_feature
master
1.0
crazy_feature
master
1.0
$ git push # Push to remote repo

13.
Finalise crazy_feature
# Implement the feature
$ git add <file> # Stage file
$ git commit # Commit change
$ git push # Push to remote repo
feature
master
feature
Remote
crazy_feature
master
crazy_feature
master
Local
hotfix or
other feature
crazy_feature
master
hotfix or
other feature
Reviewers
master
master
Merge
Rebase

14.
When to use
feature
master
feature
- Dirty master branch
- Develop vs. Production
- Feature vs. Hotfix
- NO Release tracking
+Relatively easy to manage
+Code review support
+Good for internal project
(no hand off release to
end-users)
Simple team structure, focus
task, few concurrent task

15.
Git-flow Workflow

16.
- There are:
- One master branch
- One develop branch
- One temporary branch for each release
- One feature branch for each feature
- One temporary hotfix branch for each hot fix
Git-flow Workflow anatomy

17.
Development
semantic versioning
Release
Feature Branch Workflow

18.
Gitflow conventions
- Master branch tracks release
- Develop branch tracks feature/issue development
- Hot-fix branches are always branched off master
branch
- Feature/issue branches are always branched off
develop branch
- Release branches are always branched off develop
branch
Branching

19.
Git-flow conventions
- Feature branches are always be merged to only
develop branch after finish
- Hot-fix and Release branches need to be merged to
both master and develop branch after finish
- Only hot-fix and Release are allowed to merge to
Master branch
Merging

20.
Gitflow conventions
- Feature branches should be named: feature/<name>
- ex: feature/walkthrough
- Hot fix branches should be named: hotfix/<name>
- ex: hotfix/reallyhotfix
- Only hot-fix and Release are allowed to merge to Master
branch
- ex: release/v1.0
Naming

21.
Gitflow Tools (Source Tree)

22.
When to use
- Many branch
- Need follow convention to
have smooth
management
+Separate release and
development
+Multi-thread
+Prevent dirty branch history
+Good for end user product
with release base
Big team, multiple group and
concurrent feature, and regularly
release

23.
Forking Workflow

24.
Forking Workflow
Official CloneClone Official CloneClone
Team1 Team2 Team3

25.
Forking Workflow
Centralize
Feature Branch
Git-flow
- Each clone repo can be a
central repo of a group
- Each may organised as
other work flow

26.
When to use
- More than one central
repo
- Huge and distributed
- Large scale project
Open source project

27.
Reference
• Reading
• https://www.atlassian.com/git/tutorials
• https://git-scm.com/book/en/v2
• https://www.youtube.com/watch?v=OMLh-5O6Ub8
• Git hosting with pull-request
• Bitbucket, Github, gitLab…many more