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
10. 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
11. 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 ?
13. 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
15. 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
16. 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
18. - 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
20. 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
21. 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
22. 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
24. 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
A developer creates the feature in a dedicated branch in their local repo.
The developer pushes the branch to a public Bitbucket repository.
The developer files a pull request via Bitbucket.
The rest of the team reviews the code, discusses it, and alters it.
The project maintainer merges the feature into the official repository and closes the pull request.
suite for infra team, setting file, configuration file, less likely to change.
For feature, merge are recommend because of the history clearly show which commit belong to the feature development.