Git - fisocodes/oscar-figueroa-consulting GitHub Wiki
Workflow
Git workflow refers to the process of managing code changes using Git, a popular version control system. Here’s a brief breakdown of a typical Git workflow:
-
Clone or initialize a repository Developers either clone an existing Git repository or initialize a new one (git init).
-
Create a feature branch Work on a separate branch to develop new features (git checkout -b new-feature).
-
Make changes and commit Modify files, stage them (git add .), and commit (git commit -m "Description of changes").
-
Push to remote repository Send changes to a shared repository (git push origin new-feature).
-
Open a pull request (PR) Request a review of changes before merging into the main branch.
-
Merge and deploy Once approved, the feature branch gets merged (git merge new-feature), followed by deployment.
This workflow keeps code organized, minimizes conflicts, and improves collaboration.
Branching
The base branch is named main
. All deployments come from this branch.
All new branches must start in development
and then rebased back to development
, except for hotfix/*
branches which must start in main
and then rebased back to both main
and development
.
Branch naming convention
All branch names except for main
and development
must have the following structure:
SCOPE/ISSUE NUMBER
where SCOPE is always written in lower case and can be any of this options only:
- feature For new features or functionalities.
- refactor When files, variables, constants and/or classes must be renamed.
- format Setting code with standard style/format.
- fix For fixing not critical bugs.
- hotfix For fixing critical bugs.
- documentation For updating or adding documentation, for example README.
and ISSUE NUMBER is the number of project's task on GitHub.
Committing
Always have one commit, squash if needed.
Commit message convention
Commit messages must have the following structure:
TYPE: MESSAGE.
where TYPE is always written in UPPER CASE and can be any of this options only:
- FEATURE For new features or functionalities.
- REFACTOR When files, variables, constants and/or classes must be renamed.
- FORMAT Setting code with standard style/format.
- FIX For fixing not critical bugs.
- HOTFIX For fixing critical bugs.
- DOCUMENTATION For updating or adding documentation, for example README.
Fetching and push
Always update your branch with the most recent changes. To keep your branch up to date follow the steps below:
- Fetch to see the latest changes from remote.
- Pull the base branch (
development
ormain
) to update your local. - Rebase your working branch onto the base branch.
- Push or force push to update the remote of your working branch.
Pull requests
Always follow the guidelines when making a new pull request. Stick to the following checklist.
- Name the PR after the task with the format [ISSUE NUMBER] ISSUE NAME.
- Add a small description of what you worked on.
- Make sure you removed unnecessary comments and test logs.
- Check that the code is formatted correctly.
- Double check that the branch is up to date and rebased (not merged).
- Add test instructions.
Mergin
After changes have been tested, approved and followed the PR checklist do the steps below:
- Rebase and merge branch.
- Delete branch on remote.