- Basic Elements

From a user’s perspective, working with consists of interacting with 6 basic elements:

Commits

A commit represents a single step in the history of a repository.

A commit:

• is the result of an action initiated by a developer,

• contains changes the developer decided to add,

¹While it is technically correct to consider commits as snapshots, it might be more practical to think about commits as changes.

• can be seen as a snapshot of the entire repository including a reference to the parent commits’, ^{1 1}While it is technically correct to consider commits as snapshots, it might be more practical to think about commits as changes.

• can be used to document introduced changes.

Branches

A branch is a way to create and maintain different versions of a repository.

A branch:

• offers the possibility to develop and test new features,

• allows to maintain various versions of a repository,

• is updated automatically with new commits being added.

branches are dynamic pointers

A branch only points to a specific commit. It doesn’t contain any data or changes but serves as a reference to a particular commit in the repository’s history.

The value of a branch lies in how many operations in update the location of this pointer. For example, when you make a new commit, updates the branch pointer to point to this new commit, allowing you to create new lines of development, experiment with changes, and manage different versions of your project without impacting the main codebase.

Tags

A tag is a mark for a specific state of a repository.

A tag:

• allows to flag a particular version of the repository,

• can be used to document states.

Tags provide a more human-readable way to refer to commits. For example, instead of using the commit hash c1e2d3f4, you can use a tag like 1.0, which is easier to remember. Tags can also be annotated with a message, the tagger’s name, and the date, making them useful for documenting the reason for the tag or who created it. In a scientific context, tags can mark specific states of a repository that correspond to particular analyses or publications.

HEAD

In ²HEAD is actually a variable, and therefore defines the checked out branch.HEAD corresponds ^{2 2}HEAD is actually a variable, and therefore defines the checked out branch. to the currently checked out branch.

HEAD allows to:

• simplify most commands as it serves as default branch,

³HEAD~2 would refer to the commit two steps before the one the current branch points to.

• can be used to conveniently refer to previous commits, e.g. HEAD~2. ^{3 3}HEAD~2 would refer to the commit two steps before the one the current branch points to.

Index/Staging Area

In the Staging Area or Index refers to a set of modified files that are flagged to be included in a commit.

The Staging Area (or Index):

• allows to manage the content of a new commit,

• can be used to temporarily store away uncommitted changes,

• highlights the changes to be introduced by a new commit.

Working Directory

In , the Working Directory refers to the local folder where you view and edit files from the currently checked-out branch.

The Working Directory acts like a “sandbox” where you can craft changes:

• When switching the current branch will change its content.

• Changes introduced by the developer will not be overwritten by .

In most cases the Working Directory can be recognized by the presence of a (hidden) .git folder. If no such folder can be found, you can run git rev-parse --git-dir to display its location.

When you switch branches, the working directory content will change to reflect the content of the branch you are switching to. The changes you make in the working directory will not be overwritten by unless you explicitly tell to do so.

History

In , the History is the sequence of commits in a repository.

• A record of changes made by various developers over time.

• Enables navigation and inspection of changes.

• Essential for understanding, troubleshooting, and reverting changes. Clear and informative commit messages are crucial.

In the History refers to the sequence of commits made in a repository. This sequence represents a comprehensive record of changes over time, introduced by various developers. Each commit captures a snapshot of the project at a specific point, detailing modifications and additions.

Key aspects of the history include:

• Navigation: Allows developers to explore different stages of the project, understanding its evolution.

• Inspection: Facilitates the examination of specific changes, helping to identify the reasons behind them.

• Troubleshooting: Aids in diagnosing issues by reviewing past changes and their impacts.

• Reverting: Enables the rollback of changes if necessary, ensuring stability and continuity.

A well-maintained history with clear and informative commit messages is invaluable. It not only aids in current development but also serves as a crucial resource for future developers and collaborators, ensuring the project’s long-term success.

---