---
# System prepended metadata

title: Git Workflow
tags: [Technology, Git]

---

# Git Workflow

This document provides a guide to Git workflow, including branch naming, commit messages, and common commands.

###### tags: `Git` `Technology`

> **Date**：2023/06/01
> **Taker**：Sin
> **Version**: 0.0.3

## Branches

### Naming

> 五種分支: `master(main)`, `develop(dev)`, `hotfix`, `release(test)`, and `feature`.

### Usage

1. **master(main)**: Product Version
2. **develop(dev)**: 開發
3. **hotfix**: 從 `master(main)` 切出來的分支，緊急修復完後，合併到 `master(main)` 和 `develop(dev)`。
4. **release(test)**:  發布前的測試版
5. **feature**: 開發功能的分支
6. 補充: 參照Github flow
   - 常用 feature/* , feature-* 的形式命名
   - 常用 hotfix-* , hotfix/* 的形式命名，在 test 建議不要建立hotfix直接 進版/重壓版

## Commit Messages

### Prefixes

1. **Feat**：新增或修改功能（feature）
2. **Fix**：修補 bug（bug fix）
3. **Docs**：文件（documentation）
4. **Style**：格式，不影響程式碼運行的變動，例如：white-space, formatting, missing semi colons
5. **Refactor**：重構，不是新增功能，也非修補 bug 的程式碼變動
6. **Perf**：改善效能（improves performance）
7. **Test**：增加測試（when adding missing tests）
8. **Chore**：maintain，不影響程式碼運行，建構程序或輔助工具的變動，例如修改 config、Grunt Task 任務管理工具

### What should the Commit content be?

一個好的 Git Commit Message 必須兼具 What & Why & How，能幫助開發者瞭解這個提交版本：

1. 做了什麼事情（What）
2. 為什麼要做這件事情（Why）
3. 用什麼方法做到的（How）

### Commit with Release

#### Test: `develop(dev) -> release(test)`

```
Feat: Version upgrade from x.x.x to x.x.x
    1. Something feature
```

#### Release: `release(test) -> master(main)`

```
Merge: Version upgrade from release(test) into master(main) for version x.x.x to x.x.x
    1. Something feature
```

### Commit with Work Order

#### Single line completion

```
Feat: Modified something feature by monday xxxxxxxxxx
Feat: Modified something feature by mantis xxxxxx
```

#### Multi-line completion

```
Feat: Modified something feature
Monday ID: xxxxxxxxxx
Feat: Modified something feature
Mantis ID: xxxxxx
```

## Settings

### Disable Case Ignorance

```bash
  # For a single project
  git config --local core.ignorecase false

  # For global settings
  git config --global core.ignorecase false
```

## Common Commands

### Merge Branch and Create New Commit

```bash
  git merge --no-ff branch
```

### Delete Branch

```bash
  git branch -d dev
```

### Set Tag (Only for Master)

```bash
git tag -a x.x.xx
```

### Push Tag to Remote

```bash
git push origin --tags
```

### Hard Reset to Previous Commit

```bash
git reset --hard HEAD~1
```

### Git Pull with Rebase

```bash
git pull --rebase
```

### Modify Git Remote

```bash
git remote set-url remote-name url
```

## Repository Naming

#### Example: `lowercase-with-hyphens `

1. Use lower case.
2. Use dashes.
3. Be specific.
4. "_" is harder to type than "-".
5. Avoid using camel case because camel case usually have different word interpretations, for example, checkinService
   vs. checkInService.

### Readme and ChangeLog Naming

Use `README.md` and `CHANGELOG.md`.

## Project File

### Adding a New Line to the End of a File

Some C compilers cannot parse the last line if it does not end with a newline. The C standard specifies that a C file
should end with a newline. A file that does not end with a newline is not considered a text file.

## References

1. [Git Commit Message Guide](https://hackmd.io/@Heidi-Liu/git-commit-message)
2. [Naming Convention for Git Branches and Commits](https://dev.to/varbsan/a-simplified-convention-for-naming-branches-and-commits-in-git-il4)
3. [Git Branching Name Convention](https://dev.to/couchcamote/git-branching-name-convention-cch)
4. [Naming Convention for Git Repositories](https://stackoverflow.com/questions/11947587/is-there-a-naming-convention-for-git-repositories)
5. [Git Branching Model](https://git-tutorial.readthedocs.io/zh/latest/branchingmodel.html)
6. [Why Add a New Line at the End of a File](https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file)
