These projects have a long lifespan, with numerous releases containing new functionalities and bug fixes.
Throughout this lifespan, the development team needs a way to work in parallel while sharing a common code base.
Manual source code management
Relies on shared places (local or cloud-based) where snapshots of the code base are regularly pushed by developers.
Highly impractical: no individual history of files, no release management, no handling of conflicts (simultaneous updates of a file)…
Version Control Systems
Dedicated source code management tools, often called Version Control Systems, offer developers the ability to:
share and update a common code base;
work on new features and fixes without breaking current versions;
track who did what;
handle conflicts;
and more!
Centralized VCS
Uses only one repository, accessed by developers in a client/server way.
Repo administration (security, backups…) is easy.
Synchronization is impossible in a disconnected scenario.
Examples: CVS, SVN, ClearCase.
Decentralized VCS
Each developer has its own code repository, including history and all other metadata.
Repositories are frequently synchronized in a peer-to-peer way.
Disconnected workflows become possible.
Examples: Git, Mercurial.
Git fundamentals
Git in a nutshell
Free and open source DVCS published in 2005 to manage the Linux kernel source code.
Has become the standard tool for versioning software.
Can handle any text-based project: knowledge bases, books, etc.
Designed as a command line tool.
Git is not (that) hard
The Git repository
Storage place for all versioning data: source code, history, versions, remote addresses…
Corresponds physically to a .git/ subdirectory in the project folder, with a complex internal structure.
The .gitignore file
Some project files don’t need to be versioned:
generation output;
local settings;
…
Added in the root folder, the .gitignore file defines files and folders excluded from the repository.
This repository contains standard .gitignore files for many environments: Python, .NET, JavaScript…
The Git workflow
Update files in project folder, aka working directory.
Add files to index, aka staging area.
Commit indexed files into the current branch, aka HEAD.
Branches
Branches allow parallel work in isolated contexts, for:
new features;
bug fixes;
experimentations;
…
Working with branches
Only one branch can be active at a time.
The content of a branch can be merged into another. Once merged, a temporary branch should be destroyed.
The default branch is named master (sometimes renamed main). In general, it is considered the “production” branch and must be kept stable: commits or merges on this branch must not introduce generation errors or regressions.
HEAD
HEAD is an alias to the most recent commit of the active branch.
Under the hood
Git uses the SHA-1 hash of content to create references to commits.
A commit object stores the metadata about a commit, such as the parent, the author, timestamps and references to the file tree of this commit.