Git

What Does Git Mean?

Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005. It changed how software teams collaborate and manage code changes.

Centralized version control systems rely on a single server. Git is different. Every developer has a complete copy of the project history on their own machine.

Core Git Concepts

Version Control Fundamentals

Version control systems track changes to files over time. They help teams:

• See who changed what: track each change with its author and time.
• Understand why: read the reasoning behind each change.
• Revert safely: roll back to an earlier version if problems appear.
• Work in parallel: build different features at once without interference.
• Combine work: merge contributions from many developers.

Distributed Architecture

• Full local history: every developer has the whole repository history.
• Offline work: commits, diffs, and logs work without a network.
• No single point of failure: losing one server does not lose the codebase.
• Flexible workflows: teams can use centralized, feature branch, or forking models.
• Multiple remotes: repositories can sync across several remote locations.

Branching and Merging

Git's lightweight branching model lets developers:

• Isolate work: create separate branches for new features or experiments.
• Avoid conflicts: work on several changes at once.
• Test ideas safely: try changes without affecting the main codebase.
• Merge when ready: bring finished work back into main branches.
• Clean up: delete branches after features merge.

Commit History

Every change in Git is saved as a commit. Each commit includes:

• Changes: the specific edits made to files.
• Author and time: who made the change and when.
• Message: a short explanation of the change.
• SHA hash: a unique ID for referencing the commit.
• Parent links: references that build a full history graph.

Collaboration Features

• Pull requests: review code before it merges.
• Conflict resolution: tools for handling overlapping changes.
• Remote hosting: shared repositories on GitHub, GitLab, or Bitbucket.
• Tags: mark release versions.
• Blame: show who last changed each line.

Git vs. Centralized Version Control

Git in Modern Development Workflows

Git is now the standard for version control across the software industry. Teams use it for application code and also for:

• Infrastructure as code: cloud and cluster definitions.
• Configuration: settings and config files.
• Documentation: technical writing and guides.
• Design assets: creative and design files.
• Data science: notebooks and machine learning models.

GitOps and Declarative Operations

In cloud-native environments, Git plays an even bigger role. GitOps treats Git repositories as the single source of truth for:

• Kubernetes manifests: resource definitions for workloads.
• Helm charts: configuration templates.
• Pipelines: CI/CD pipeline definitions.
• Environment settings: per-environment configuration.
• Policies: compliance and policy rules.

The desired state lives in Git. Automated systems then keep the real state in sync with what the repository declares.

Why Git Matters

Git is fundamental to modern software delivery. Its value goes well beyond tracking versions.

1. Enabling Collaboration

• Parallel development: developers work on different features without blocking each other.
• Conflict management: Git helps find and resolve overlapping changes.
• Code review: pull and merge requests enable review before integration.
• Distributed teams: developers in different time zones contribute on their own schedules.
• Open source: forks let outside contributors propose changes without direct access.

2. Providing Traceability

• Attribution: every commit records who changed what and when.
• Intent: commit messages explain the reasoning.
• Bug hunting: tools like git bisect find when a bug was introduced.
• Compliance: audit trails show what changed for regulators.
• Ownership: blame shows who to ask about a code section.

3. Powering Automation Pipelines

• Automated testing: commits and pull requests trigger test suites.
• Continuous deployment: merges to key branches start deployments.
• Preview environments: pull requests can spin up temporary test environments.
• Release automation: tags trigger builds and releases.
• Notifications: webhooks alert teams about code changes.

4. Ensuring Configuration Consistency

• Declarative definitions: desired infrastructure state is written down in versioned files.
• Drift detection: automation flags when real state differs from Git.
• Rollbacks: reverting a commit restores a known-good configuration.
• Environment parity: dev, staging, and production configs are versioned together.
• Change approval: infrastructure changes go through code review.

Git's Role in Testing Workflows

• Versioned test assets: test scripts, data, fixtures, and configs are versioned with app code, so results map to code versions.
• Tests evolve with code: feature branches carry their own test changes, and reviews cover both code and tests.
• Reproducible runs: anyone can check out a version and rerun the exact tests that failed.
• Audit and compliance: test runs link to commits, and coverage changes are visible and reviewable.

Tying testing to Git keeps quality practices in step with development speed.

A B2B SaaS Example

Picture a compliance software company preparing for a SOC 2 audit. The auditor asks which tests ran against the release that shipped in March.

Because tests live in the same repository as the app, the team checks out the release tag. They show the exact test code, the reviewers who approved it, and the results. The audit request takes minutes instead of days.

Our Perspective: Tests Belong in the Same Pull Request

When tests live in a separate repo or a test tool's UI, they drift from the code they check. Teams then debug tests that are simply out of date.

Keeping test changes in the same pull request as the feature keeps both honest. Reviewers see what changed and how it is verified, side by side.

Git Integration in Testkube

Testkube integrates with Git to streamline continuous testing:

• Tests from Git: Test Workflows can clone test code from a Git repository at the start of each run, so updates apply automatically.
• GitOps-friendly: Test Workflows are Kubernetes resources that can live in Git and sync through Argo CD or Flux.
• Branch and commit control: run tests from a specific branch, tag, or commit to match the code under test.
• Private repositories: authenticate with tokens or SSH keys stored in Kubernetes Secrets.

Example: Running Tests from a Git Repository

This Test Workflow clones a folder of Postman tests from the main branch and runs the collection with Newman:

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: postman-from-git
  namespace: testkube
spec:
  content:
    git:
      uri: https://github.com/kubeshop/testkube
      revision: main
      paths:
      - test/postman/executor-tests
  container:
    workingDir: /data/repo/test/postman/executor-tests
  steps:
  - name: Run Postman collection
    run:
      image: postman/newman:6-alpine
      args: [run, postman-executor-smoke.postman_collection.json]

Understanding the Configuration

• content.git.uri: the repository that holds your tests. It can be public or private, cloud-hosted or self-hosted.
• revision: the branch, tag, or commit to use. Use main for stable tests or a feature branch for new work.
• paths: the folders to fetch. This keeps clones small and supports monorepos.
• workingDir: where the step runs inside the pod after the repository is cloned.

Benefits of Git-Based Test Management

• Single source of truth: tests live next to the code they check and change in the same commits.
• Peer review: test changes go through the same review as app changes.
• Easy rollback: reverting a commit restores working test definitions.
• Branch-based testing: feature branches can add tests without touching stable suites.
• Audit trail: commit history shows who changed tests, when, and why.

Frequently Asked Questions (FAQs)