Git Workflows
Viet Nguyen - QSoftVietnam
When we don't understand Git:
- Don't know how to resolve conflicts properly
- Need to spend too much time for correcting wrong commits or merges
- The master branch is corrupted and our application is died
- Teammates need to wait for a person to fix his bad commits
- Our Git repository becomes a very big mess
... and many more
Then we $^^&%*%$^#
Outline
1. Branches
2. Workflow Overview
3. Centralized Workflow
4. Feature Branch Workflow
5. Gitflow Workflow
6. Other Workflows
7. References
Branches
Overview
- A independent line of development
+ New working directory
+ New staging area
+ New project history
+ New commits for the current branch
- Usually the default main branch is master
Playing with branches
Create a new branch:
git branch <branch_name>
Check out a branch:
git checkout <branch_name>
Create a new branch and switch to it:
git checkout -b <branch_name>
Merge the specified branch into current branch:
git merge <branch_name>
Playing with branches
Delete a local branch:
git branch -d <branch_name>
Force delete a local branch:
git branch -D <branch_name>
Rename a branch:
git branch -m <branch_name>
Delete a remote branch:
git push origin --delete <branch_name>
Git Workflow
Overview
- How we work with Git in a project
- Depends on the project workflow
- Version control of code base: features, bugs, hotfixes ...
- Structured to branches
Target
- Run on multiple environments
- Keep our Git history clean and clear
Centralized Workflow
Overview
- Use a single central repository
- Use a single default branch (master)
Basic Flow
1. Clone the central repository to local
2. Edit files and commit changes
3. Pull other's changes to integrate with local repository
4. Push local master branch to the central repository
Suggestion
- With very small projects, use Centralized Workflow
- With small projects, should extend Centralized Workflow to use at least 2 branches:
+ develop: for development enviroments
+ master: for production environment
Feature Branch Workflow
Overview
- Each feature should be in a separated branch instead of the master branch
- master branch will never contain broken code
- Pull requests
How it works
- Each feature should be in a separated branch instead of the master branch
- master branch will never contain broken code
- Pull requests
Gitflow Workflow
Introduction
- A workflow created by Vincent Driessen
- Designed around project release
- Work well for big projects
How it works
- Historical branches (master and develop)
- Feature branches (feature/*)
- Release branches (release/*)
- Hotfix branches (hotfix/*)
Historical branches
- master: official release
- develop: main branch
Feature branches
- Be created for each feature
- Use develop as their parent branch
- After completing, will be merged back into develop
Release branches
- Use for preparation of a production release
- Concentrate on bug fixes
- Use develop as their parent branch
- After completing, will be merged back into master and develop
Hotfix branches
- Use to patch production releases
- Use master as their parent branch
- After completing, will be merged back into master and develop
References
http://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://github.com/nvie/gitflow
http://danielkummer.github.io/git-flow-cheatsheet/
http://www.slideshare.net/lemiorhan/git-and-git-workflow-models-as-catalysts-of-software-development
Q & A
Thank you !
Git Workflows Viet Nguyen - QSoftVietnam
Git Workflows
By Hong Viet Nguyen
Git Workflows
- 984
