Introduction to Git for Teams

Version control connects stored project states with a traceable history. You compare a centralised model with Git's distributed architecture and examine the relationships between the working tree, repository, commits, and references. Using a prepared history, you inspect which information exists locally and what role a remote repository plays in collaboration.

A Git working environment needs an installation, author identity, editor, and suitable access to the remote service. You configure Git on Windows, macOS, or Linux and compare HTTPS with a credential helper against SSH keys. In the lab, you inspect the configuration and a GitHub connection without placing credentials in the repository.

Git separates the current working tree, the preparatory index and stored commit history. You initialise a repository, change files and select content deliberately for a commit. The DevNinjas Dojo, our cloud learning environment, lets you compare these states and explain which changes are staged and which remain outside the next snapshot.

Status, differences, and history answer distinct questions about a change. You inspect these perspectives with git status, git diff, and git log, then create .gitignore rules for generated files and local editor configuration. The discussion also covers why ignore rules do not remove content already recorded and why secrets should never enter history.

Graphical interfaces present the same Git states from a different perspective than the command line. You inspect commits, diffs, history, and blame information in VS Code with GitLens and compare the view with terminal output. The comparison helps you decide which presentation supports a particular review and where explicit Git commands provide greater clarity.

A Git branch is a movable reference to a line of development, not a copy of the project. You create, switch, and remove branches while observing how HEAD and the working tree represent the selected state. In the lab, you compare independent changes and assess when a short-lived line of development keeps later integration understandable.

Git can combine lines of development through a fast-forward or a merge commit; conflicting changes require a content decision. You create controlled conflicts and inspect the base, both variants, and conflict markers in the terminal and VS Code. In the lab, you resolve the conflict and review which content decision the resulting state represents.

A remote connects the local repository with references and objects stored elsewhere. You clone a repository, retrieve new information with fetch, integrate it deliberately, and publish your own references with push. The lab makes the distinction from pull visible so you can treat retrieval and integration as separate decisions.

Hosting platforms extend Git with tasks, discussions, and governed integration decisions. On GitHub, you create an issue, open a pull request, assign reviewers, and write traceable feedback. In the lab, you compare the technical branch and merge state with the social review layer and derive criteria for a reviewable change description.

Rebase, stash, and tags solve different problems and affect history in different ways. You move commits onto another base, put unfinished changes aside temporarily, and mark a traceable state. Across several scenarios, you decide when rewriting is acceptable, when a merge preserves history more appropriately, and which marker should be shared.

Branching models structure integration, reviews, and releases differently. You compare GitFlow, GitHub Flow, and trunk-based development by branch lifetime, release cadence, automation, and required coordination. For several team scenarios, you assess their boundaries and formulate criteria without presenting any workflow as a universal best practice regardless of context.

Gitea provides repositories and collaboration features as a self-hosted platform. You set up an instance in the lab, publish a repository, and compare access, issue, and review workflows with GitHub. The focus is on criteria for operating responsibility and collaboration; designing or continuously operating a production platform is outside this module.

Contributing to someone else's repository separates your own write access from the target project's integration rights. You work with a fork, configure an upstream remote, and keep lines of development synchronised for a prepared change. In the lab, you draft a pull request and assess which description and commit structure support the review decision.

A shared repository connects branching, pull requests, reviews, and conflict resolution in one coherent scenario. You rotate roles, plan integration points, and respond to parallel changes in the lab. The exercise observes how technical Git states and team agreements interact without prescribing a universal workflow or a finished result.

Advanced tools help transfer individual changes and narrow down the source of faults in history. You try cherry-pick and bisect, classify SHA-256 and reftable as alternative hash and reference formats, and compare Jujutsu (jj) and GitButler with familiar Git workflows. These topics provide a bounded outlook rather than a complete advanced treatment.