GIT
INTRODUCTION
Version Control
Version Control is a system that allows you to revisit various versions of a file or set of files by recording changes. Through version control, one can revert a file or project to a previous version, track modifications and modifying individuals, and compare changes. By utilizing a Version Control System (VCS), mistakes with files can easily be rectified.
Local Version Control
Many years ago, programmers created Local Version Control systems. A Local VCS entails one database on your hard disk that stores changes to files.
Centralized Version Control
The need for collaboration within a developer team on a single file or set of files led to the advent of the Centralized Version Control System (CVCS). This system entails a single server storing all changes and file versions, which can be accessed by various clients. This streamlined the collaboration process (by eliminating the need to involve all local databases), allowed programmers to have more knowledge of team members’ activities with certain files, and gave administrators much more control over divvying up revision privileges.
Distributed Version Control
A Distributed Version Control systems (DVCS) addresses the major vulnerability of the CVS: the server as a single point of failure. If a CVS goes down, collaborators cannot work with each other on a file or save changes and new versions. Also, in the event of corruption of a central database’s hard disk — with the absence of backups — all work will be lost, except for any portions on local machines.
To prevent this type of catastrophic loss, a DVCS allows clients to create mirrored repositories. These data backups can be easily be placed on the server to replace any lost information.
Because the DVCS allows for multiple mirrored repositories, programmers working in teams can collaborate with each other in various ways to complete a joint project, which enables the use of various simultaneous workflows.
So, what is Git?
** Git is a DVCS that stores data in a file system made up of snapshots. ** Each time you save a changed version of your project — called commit — Git creates a snapshot of the file and stores a reference to it. If the file has not changed, Git only stores a reference to the already-stored identical version of it.
Local Operations
Git mostly relies on local operations because most necessary information can be found in local resources. This allows for process expediency because a project’s history resides on the local disk, eliminating the need to fetch history information from the server, and allowing one to continue work on a project even when not online or on a VPN.
Tracking Changes
Every single change applied to any file or directory is tracked by Git. And, as the gatekeeper, Git will always detect file corruption or loss of information in transit.
Loss of Data
Git is set up to greatly minimize the possibility of irreversible damage to files, such as accidentally lost data. Git makes it extremely difficult for a snapshot of your file that is committed to be lost.
States
Files in Git can reside in three main states: committed, modified and staged.
** Committed **
Data is securely stored in a local database
** Modified **
File has been changed but not committed to the database
** Staged **
Flagged a file’s changed version to be committed in the next snapshot
Getting Help
There are three ways to get more information on a particular command, by accessing the manual:
git help command
git command –help
man git-command
Setting up a Git Repository
Importing To import an existing project or directory into Git, follow these steps using the Terminal or Command Line:
Switch to the target project’s directory Example:
$ cd test (cd = change directory) Use the git init command $ git init Note: At this stage, you have created a new subdirectory named .git that has the repository files. Tracking has not commenced.
To start tracking these repository files, perform an initial commit by typing the following: $ git add *.c $ git add LICENSE $ git commit -m “any message here” Now, your files are tracked and there’s an initial commit. We will discuss the particular commands in detail soon.
Cloning
You can also create a copy of an existing Git repository from a particular server by using the clone command with a repository’s URL:
$ git clone https://github.com/test By cloning the file, you have copied all versions of all files for a project. This command leads to the creation of a directory called “test,” with an initialized .git directory inside it, which has copies of all versions of all files for the specified project. The command also automatically checks out — or retrieves for editing — a copy of the newest version of the project.
To clone a repository into a directory with another name of your choosing, use the following command format:
$ git clone https://github.com/test mydirectory The command above makes a copy of the target repository in a directory named “mydirectory.”
Check File Status To determine the state of files, utilize the git status command:
$ git status On branch master
nothing to commit, working directory clean
*This information indicates which branch you’re on (we will cover branches in a later section) and states “working directory clean,” which means that files have tracked or modified status at the moment. Also, no untracked files are present because Git has not listed any.
Tracking and Staging a New File Single File
Track one file only by using the following format:
git add filename All Files
Track all files in a repository by using the following command:
$ git add * *After using these commands, files are tracked and staged for committing.
After adding a new file called EXAMPLE, you would see information regarding changes to be committed when using the git status command:
$ git status
On branch master
Changes to be committed:
(use “git reset HEAD …” to unstage) new file: EXAMPLE This information tells us that there are changes to be committed and that the file has been staged.
Committing a File After staging one or multiple files, you should commit the changes and record what you did within the commit message:
$ git commit -m “made change x,y,z” *This step has committed changes for the file or files (you can have one commit message for multiple files, if applicable) to the HEAD.
Committing All Changes $ git commit -a *This command commits a snapshot of all modifications to tracked files in the working directory.
Pushing Changes Next, you would push changes to a remote repository. We will discuss remote repositories in more depth in the next section. For now, we will look at a general overview of pushing changes to remotes.
Example:
$ git push origin main *This command pushes changes from the local “main” branch to the remote repository named “origin”.
*For cloned repositories, Git will automatically give the name “origin” to the server from which you cloned and the name “main” to your local repository. However, these names can be changed by the user.