Version Control

Version Control

Version control allows us to track codebase history, maintain parallel tracks of development, and collaborate without stomping out each other's changes.

Commits

Commits should be small and independent items of work, containing changes limited to a distinct idea. Distinct commits are essential in keeping features separate, pushing specific features forward, or reversing or rolling back code if necessary.

Commit Messages

The first line of a commit message is a brief summary of the changeset, describing the expected result of the change or what is done to affect change. It's important to craft something that is as descriptive as possible within the 70 character limit.

git log --oneline -5

# fca8925 Update commit message best practices
# 19188a0 Add a note about autoloading transients
# 9630552 Fix a typo in PHP.md
# 2309e04 Remove extra markdown header hash
# 5cd2604 Add h3 and h4 styling

Pull Requests

Pull requests let you tell other engineers about changes you've pushed to a repository. Once a pull request is sent, fellow engineers can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Creating a Pull Request

To create a pull request, we need to create a branch from the latest commit on master. It's important that your repository is up to date to prevent conflicts when it's merged to master.

git pull origin master

Note: git pull does a git fetch followed git merge to update a local repository with the remote repository.

Creating a Branch

To create a branch, use git checkout -b <branch-name>. Below is an example of how to create a new branch from master and push it to to github.

git pull origin master
git checkout -b feature/my-new-branch

Make file changes, stage, and commit them.

git add .
git commit -m "My new feature"
git push origin my-new-branch

Merges

In order to avoid large merge conflicts, merges should occur early and often. Do not wait until a feature is complete to merge master into it. Merging should be done as non-fast-forwards git merge --no-ff to ensure a record of the merge exists.

Configuring Repositories

Anything in the master branch is deployable. It's recommended that all repositories are configured in a way that the master branch is protected to prevent direct pushes. All merges should be made through a pull request, which ensures all code changes are peer reviewed before merging to prevent unintentional code reversions. Additionally, protecting branches provides the following benefits:

  • Prevents the master branch from being accidentally deleted by other engineers
  • Prevents force-pushes to the branch, overwriting the history
Edit this page on GitHub Updated at Wed, Oct 12, 2022