Git

Git is a distributed version control system (VCS) that Linus Torvalds wrote in 2005 for Linux kernel development. Unlike centralized systems such as SVN, every developer has a full copy of the entire project history locally — offline work, merges without a server, and recoverable versions are therefore core properties, not add-ons. The core concepts: A repository (repo) is the project with its full history. A commit is a saved change with author, timestamp, diff, and parent pointer — the smallest atomic unit. Branches are pointers to commits that exist in parallel (feature/login, bugfix/hotfix-X, main). Merge and rebase combine branches, where merge creates a "merge commit" and rebase linearizes history. Remotes (origin, fork) are other copies of the repo, typically hosted on GitHub, GitLab, Bitbucket, or Azure DevOps. The standard team workflow: create a feature branch from main → local commits → push to remote → pull request (PR) / merge request → code review by the team → merge to main → CI pipeline auto-deploys. Variants are Git Flow (explicit develop/release/hotfix branches, classic for release cycles), trunk-based development (short-lived feature branches, continuous deployment), and GitHub Flow (minimal, ideal for web apps). Git skills are now basic equipment for any professional software development team. For non-technical team members (design, content), graphical clients like GitHub Desktop, Sourcetree, Fork, or Tower are the easiest entry point. The most common pitfalls: forgotten .gitignore (secrets in the repo), force-push on shared branches (overwriting colleagues' work), huge commits without context. Discipline pays off: clean atomic commits with meaningful messages are the foundation for debugging, code review, and audits.