Git Basics: Working together for beginners

Git is a version control system that allows you to track changes in a codebase (repository) and collaborate with others effectively. It supports features like branching, merging, and history tracking, making it easier for teams to work on the same codebase simultaneously.

To get started with Git, you’ll need to understand a few core concepts:

Repositories
Branches
Commits
Pull Requests (PRs)

💡 If you're new to Git, there’s a great Git guide for beginners on Stack Overflow.

Working with Teams in Git

Even if you're familiar with Git, there are a few important practices to understand when working in a team—especially on the same project or feature.

Branching

Learning how to use branches effectively is essential. Branches help organize work into features, fixes, and releases, making it easier to manage development as your project scales.

Branching Model

Typically, development follows a structure like this:

feature/*  →  release/*  →  main
   ↑           ↑
hotfix/*    (merged when ready)

1. Feature Branches

Feature branches represent self-contained units of value. It's best to create a separate branch for each feature:

git checkout -b feat/my-new-feature

2. Release Branches

Releases are collections of features that form a stable version of the product. A release branch is created when a set of features is ready for testing, QA, and final adjustments:

git checkout -b release/v1.2.0

Once all conditions are met (tests pass, QA is approved, pipelines are green), the release is finalized, locked, and merged into main:

git checkout main
git merge release/v1.2.0
git tag v1.2.0

🔗 Atlassian Git workflows offer detailed branching strategies like GitFlow.

Collaborating on a Feature Branch

When multiple developers work on the same feature branch, understanding rebasing and merging becomes essential.

What's the difference between `git rebase` and `git merge`?

Action	Description
`git merge`	Combines two branches while preserving history
`git rebase`	Moves or reapplies your local commits on top of another branch for a linear history

When to Use What?

If others have made changes to the same branch:

git fetch origin
git rebase origin/feat/my-feature

After rebasing, push your changes:
```
git push --force-with-lease
```

Rebase rewrites history to create a cleaner, linear commit history. Only use it on local or shared feature branches that everyone agrees to rebase.

Merging Feature Branches into Release Branches

You have two key options when merging a feature into a release branch:

`--no-ff` vs `--squash`

Option	Description
`--no-ff`	Keeps all individual commits; history is preserved
`--squash`	Combines all commits into a single commit

Example: Merge with `--no-ff`

git checkout release/v1.2.0
git merge --no-ff feat/my-feature

This method preserves all commits and commit messages. It’s helpful for:

Tracking who did what
Reverting specific changes
Using git blame effectively

Example: Merge with `--squash`

git checkout release/v1.2.0
git merge --squash feat/my-feature

This results in a single commit, which is cleaner but loses individual commit history. It’s harder to revert only part of the change.

✅ Recommendation: Use --no-ff by default to preserve context and make collaboration smoother.

Final Thoughts

Mastering these Git techniques—branching, rebasing, and merge strategies—will make working in teams far more effective.

🔍 There’s more to explore, like git bisect, a powerful tool for debugging regressions. We’ll cover that in a future post.