Guidelines
Git

Git

Use a .gitignore file

A .gitignore file is used to tell Git which files or directories to ignore when committing changes to a repository. Using a .gitignore file can help you maintain a clean and organized repository, while also ensuring that sensitive or irrelevant files are not accidentally committed to the repository.

The website gitignore.io (opens in a new tab) can help you generate a .gitignore file tailored to the technologies used in your project.

Use the Conventional Commits convention

The Conventional Commits convention (opens in a new tab) is a set of guidelines for writing commit messages that are both human-readable and machine-readable. Using the Conventional Commits convention can help to standardize commit messages and make it easier to automate versioning and release processes.

Perform work in a feature branch

A feature branch is a separate branch that is used to develop a new feature or make changes to the codebase. Performing work in a feature branch allows developers to isolate their changes and easily merge them into the main codebase when they are ready to be reviewed and deployed.

Branch out from develop branch

Branching out from the develop branch rather than the main branch (often referred to as the "master" branch) ensures that the code in the feature branch is always based on the most up-to-date version of the codebase, rather than on outdated code in the main branch.

Do a pull request to merge into the develop or main branches

Never push directly into the develop or main branches.

Doing a pull request to merge into the develop or main branches allows for an additional review process and ensures that any changes are properly documented and tested before being merged into the main codebase.

Protect the develop and main branches

In a collaborative development environment, it's important to protect the develop and main branches. Protecting these branches means putting certain restrictions in place to prevent changes from being made to them without proper review and approval. This ensures that changes made to the codebase are reviewed and approved by other team members before they are merged.

Here's how to enable branch protection depending on the service you use.

Do an interactive rebase before making a pull request

Developers should do an interactive rebase before pushing their feature and making a pull request. This allows them to clean up their commit history and make sure that their changes are organized in a logical and easy-to-follow way. It can help to avoid merge conflicts and ensure that the feature can be smoothly merged into the develop branch.

# 1. Change your current branch for develop
git checkout develop
# 2. Pull develop changes
git pull
# 3. Change your current branch for your feature branch
git checkout <feature-branch>
# 4. Do an interactive rebase from develop into your feature branch
git rebase -i --autosquash develop
# 5. If your have conflicts, fix them then add the changed files then continue the rebase
git add <file1> <file2> ...
git rebase --continue
# 6. Force push to change the history of your feature branch
git push -f

Validate your feature branch before making a pull request

Building and testing code on the feature branch allows developers to catch any problems before they are merged into the main codebase, which can save time and effort in the long run. Developers should make sure their feature branch builds successfully and passes all tests and validations before making a pull request.

Avoid Git hooks to run pre-validation

Git hooks are scripts that are run automatically by Git at specific points in the Git workflow, such as when committing or merging changes. Pre-commit hooks can be used to run validations on the code before it is committed, ensuring that the code meets certain standards and is free of errors.

However, Git hooks can easily be overridden by "developers in a hurry", must be installed on each of the team's developer workstations, do not allow committing work in progress to a work branch, and generally cause more friction than benefit in the developers' work.

Avoid their use and prefer the use of automated validation tasks that only execute on code that is ready to be validated.

Use pull request automated validations

Automated validations can be added to pull requests to ensure that code changes meet certain standards or requirements, and to catch mistakes before the code is merged into the main branch, making it easier to maintain the quality and integrity of the codebase.

Here's how to add pull request automated validations depending on the service you use.

Squash merge the feature branch pull requests

Squashing a merge of a feature branch combines all of the commits into a single commit when it is merged into the destination branch, which can improve code quality and reduce clutter in the commit history. It can also make it easier to roll back or undo changes, as there is only one commit to undo instead of several.

However, it's important to keep in mind that squashing a merge will result in the loss of some of the granular commit history, which may be important for understanding the development process or for debugging. In these cases, it may be more appropriate to use a regular merge instead.

Delete local and remote feature branches after merging

Deleting local and remote feature branches after merging can help to keep the repository organized and can reduce clutter, as it removes branches that are no longer needed. It can also help to prevent confusion and ensure that the commit history is easier to understand.

# Remove your local feature branch if you're done
git branch -d <feature-branch>
 
# Or simply remove all local branches which are no longer on remote
git fetch -p && for branch in `git branch -vv --no-color | grep ': gone]' | awk '{print $1}'`; do git branch -D $branch; done
Last updated on
Paradigms and PrinciplesDocumentation and Comments