Git, AI teams & CI/CD

1. A shared memory

Git stores versioned snapshots locally. A commit connects such a state with its history and a description of the change. GitHub and GitLab add collaboration: issues, reviews and automation. Git is the version control system; GitHub and GitLab are platforms built around it.

A repository contains approved project context and traceable source code. Keep passwords, access keys (secrets) and production data outside it. A private repository is not a suitable password store either.

2. One change, one understandable step

Before starting, inspect the local state with git status and update information from the remote repository with git fetch. Fetch does not yet integrate those changes into your working branch. Create a short-lived task branch from the agreed starting version.

Small, understandable commits connect intent and change. Inspect the diff before each commit. Select files deliberately with git add and check the changes actually staged with git diff --staged. A meaningful commit message explains the purpose. Related changes and the appropriate tests form one traceable step.

3. People and AI agents in parallel

Every task needs clear ownership and a verifiable result. git worktree add creates additional working directories, usually on different branches. Each has its own checked-out working state; the worktrees share important repository data and references. They are not completely independent clones.

Separate directories do not prevent conceptual conflicts. Continue to coordinate interfaces and file ownership; do not blindly revert changes made by other people or agents. Give AI agents only the access they need. Keep secrets outside the repository and out of prompts, test output and logs.

4. Review before integration

Push the branch and open a pull request on GitHub or a merge request on GitLab. Both terms here describe a proposal to have a change reviewed and integrated into the target branch. Describe the problem, resulting behaviour and validation performed so that another person can assess the change.

Protect the main branch using the controls available on the platform and its feature tier: restrict direct changes and configure required reviews and successful checks. A green pipeline does not replace a technical review. After further commits, check again that approvals and test results still apply to the current state.

5. CI as a verifiable process

Continuous Integration (CI) checks changes automatically. GitHub Actions uses workflow files under .github/workflows; GitLab CI/CD normally uses a .gitlab-ci.yml. A pipeline comprises individual jobs that might check syntax, behaviour and security boundaries or build a deliverable.

Pinned dependency versions and traceable build artifacts make processes more reproducible. Logs and test reports must correspond to the commit being checked. A successful build and a successful deployment are separate pieces of evidence. CD can mean Continuous Delivery, where authorising production deployment remains a separate step, or Continuous Deployment, with automated deployment to production.

6. Containers and delivery

Build container images in CI and push them to a private container registry. For a particular deployment, pull the verified image using its cryptographic content identifier, or digest. A mutable tag alone does not identify an immutable image version.

Store live data and secrets in protected persistent directories or suitable secret management. Grant access to the registry and target system separately, with the permissions each requires. After starting the application, verify the application, proxy, TLS, login and persistence. Keep the previous image version and a verified backup available for rollback. An older image alone does not reverse incompatible database changes.

7. Conflicts and recovery

Read git status and the affected diff before resolving a conflict. Understand the intended effect of both changes, resolve conflict markers deliberately and test the combined behaviour. A syntactically successful merge does not establish functional correctness.

In shared history, git revert can undo a change visibly through a new commit. Reverting a merge commit also requires selecting the appropriate mainline parent. git reflog helps locate earlier local reference states; it is not a substitute for a backup. git reset --hard and a force push can remove work or rewrite shared history: preserve the state, agree ownership and understand the effects first.

Practice

Create a separate practice repository with a remote on GitHub or GitLab and a task branch. Do not put production data or access keys in the practice files.
Make a small change and a meaningful test. Inspect the diff and staged changes, run the tests and commit.
Make an independent change in a second worktree on another branch. Agree ownership beforehand.
Open a pull request or merge request and integrate it after successful CI and review. Check that the results correspond to the integrated state.
Undo the integrated change with git revert and verify the result again. If reverting a merge commit, first read about the meaning of the mainline parent.

In this learning path, we bring together our material on collaboration with Git, GitHub and GitLab in an edited web adaptation. Try commands only in a practice repository.

Terminology: English and German

Repository — versionierter Projektbestand: a versioned project with its history; a local repository can be used without a hosting platform.
Commit / Snapshot — Versionsstand / Schnappschuss: a recorded version with its history / a snapshot of the versioned files.
Branch — Entwicklungszweig: technically a movable reference to a commit.
Staging Area / Index — Vormerkbereich: the selected state for the next commit.
Diff — Unterschied: the displayed difference between two states.
Fetch / Push — vom Remote holen / an ein Remote übertragen: retrieve information and objects from a remote / transfer local reference states to a remote.
Pull Request / Merge Request — Integrationsvorschlag: a reviewable proposal to integrate a change on GitHub / GitLab.
Worktree — zusätzliches Arbeitsverzeichnis: an additional working directory of the same repository with its own checked-out state.
Pipeline / Job — automatisierter Ablauf / einzelne Aufgabe: an automated process / an individual task within it.
Artifact — aufbewahrtes Ergebnis: an output retained from a job, such as a test report or a build package.
Container Registry / Digest — Image-Ablage / Inhaltsbezeichner: storage for container images / a cryptographic content identifier for an image or manifest.
Deployment / Rollback — Bereitstellung / Rückkehr: making a version available / returning to an earlier operational state.
Revert / Reflog — rückgängig machen / Referenzprotokoll: undo changes through a new commit / a local record of earlier reference states.

Sources

The official documentation provides the original English terminology and precise syntax. This learning path summarises the relationships that matter for collaboration.