Configure your global gitignore file, usually in your home directory named
.gitignore_global. It should contain ignore rules specific for your operating system and editor of choice. You can find these ignore rules here and add them to your global gitignore file.
After you have created your global gitignore file update the global git configuration to use your global ignore rules:
git config --global core.excludesfile ~/.gitignore_global
OPTIONAL: Color highlighting
Depending on your terminal color profile, the default Git diff coloring might not be optimal. The following colors are suggested instead:
git config --global color.ui true git config --global color.diff-highlight.oldNormal "red bold" git config --global color.diff-highlight.oldHighlight "red bold 52" git config --global color.diff-highlight.newNormal "green bold" git config --global color.diff-highlight.newHighlight "green bold 22" git config --global color.diff.meta "yellow" git config --global color.diff.frag "magenta bold" git config --global color.diff.commit "yellow bold" git config --global color.diff.old "red bold" git config --global color.diff.new "green bold" git config --global color.diff.whitespace "red reverse"
We use the Git Flow workflow model.
master branch is one of the two branches with an infinite lifetime. The source code of
HEAD always reflects a production-ready state.
develop is the second branch with an infinite lifetime. The
develop branch source code of
HEAD always reflects a state with the latest delivered development changes for the next releases.
When the source code in
develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into
master and tagged with a release number.
Next to the main
develop branches the Flow model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases, and to assist in quickly fixing live production problems.
Unlike the two main branches, these branches have a limited lifetime.
Feature branches may branch of from
develop and must be merged back into
develop. Feature branch naming convention is as follows:
feature/*, for example
It is advisable to put a unique task identificator into the branch name. Usually that would be a task ID or some other unique task property, for example
Feature branches are used to develop new features for the upcoming or a distant future release. These branches exist as long as the feature is in development. Eventually, they are merged back into
develop or are discarded.
Hotfix branches are created if you need to immediately act upon an undesired state of a live production version. If a critical bug in production must be resolved immediately, a hotfix branch can be branched off from
master branch. Similar to the feature branches, the hotfix branches are named
hotfix/*. A hotfix branch should be merged back into
A commit should round up only the related changes. For example, fixing two different bugs should produce two separate commits. Small, atomic commits make it easier for other developers to understand the changes and roll them back if needed.
Committing often will keep your commits small and help you commit only related changes. It will also allow you to share your code more frequently with others. Furthermore, it will help with avoiding merge conflicts.
git add -A to stage changes. If you have a lot of changes you can filter through them with
git add -p and stage only relevant changes.
Writing good commit messages is important. A clear commit log will be easier to navigate through and make it easier for other people to follow along. You can read on how to write proper here.
Avoid creating pull requests that contain a lot of changes. If you are implementing a feature that requires a lot of file changes, try breaking it up into multiple smaller features which results in multiple pull requests.
Smaller pull requests are easier to review and will therefore be merged sooner.
You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository. Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. More about code owners.