Version control · Git · Workflow

Version Control, Git and Branching Strategies: Which Workflow Fits Which Team

Every team that writes code needs to answer three questions: where does the history live, how do we work on things in parallel, and how does finished work reach users? Version control answers the first, Git is the tool most teams pick, and a branching strategy answers the other two. This article covers all three, with diagrams, and ends with the tools you can use to drive Git every day.

1. Version control overview

Without version control, a project folder fills up with report_final.docx, report_final_v2.docx and report_REALLY_final.docx. With two people editing, someone overwrites someone else. With a bug in production, nobody can say which change caused it.

A version control system fixes this by keeping a complete, searchable history of a project. Each saved state is a commit with an author, a time and a message. The system lets you:

• Go back. Restore any file, or the whole project, to how it was last Tuesday.
• Compare. See exactly which lines changed between two versions, and who changed them.
• Work in parallel. Two people (or one person with two ideas) change the same project at once, then merge the results.
• Find bugs. Ask which commit introduced a problem, and read why it was made.
• Release with confidence. Tag the exact code that shipped as version 2.4.

Three generations of version control

Words you will meet in every VCS

2. Git: how it works

Git (official site: git-scm.com) was written in 2005 by Linus Torvalds to manage the Linux kernel, after the tool the kernel team had been using became unavailable to them. It was designed to be fast, to handle thousands of parallel branches, and to need no central server. It is now the default choice, used by most open source projects and most companies.

Snapshots, not differences

Older systems stored each version as a list of changes to a file. Git thinks differently: every commit is a snapshot of the whole project at that moment (files that did not change are stored once and shared). A commit points to its parent, so the history is a chain, and a merge is a commit with two parents. Each commit has a unique ID, a hash such as 9fceb02. Because the ID is computed from the content and the parent, history cannot be changed silently.

The four places your work lives

• Working directory: the files you see and edit.
• Staging area (index): a draft of your next commit. You choose exactly what goes in, so one commit can hold one idea even if you changed five things.
• Local repository: the .git folder with all commits. Committing is instant and needs no network.
• Remote: a copy on a server (GitHub, GitLab and so on) that the team shares.

A branch is only a label

In Git a branch is a small pointer to a commit. Creating one costs almost nothing, which is why Git encourages branching for every task. HEAD says which branch you are on.

3. The commands you use every day

# start
git clone https://github.com/you/project.git
git switch -c feature/login          # create and move to a new branch

# save work
git status                           # what changed?
git add src/Login.kt                 # stage one file (or: git add -p to pick pieces)
git commit -m "Add login form validation"

# share and update
git fetch                            # download new commits, change nothing
git pull --rebase                    # update your branch on top of the remote
git push -u origin feature/login     # publish the branch

# combine
git switch main
git merge --no-ff feature/login      # or merge through a pull request

# look around
git log --oneline --graph --all
git diff                             # unstaged changes
git blame src/Login.kt               # who changed each line, and in which commit

Undoing things safely

Two files belong in every repository. A .gitignore lists what Git must not track (build output, node_modules, IDE settings, and above all secrets such as .env). A README.md tells a newcomer what the project is and how to run it. If a secret is ever committed, treat it as leaked and rotate it; deleting it in a later commit does not remove it from history.

4. Alternatives to Git

Git is the right default, but it is not the only option, and knowing the others helps you understand Git’s design and spot the cases where it is a poor fit.

Older systems you may still meet in legacy code bases: CVS, Visual SourceSafe (retired) and TFVC, the centralized option in Azure DevOps (Microsoft recommends Git for new projects).

5. Branching and merging basics

A branching strategy is a team agreement about which branches exist, what each is for, and how work flows between them. To compare strategies you first need the three ways to bring a branch back, and a few guard rails.

Three ways to integrate a branch

Guard rails

• Protect the main branch. Require a pull request, at least one review and passing CI. Block force-pushes.
• Name branches so they explain themselves: feature/login-form, fix/crash-on-rotate, release/2.4, hotfix/payment-timeout. Many teams add a ticket number.
• Write good commit messages: a short summary line in the imperative (“Add retry to upload”), then a body that explains why.
• Tag releases with semantic versions: v2.4.1.

6. Branching strategies

Three strategies cover most teams. Each is a different answer to one question: how long may work stay off the main line? The shorter the answer, the simpler the process and the easier the merges, but the more you rely on tests and feature flags.

A. GitHub Flow: one main branch, short feature branches

Everything on main is deployable. For each task you branch from main, commit, open a pull request, get review and passing tests, merge, and deploy.

B. Git Flow: structured branches for versioned releases

Introduced by Vincent Driessen in 2010, Git Flow uses long-lived main (only released code, tagged) and develop (the next release being assembled). Short feature/* branches come off develop, release/* branches stabilise a version, and hotfix/* branches patch production directly.

C. Trunk-based development: everyone integrates into one trunk

Developers commit to main (the trunk) at least daily, either directly or through very short-lived branches that last hours. Unfinished features are hidden behind feature flags so incomplete code can be merged and still stay off for users. When a release is needed you tag the trunk, or cut a short release/* branch that receives only bug fixes cherry-picked from the trunk.

Other patterns worth knowing

• Fork and pull request. Contributors copy (fork) the project, work in their copy, and propose changes by pull request. The standard for open source, where you cannot give everyone write access.
• GitLab Flow. GitHub Flow plus environment branches (main → staging → production) or release branches. A middle path when you cannot deploy straight from main.
• Release branches per supported version (release/1.x, release/2.x) with fixes cherry-picked back. This is how the Linux kernel, language runtimes and most libraries keep long-term support.

7. Choosing a strategy for your situation

Start from how your software reaches users, not from what is popular.

Situation by situation

8. Software for Git operations

Git itself is a command-line program that keeps data in a .git folder. Everything else is a layer on top of it. Pick one tool from each layer that you enjoy; they all work on the same repository, so you can mix them.

Clients

Hosting services

Helpers worth adding

• Git LFS stores large files outside normal history and keeps lightweight pointers in Git.
• Hooks run scripts at key moments. Tools like pre-commit or Husky run linters and tests before a commit or push.
• git worktree checks out a second branch in another folder, handy for a hotfix while your feature is half done.
• SSH keys or a credential manager (Git Credential Manager) so you do not type passwords. Sign commits with an SSH or GPG key if your team requires it.
• Diff and merge tools such as delta, Meld, Beyond Compare or the IDE’s three-way merge make conflicts less scary.
• CI services (GitHub Actions, GitLab CI, Jenkins, CircleCI) run your tests on every push, which every branching strategy above depends on.

9. Habits that work with any strategy

• Keep branches short-lived. Merge within days. The cost of merging grows faster than the age of the branch.
• Make small pull requests that do one thing. They get reviewed faster and are easier to revert.
• Pull or rebase often from main so conflicts show up while they are small.
• Automate checks: build, tests, lint and security scan on every PR. A branching strategy without CI is only a convention.
• Commit often, publish clean. Commit as you go locally, then tidy with an interactive rebase or squash before sharing.
• Never force-push a shared branch. If you must, use --force-with-lease on your own branch only.
• Back up by pushing. Unpushed local commits exist on one disk only.
• Keep secrets and large generated files out of the repository.

10. Common mistakes

• Long-lived feature branches. Weeks of drift lead to a “merge hell” day. Merge in slices, use flags.
• Choosing Git Flow because it looks professional. If you deploy continuously, it adds work for no gain.
• Committing everything with git add . without checking git status, and catching build files or secrets.
• Vague commit messages (“fix”, “update”, “wip”) that make history useless for finding bugs.
• Rebasing or resetting shared history, which breaks teammates’ clones.
• Environment branches with different code, so what you tested is not what you ship.
• Forgetting to merge a hotfix back, so the bug returns in the next release.
• Putting big binaries in plain Git, bloating every clone forever.
• Resolving conflicts without understanding them. Read both sides, run the tests, and ask the author if unsure.

11. Takeaways and glossary

• Version control is the safety net and the collaboration tool of every software project.
• Git is distributed and snapshot-based: three local areas plus a remote, with branches as cheap labels.
• Alternatives win in special cases: huge binaries (Perforce, Unity Version Control), tiny self-hosted projects (Fossil), nicer ergonomics on Git (Jujutsu).
• Pick a branching strategy by how you release: GitHub Flow or trunk-based for continuous delivery, Git Flow or release branches for versioned software, fork and PR for open source.
• Short branches, small PRs, protected main and automated tests matter more than the name of the strategy.
• Learn the command line, then use GUIs and IDE tools for convenience.

Links and further reading

• Git quicksheet (companion one-page reference)
• Pro Git (free book) · Git reference · Learn Git Branching (interactive)
• GitHub Flow · A successful Git branching model (Git Flow) · trunkbaseddevelopment.com
• GitLab Flow · Semantic Versioning · Conventional Commits
• Subversion · Perforce Helix Core · Mercurial · Fossil · Jujutsu · Sapling · Pijul
• GitHub Desktop · Fork · GitKraken · Tower · lazygit · GitHub CLI · Git LFS