Git

Why you should use Git

Source: https://dev.to/hamitseyrek/8-what-is-git-why-should-i-use-it-what-is-github-gitlab-bitbucket-used-for-5hdm

The fundamental problem

You’re debugging something. You change a few things. Now the original bug is still there AND something else broke. You want to go back to 20 minutes ago, but you can’t — because there’s no record of what “20 minutes ago” looked like.

Without version control, people resort to project_final, project_final_v2, project_final_ACTUALLY_FINAL folder copies. It’s absurd, unreliable, and doesn’t scale to teams at all.

Git tracks every change to every file, so any previous state is recoverable instantly. That alone justifies its existence.

Why Git specifically?

About 43% of professional developers use Git, making it the dominant version control system by a wide margin. Alternatives exist — Mercurial, SVN, CVS — but they have much smaller communities, fewer integrations, and less tooling support. At this point, Git is the industry default.

Git is also distributed — every developer has a complete copy of the entire repository history. SVN and CVS are centralized (one server holds the truth, clients hold only working copies). Distributed means no single point of failure and offline work is fully supported.

Team collaboration

Without version control, team collaboration on code is essentially impossible at scale. Git provides:

• Attribution — every change records who made it, when, and why (via commit message)
• Reversibility — any change can be undone without affecting other changes
• Visibility — team members see each other’s work through the shared repository
• Merging — when two people edit the same file, Git can usually merge both changes automatically. When it can’t, it shows you exactly where the conflict is
• Synchronization — git pull brings everyone else’s changes into your local copy with one command

Branching

Branching lets you work in isolation. You create a branch, make changes, experiment freely — and none of it touches the main codebase until you explicitly merge it. If the experiment fails, delete the branch. Zero cost.

Why this matters:

• You can try risky refactors without fear. Doesn’t work? Delete the branch. The main code is untouched.
• Multiple features can be developed in parallel on separate branches without interfering
• Removing or reworking a module is safe because you’re not directly modifying what everyone else depends on
• New developers can experiment without risk. Mistakes cost nothing because everything is reversible.

Commit best practices

A commit is a snapshot with a message explaining what changed and why. Good commit hygiene matters:

One commit = one logical change. Don’t mix a bug fix, a refactor, and a new feature in one commit. If you need to revert the bug fix later, you’ll lose the refactor and feature too.

Write meaningful messages. “fix stuff” tells your teammates nothing. “Fix null pointer in payment callback when user has no saved card” tells them everything. The first line should summarize the change in under 50-72 characters. A longer body can explain the reasoning if needed.

Git tracks everything. Even a single changed space character shows up in the diff. This precision is a feature — it makes code review meaningful and debugging possible via git bisect.

Online platforms

Git itself is a command-line tool that works locally. These platforms add collaboration on top:

All three support: pull/merge requests for code review, issue tracking, access control (public/private repos), and webhooks for automation.

Relationship to other practices

Version control isn’t just “nice to have” — it’s a prerequisite for everything else in modern development:

• CI/CD — pipelines trigger on git pushes. No git, no CI.
• DevOps — automation, traceability, and collaboration all depend on version control
• Agile — parallel work in sprints requires branching and merging
• Code review — pull requests are a git feature (via platforms)
• Microservices — independent repos or monorepos both require git for team coordination

Git encourages modular thinking. When your team splits a project into modules (authentication, UI, payments, API), each can be developed on separate branches by different people and merged cleanly. Without version control, parallel development is chaos.

Data loss prevention

What developers fear most: losing work. Hard drive failures, corrupted files, ransomware — all real threats. Git’s distributed nature means every developer has a full copy of the repository, including all history. If the server dies, any team member’s local copy can restore the entire project.

Even companies that can’t use cloud services for security reasons benefit from Git running locally. If the internal server has issues, developers still have their complete local copies and can continue working independently until the server recovers.

How to use Git

For learning all the concepts and become proficient, check these resources:

• https://learngitbranching.js.org/?locale=en_US
• https://gitimmersion.com/index.html

Git Workflows

A Git workflow encourages effective collaboration, makes software development process more efficient, and facilitates continuous delivery. By choosing a singular Git workflow, teams can pave the way for smoother conflict resolution and a more coherent code base.

Centralized

A centralized Git workflow enables all team members to make changes directly to the main branch, with every change logged in a running history. This works well for small teams (or beginners), because team members can communicate easily in order to avoid contributing to the same piece of code simultaneously.

Limitations: If multiple developers commit to the same branch, it’s challenging to find a stable moment to release changes. Consequently, developers must keep unstable changes local until they’re ready for release.

Feature Branching

Rather than commit directly to the main branch, developers create a branch for each feature, make changes, submit a merge request (or pull request), and then merge it into main. This has the benefit of keeping a clean main branch without unfinished features.

Teams of any size can use this feature branching, because it permits multiple developers to work on the same feature simultaneously.

GitFlow

This workflow doesn’t add any new concepts beyond the Feature Branch Workflow, while it assigns specific roles to different branches and defines how and when they should interact. Here you would use a develop branch with feature branches.

The main branch should always be releasable to production, and there should never be untested / incomplete code on it. When the develop branch is ready to go to production, a contributor creates a release branch where testing and bug fixing occur before being merged back to the develop branch.

The release branch makes the code review process easier, because there’s a dedicated place to resolve conflicts when merging into the main branch. With this strategy, the main branch always reflects production.

Trunk-Based Development

Trunk-based development facilitates concurrent development on a single branch called trunk. Developers work directly on trunk or on short-lived branches, and when they are ready to release, they use release branches.

Trunk-based development decreases the likelihood of merge conflicts and keeps code clean, because there are many frequent, small merges made each day.

Personal Branching

Personal branching is similar to feature branching, but rather than have a single branch per feature, it’s per developer. This approach works well if team members work on different features and bugs.

Every user can merge back to the main branch whenever their work is done.

Advantages:

• Similar benefits as feature branching
• Fewer branches, so branch management is easier
• Can be used for bug fixes and small changes
• Help developers innovate and experiment
• Useful for long-running features that may not fit into a single release cycle

This strategy can work well for small teams in which every team member develops their own part of the application.

Forking

A forking approach to version control starts with a complete copy of the repository. Forking effectively creates a local copy of a Git repository and provides the ability to create a new collaboration structure.

This workflow is popular for projects that have multiple developers contributing to it, particularly open source projects. After all, keeping track and providing privileges to collaborate to a repository with thousands of contributors is difficult to maintain.

If a maintainer enables contributors to try their changes on their forked copy, managing change proposals is easier and safer.

Benefits:

• Contributors can push changes to a server-side repository
• Decreases likelihood of including low-quality code and bugs
• Only project maintainers can integrate changes to the source code
• Enables secure, quality-driven development for large teams

Images sources: Toptal – Trunk Based Development vs Git Flow

Conventions

Branch naming conventions

Source: https://conventional-branch.github.io/

Conventional Branch refers to a structured and standardized naming convention for Git branches which aims to make branch more readable and actionable

Key Points

1. Purpose-driven Branch Names: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
2. Integration with CI/CD: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type (e.g., auto-deployment from release branches).
3. Team Collaboration: It encourages collaboration within teams by making branch purpose explicit, reducing misunderstandings, and making it easier for team members to switch between tasks without confusion.

Prefixes

The branch specification supports the following prefixes and should be structured as:

<type>/<description>

• main: The main development branch (e.g., main, master, or develop)
• feature/ (or feat/): For new features (e.g., eature/add-login-page, feat/add-login-page)
• bugfix/ (or fix/): For bug fixes (e.g., bugfix/fix-header-bug, fix/header-bug)
• hotfix/: For urgent fixes (e.g., hotfix/security-patch)
• release/: For branches preparing a release (e.g., release/v1.2.0)
• chore/: For non-code tasks like dependency, docs updates (e.g., chore/update-dependencies)

Rules

1. Use Lowercase Alphanumerics, Hyphens, and Dots: Always use lowercase letters (a-z), numbers (0-9), and hyphens (-) to separate words. Avoid special characters, underscores, or spaces. For release branches, dots (.) may be used in the description to represent version numbers (e.g., release/v1.2.0).
2. No Consecutive, Leading, or Trailing Hyphens or Dots: Ensure that hyphens and dots do not appear consecutively (e.g., feature/new—login, release/v1.-2.0), nor at the start or end of the description (e.g., feature/-new-login, release/v1.2.0.).
3. Keep It Clear and Concise: The branch name should be descriptive yet concise, clearly indicating the purpose of the work.
4. Include Ticket Numbers: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket issue-123, the branch name could be feature/issue-123-new-login.

Examples

Commit messages conventions

Source: https://www.conventionalcommits.org/en/v1.0.0/

The Conventional Commits specification is a lightweight convention that provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

• fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
• feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
• BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
• types other than fix: and feat: are allowed, for example build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
• footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.

Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.

Examples

• Commit message with description and breaking change footer

  feat: allow provided config object to extend other configs
  BREAKING CHANGE: `extends` key in config file is now used for extending other config files

• Commit message with ! to draw attention to breaking change

  feat!: send an email to the customer when a product is shipped

• Commit message with scope and ! to draw attention to breaking change

  feat(api)!: send an email to the customer when a product is shipped

• Commit message with both ! and BREAKING CHANGE footer

  feat!: drop support for Node 6
  BREAKING CHANGE: use JavaScript features not available in Node 6.

• Commit message with no body

  docs: correct spelling of CHANGELOG

• Commit message with scope

  feat(lang): add Polish language

• Commit message with multi-paragraph body and multiple footers

  fix: prevent racing of requests
  
  Introduce a request id and a reference to latest request. Dismiss
  incoming responses other than from latest request.
  
  Remove timeouts which were used to mitigate the racing issue but are
  obsolete now.
  
  Reviewed-by: Z
  Refs: #123