What is a Git Repository, if needed to explained in one line it is a version control system that orks in similar fashion to other version control systems, manage a project, or a set of files, as they change over time.
Git however explains itself in various self-explaining terms like everything is local, distributed is the new centralized, local branching on the cheap.
But here we missed a lot, actually a lot.
In this article, we will try to understand what Git Repository actually is, it’s birth and history, why it came into picture and some of its main features in brief.
In the first paragraph of this article, a term has been used version control. What is that? Let’s understand this first then.
1. Version Control
1.1 What is Version Control
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.
And if you screw things up or lose files, you can generally recover easily.
1.2 Types of Version Control Systems
1.2.1 Local Version Control Systems
Local Version Control System is a simple database that keep all the changes to files under revision control
1.2.2 Centralized Version Control Systems
Centralized Version Control Systems have a single server that contains all the versioned files, and a number of clients that check out files from that central place. Systems such as VSS, CVS, Subversion, and Perforce are examples of the same.
Its downside is single point of failure. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything.
1.2.3 Distributed Version Control Systems
Distributed Version Control Systems (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it.
2. Birth of Git
The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked.
This prompted the Linux development community to develop their own that gave birth to GIT in 2005. Some of the goals of GIT were as follows:
- Speed
- Simple design
- Strong support for non-linear development (thousands of parallel branches)
- Fully distributed
- Able to handle large projects like the Linux kernel efficiently (speed and data size)
3. How Git stores data
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored.
4. Git Features
- Nearly every operation is local.
- GIT has integrity.
- Everything in Git is check-summed before it is stored and is then referred to by that checksum.
- You can’t lose information in transit or get file corruption without Git being able to detect it.
- The mechanism that Git uses for this checksumming is called a SHA-1 hash. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents.
- GIT generally only adds data.
- The 3 states: committed, modified, and staged
- Committed means that the data is safely stored in your local database.
- Modified means that you have changed the file but have not committed it to your database yet.
- Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
5. Where to find Git
GIT source can be downloaded from here.
For windows it can be downloaded from here.
For Mac it can be downloaded from here.
6. Installing Git
- Installing on Linux:
If you want to install Git on Linux via a binary installer, depending on linux distribution, use one of the following commands:
$ yum install git-core
or
$ apt-get install git - Installing on Mac:
$ sudo port install git-core +svn +doc +bash_completion +gitweb - Installing on Windows:
Just use the installer…
7. Git Configuration
To understand how to configure Git, follow link here.
8. Getting Git Help
To get Git help use any of the commands:
$ git help <verb>
or
$ git <verb> --help
or
$ man git-<verb>
9. Quick References
For quick reference to Git commands, one can follow link:
10. Conclusion
In this tutorial we learnt basics of Version Control moving on to Git, what it is, why it came into picture, followed by where one can find Git, how it can be installed and links to quick reference guides to Git commands.
