# 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)