- Installing Git
- Install from the CLI
- $ sudo apt-get install git-all
- First-Time Git Setup
- Configure your user info
- $ git config --global user.name "John Doe"
- $ git config --global user.email firstname.lastname@example.org
- Configuring your editor
- $ git config --global core.editor gedit
- Checking Your Settings
- $ git config --list
- Getting a Git Repository
- Initializing a Repository in an Existing Directory
If you’re starting to track an existing project in Git, you need to go to the project’s directory and type:
- $ git init
- $ git add *
- $ git add .
- $ git commit -m 'initial project version'
- Cloning an Existing Repository
- $ git clone https://github.com/source/git/dir target/git/dir
- Git has a number of different transfer protocols you can use.
- Initializing Git repositories in the Cloud
This was something that I needed to do (for my own personal and private projects). While there are many ways out there to host your private repositories such as the awesome Bitbucket, Github, etc, I was looking at much simpler solution just for myself. All I needed is a versioning system to keep my source codes.
I'm going to demonstrate how easy it is to host your own Git repositories in any of your preferred cloud providers. I chose Google Drive personally.
Lets say you have a project named "johndoe":
- Initialize an empty Git repository:
- $ cd /path/to/project/johndoe
- $ git init
- Make and change directory to where your Google Drive is located and initialize a bare repository.
- $ mkdir /path/to/GoogleDrive/project/johndoe
- $ cd /path/to/GoogleDrive/project/johndoe
- $ git remote add origin /path/to/GoogleDrive/project/johndoe
- $ git push origin master
- Cloning Git Repositories in the Cloud
- To clone your Git repository from Google Drive
- $ git clone /path/to/GoogleDrive/project/johndoe
- Git Version Control
- There are some subtleties to this because of the nature of Git. The way I've done this is by copying what the Git developers themselves do. First, you'll want to use annotated tags which is probably a good idea anyway. To review, you can create a new tag like this:
- $ git tag -a -m "Version 0.2" v0.2 HEAD
- Then you can use
git describefor a useful "version" string that will include the number of commits since the tag and the leading digits of the sha1 of the the current commit. Here's an example from one of my projects:
- $ git describe
- That is, this copy is 3 commits ahead of the "v1.0" tag and the commit sha1 begins with ee47184 (I'm not sure why they include that leading 'g').
- The Git developers take it one step further and also include an extra bit if the working copy is modified (uncommitted). This requires a few more steps so it's all wrapped up in a script they name VERSION-GEN. When run, it prints the version string to standard output and also creates a VERSION-FILE file (the script is careful to not re-touch that file if the version hasn't changed -- so it's build-tool friendly). Then, you can include that VERSION-FILE file in your source code, help files, etc.
- Using my example VERSION-GEN script, my version string for the above example is:
- $ VERSION-GEN
- version: 1.0-3-gee47
- If I modify any of the tracked files it looks like this:
- $ VERSION-GEN
- version: 1.0-3-gee47-mod
- Note that VERSION-GEN expects that the tags marking versions are of the form v[0-9]* (e.g., v1.0 or v0.2 or v12.3.4 or v12.2-4feb2009 etc.)
- Recording Changes to the Repository with RabbitVCS
- Installing RabbitVCS for use with Nemo
A Git IT work in progress....