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:

  1. Clone or initialize a repository Developers either clone an existing Git repository or initialize a new one (git init).

  2. Create a feature branch Work on a separate branch to develop new features (git checkout -b new-feature).

  3. Make changes and commit Modify files, stage them (git add .), and commit (git commit -m "Description of changes").

  4. Push to remote repository Send changes to a shared repository (git push origin new-feature).

  5. Open a pull request (PR) Request a review of changes before merging into the main branch.

  6. 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:

  1. Fetch to see the latest changes from remote.
  2. Pull the base branch (development or main) to update your local.
  3. Rebase your working branch onto the base branch.
  4. 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:

  1. Rebase and merge branch.
  2. Delete branch on remote.