Git™ is a system that you can use to track and manage changes to files (a version control system).
But unlike other CVS such as Subversion, Perforce, Bazaar and so on, Git stores and thinks about information in a very different way.
While most other systems store information as a list of file-based changes using a process commonly described as delta-based version control, Git thinks of its data more like a series of snapshots of a miniature filesystem.
Git thinks about its data more like a stream of snapshots.
Every time you commit or save the state of a project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
Since there is much you can do with Git, it uses many terms that first-time users may not immediately understand.
We have listed some that you may need to get started below:
Archives store the contents of the current working tree (but not the
.git directory or uncommitted changes) in a
You may wish to create an archive if, for example, you wish to provide a source download file.
Each branch in a repository represents a separate line of development, and all branches retain their own project history, working directory, and staging area.
- Each repository can contain as many branches as you wish to create.
- You can only work in one branch (the checked-out branch) at any given time.
- Generally, branches diverge from the original line of development with the intent to merge the branch’s changes at a later time.
Git uses this term in two contexts:
- When you check out a branch or commit via the
git checkoutcommand, Git points
HEADto the specified branch or commit. This allows you to switch between multiple branches from the command line.
- When you check out files via the
git checkoutcommand, Git copies the version of that file from the specified commit or from the index. This allows you to revert committed or uncommitted changes.
When you cherry-pick changes via the
git cherry-pick command, Git applies the specified changes from a commit and branch to a different branch’s
When you clone a repository via the
git clone command, Git performs the following actions:
- Git creates a new repository (the local repository) in the directory in which you ran the command.
When you clone a repository in cPanel's Git Version Control interface (cPanel >> Home >> Files >> Git Version Control), the system creates the repository in the Repository Path directory that you specify.
- Git sets the repository that you wish to clone (the remote repository) as the
- Git fetches all of the commits and branches from the remote repository.
- Git checks out the default branch (generally, the
Effectively, this copies the remote repository. You can then make changes to the local repository and push them to the remote repository.
Commits represent a point in Git’s history. Git’s entire history for a repository exists as a timeline of individual commits.
When you commit changes, you create a new point in the history that represents the current state of the index.
HEAD then points to the new commit.
Commit objects represent your committed revisions to a branch.
Each commit object contains the commit’s files (the tree object), parent commits, commit metadata (for example, the author and date), and an SHA-1 value that identifies the object.
Deployment sends finished code into production. You can use different configurations to automatically (push deployment) or manually (pull deployment) deploy changes.
- For example, you can configure cPanel’s Git Version Control interface (cPanel >> Home >> Files >> Git Version Control) to automatically deploy changes that a cPanel-managed repository receives to the directory for your website.
When you fetch changes via the
git fetch command, Git automatically downloads new changes from the remote repository.
However, it does not integrate (merge) these changes into the working tree for any local branch.
When you fork a repository, you create a new server-side copy of that repository.
You can then experiment with changes to that repository without any impact on the original repository.
HEAD value represents the SHA-1 identifier for the most-recent commit or active branch.
Whenever you commit changes to the active branch, Git automatically updates
HEAD to that commit’s SHA-1 identifier.
If you use the
git checkout command to check out a specific commit instead of a branch, Git enters the
detached HEAD state.
Heads are the SHA-1 identifiers for the most-recent commits to each branch.
While only one HEAD commit exists, a repository generally contains many heads for each branch.
Hooks are scripts or other code that you can configure to trigger before or after specific Git actions.
You can store these hooks in the hooks directory within the repository directory.