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 $^^&%*%$^#

 

 

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