Git was made by Linus Torvalds in 2005, originally as version control software to better enable contributors to upload code to the Linux kernel. Git is a version control system. Sometimes referred to as an SCM (source control management) system.
Since then its use has far outgrown the Linux ecosystem and is used by millions of software developers worldwide (42.9% of all software developers use it over any other version control system). It’s not only for software developers, regular joe’s that want to share or store things, for example, configuration files or websites. Git allows them to have a place where they can store (and more importantly, collaborate – or merge) their content.
What exactly does it do, in layman’s terms?
Here are two main reasons why you would want to use Git:
- Collaboration: You want to collaborate on some files – eg a developer writes one line of code, and another developer writes two lines of code. This can be ‘merged’ back up to the ‘git server’, so that it becomes one file.
- Version control/tracking: You want to be able to track the changes that the other contributor(s) have made. The tracking ability will let you see if there are mistakes that need to be reverted.
Another reason is that if you are in a job which involves application development in any way (for example, if you are a coder, or if you are a system administrator that needs to make revisions of your configuration management data, or just clone developers code) – using Git is the generally accepted version control system these days. Not knowing how to use it will likely put you at a career disadvantage.
Git vs Github
A Git server can be installed on any Linux server. Accessing it generally requires the use of the git client, which is a command line tool. More on that in the below section.
Github is a widely used web based public Git service for people to work on projects across the Internet. It is not affiliated with Linus Torvalds or any of the git project folks, it is a web based adaptation of a git server. It leverages all of the main components of git, and offers further extensibility via its web interface. The main benefit of github is that it is a public git repository that you can still connect to via the usual git client. Github also offers private repository services, however these are paid for.
Other commercial products are also available which implement some or all of git’s service, such as Atlassian Bitbucket.
Important terminology and commands
The git client command is entered at the terminal and has a number of options. You’ll find that git is probably already installed on your Linux machine. If it isn’t, it’s a sure fire thing to expect that it’s only a apt-get or a yum install away.
The most pertinent of those are listed below. Keep this handy as it will be useful as a cheat-sheet whilst you get started with Git:
| Command | Description |
| clone |
Makes a copy of a git repository. For example, whenever you download things from a github/git site (repository), you’ll be using clone. |
| init | Initialises an empty Git repository in the current directory. eg: git init /home/mycode |
| status |
Shows the status of the repository. You’ll do this often, so you can track any changes to the repository. |
| add |
Adds file(s) to a staging area, so that changes can be tracked locally. Tells git to start tracking changes for the file you specify. Note that this doesn’t commit them to the branch, it’s in a local staging area, e.g:
To add multiple files/directories, you need parentheses around wildcards so that git gets the list of files before the shell operates on the wildcard. This example adds every .jpg file in all the directories below the current directory (including the current directory):
|
| commit |
Commit a staged (added) change. To commit a change means “all of these add’s I’ve done, take them out of the staging area and commit them to my repository”. It’s mandatory to commit with a message. The message should describe what the commit is for, eg, you could say that you’ve added a few jpegs of cats. |
| remote |
Configure a remote repository to push commits to. Any changes you have committed locally can be uploaded to a remote repository. Github is a remote repository for example. To initialise your remote git server connection, you use git remote. Eg:
|
| push |
Push committed changes to a remote repository. Once you have initialised your remote repository, you can push the committed changes to it with push:
|
| pull |
Merges changes from the remote repository with your local copy. Once people (or you) have committed more changes to the repository, you want to issue a pull request to merge the changes you have locally with the upstream (remote) repository.
|
| diff |
Shows what differences there have been to the repository since the last commit. When changes are committed to the remote repository by more than one person, there will be differences between what you have stored locally and that which is on the remote server. Differences are called diffs. When you do a pull, this will let your local To view the differences between your most recent commit and that of what exists in the remote repository, you can use the HEAD pointer. HEAD is simply a position indicator, by default it points to your most recent commits.
The output will show the differences between your copy of any changed files, vs the remote copy (adds and subtractions). To see differences between the files in your staging (added) area and the local files on your PC, use |
| checkout |
Revert to a previous commit, or switch branches. Let’s just say that you made a commit of file.txt that you decided was no good, and you wanted to go back to a previous committed version, you’d revert it as so:
To change a branch, specify the branch name (rather than using the — or supplying a filename to revert):
|
| branch |
Creates a new copy (branch). The command also deletes or lists present branches. For more information on what a ‘branch’ is, see the terminology below. The below example creates a new branch called ‘newbranch’:
The below example deletes ‘newbranch‘:
|
| rm |
Removes files from the current branch, as well as the local disk. To remove all of the files, use rm just like you would an add:
|
| merge |
Merges one branch into another. As a practical example, continuing on from the rm command example above, lets assume that you performed an rm *.txt from the branch newbranch. If you wanted to merge that change into the master branch, firstly you would switch back to the master branch by issuing git checkout master, then using the merge command to merge the differences from newbranch back to the current branch (master). Most teams of developers will work on their code in separate branches before merging them into the master branch at the end of the day.
|
| reset |
Reverts (removes) any staged changes. For example, if you have done a git add file.txt, but then before you commit, you decide that file.txt should not be committed, issue the reset command, e.g.:git reset file.txt |
| log |
Show a journal of all of the committed changes. Eg: git log |
Terminology
Some terminology you are going to need to understand is:
- Pull requests – When a team are working on code changes, a pull request is used to signal to the maintainer of the repository to merge a new change.
- Branch – A branch is simply a copy of an existing repository. By default, each repository starts with a ‘Master‘ branch. The master is the name of the main branch.
- The master branch is usually not the working branch, it is often used as the branch when all the developers have completed (committed) their code. It is then merged into it at the end of the day from other working branch(es).
- Fork – A fork is a duplicate copy of someone’s repository. It allows you to make any changes you want to the code without impacting the original project/repository. It is used either to create a new application from the original code base, or as a working scratch to allow a developer to propose changes to the project.
- Staging – When a file is added (with git add) it is said to be staged, or in the staging process. When you commit the change, it is no longer staged.
- Staging is held on your local machine, not in a remote repository.
- In a practical example, say you have a bunch of files that are on a remote repo
See also
The inbuilt manual page called ‘gittutorial’ is a well written tutorial stepping you through the ins and outs of Git usage. To view it enter the following command:
man 7 gittutorial
The following web links are highly recommended:
- Interactive tutorial (trygit)
- Official website
- github website