It’s been quite a long time that I have posted any tutorial of things I have learnt, apart from the daily diary. So as to prohibit the distance between me and my blog to increase further, I decided to start fresh with Git.
Getting a Git Repository
Creating your own Git repository :
- Create a new directory for your project. If it is already made, you do not need to make it again.
~$ mkdir first_repo
- Initialize the repository in your project directory.
~$ cd first_repo ~$ git init
This creates a new (hidden) subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton.
- Record your changes to the repository on your local system or in simple words, work the changes in your project directory on your system.
- Check the status of your files.The main tool you use to determine which files are in which state is the git status command.
~$ git status
- If you have worked out your changes. Running ‘git status’ would give something like :
# On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # ex31.py # ex32.py # ex33.py nothing added to commit but untracked files present (use "git add" to track)
Untracked files are those that have been modified or added but not marked or staged to be committed.
- Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
Let’s run ‘git add’ now to stage the changed or newly added files.
~$ git add <filename> OR ~$ git add <path-to-your-file> (if your current directory is not your working directory)
- Running git status again would give the following output:
# On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: ex31.py # new file: ex32.py # new file: ex33.py #
It is generally useful to frequently run git status.
- Commits represent every saved version of a project. Each commit contains a snapshot of the project, your user information, the date, a commit message, and an SHA-1 checksum of its entire contents.
Run ‘git commit’ to commit the staged changes.
~$ git commit -m "My first commit"
Specify the message in the commit using -m option and then writing the message in quotes.
- To view your commit history, run ‘git log’.
~$ git log
Running this, you can see your latest commit at the top.
- After committing the things, you have saved the changes to your local system. In order to share your project, you must now push the changes to your repository online on the server.
But, wait ! Have you created a repository on github ? No!! Then create it. Go to your github account and Click on ‘New repository’ button to create the repository.
- But how would your system come to know where to push the changes ?
You let your system know this by adding a remote. As you probably know, git is a distributed version control system. Most operations are done locally. To communicate with the outside world, git uses what are called remotes. These are repositories other than the one on your local disk which you can push your changes into (so that other people can see them) or pull from (so that you can get others changes).
The syntax to add a remote is:
~$ git remote add <shortname> <link-to-your-online-repository>
~$ git remote add origin https://github.com/saloni10/first_repo
You can have more than 1 remotes from/to where you can pull or push the things. Remote repositories are versions of your project that are hosted on the Internet or network somewhere.
The short-name I have given here is origin, and it can be any name as well, which is like an alias to a URL. And origin is the usual path of where the remote repo points to.
- The last step is to, finally, push your changes.
~$ git push origin master
This is a command that says “push the commits in the local branch named master to the remote named origin”. Once this is executed, all the stuff that you last synchronised with origin will be sent to the remote repository and other people will be able to see them there.
- You clone a repository with :
~$ git clone [url]
For example, if you want to clone the Ruby Git library called Grit, you can do so like this:
~$ git clone git://github.com/schacon/grit.git
This creates a directory named “grit”, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new grit directory, you’ll see the project files in there, ready to be worked on or used.
- If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option:
~$ git clone git://github.com/schacon/grit.git mygrit
This command does the same thing as the previous one, but the target directory is called mygrit.
Git has three main states that your files can reside in: modified, staged and committed.
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.
Committed means that the data is safely stored in your local database.
This leads us to the three main sections of a Git project: the working directory, the staging area and the Git directory.
At last, Remember the steps…
1. modify and add your work
2. track or stage the files (using git add)
3. then save(their version, if you want) i.e. commit them. (using git commit)
Cloning an Existing Repository
If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone.
Every version of every file for the history of the project is pulled down when you run git clone.
This ends the first basic git tutorial. We’ll get into more of ‘Git’ things in the coming posts. Till then, keep practicing !! 🙂