Collaboration with Git & Bitbucket

Pikicast R&DJack Pham

Pull Request and Code Review

Anatomy of a Pull Requestsource repo

target repo

source branch

target branch

Reviewers

Reviewers

Merge

pull request

Pull request processA 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 requestfeature

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

Workflows with Git

feature

master

feature

Centralized WorkflowFeature Branch

Workflow

Gitflow Workflow Forking Workflow

Centralized Workflow

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

pullmerge

rebase + fast-forward merge

origin/master

master

origin/master

master

push

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 ?

Feature Branch Workflow

feature

master

feature

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

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

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

Recommened !!

When to usefeature

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

Git-flow Workflow

- 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

Develo

pm

en

t

semantic versioning

Rele

ase

Feature Branch Workflow

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

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

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

Gitflow Tools (Source Tree)

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

Forking Workflow

Forking WorkflowOffici

alCloneClone Offici

alCloneClone

Team1

Team2

Team3

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

When to use

- More than one central repo

- Huge and distributed

- Large scale project

Open source project

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