Mastering Team Git Workflow: Practical Tips and Git Flow Best Practices

Git History

In 2005 Linus Torvalds released Git, a tool that transformed software development workflows and remains widely used today.

Habit Formation

Without clear conventions, using Git in a team can become a nightmare; personal discipline and good habits are equally important.

Commit

Each commit should represent a small feature or bug fix, have a concise first line followed by a detailed description, and be pushed in batches rather than after every commit.

Commit granularity should be a single functional change or bug fix to minimize accidental damage during rollbacks.

Write a brief summary on the first line, then leave a blank line and elaborate on the changes.

Avoid pushing after every commit; accumulate several commits before pushing to catch early mistakes.

If a mistake is discovered before pushing, amend the commit with the same message. git rebase -i [SHA] can be used to edit or combine recent commits (replace [SHA] with the appropriate hash, e.g., 3b22372).

Push

When working alone, avoid creating a remote branch until the feature is complete.

Pull

Read the article "Using git rebase to avoid unnecessary merges" for best practices.

Merge

If the source branch is a parent of the target, prefer git rebase over git merge to keep the history clean; otherwise, use merge to avoid repeated conflicts.

Branch Management

Git allows many parallel branches, but without a mature branching model the repository becomes chaotic.

The widely adopted Git Flow model defines clear responsibilities for each branch type:

Master – stable, release‑ready code.

Hotfix – urgent bug fixes on production.

Develop – integration branch with the latest features.

Feature – development of a specific feature.

Release – preparation for an upcoming release.

Only one main branch of each type exists; derived branches can have multiple instances.

Tool Selection

Choose tools that solve the problem best; graphical tools like SourceTree are recommended for most teams, though command‑line usage is also fine.

Preparation (SourceTree)

In SourceTree preferences under the Git tab, enable "Use rebase instead of merge by default for tracked branches" and "Do not fast‑forward when merging, always create commit".

These settings make git pull --rebase the default and ensure merge commits are always created.

Initialize Git Flow via the "Git Flow" button; the dialog will set up the workflow and switch to the develop branch.

GitLab Configuration

Protect the main master and develop branches in GitLab, allowing only project owners to push or delete them.

Development Process

After defining a release date, create a feature branch in SourceTree for each functional task. Developers push the remote branch only when collaboration is needed.

When a feature is complete, merge the latest develop into the feature branch, resolve conflicts, then create a merge request in GitLab targeting develop.

Reviewers approve the merge request, delete the feature branch, and the code becomes part of develop.

When all features for a release are ready, create a release branch for testing. Bugs found are fixed on the release branch or a derived branch.

Once testing passes, merge the release branch into both master and develop, tag the release with a semantic version, and deploy to production.

Additional Notes

Branch naming conventions improve clarity:

Feature – name after the functional point, not the requirement.

Release – use the release date, optionally with a prefix.

Hotfix – include the GitLab issue number or a brief bug description.

Tags should follow semantic versioning.

Release Schedule

Consistent release cycles are crucial for team morale; irregular releases cause stress and inefficiency. Plan releases in advance and limit scope per cycle.

Original source: https://ourai.ws/posts/working-with-git-in-team/