git collaboration
TRANSCRIPT
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