Version control is the management of changes to documents, computer programs, and general collections of information. I will refer to it as a project.
Version control is a means in which several people can work on one project. It also allows you to review changes that people have made in the past.
Version control should not be used to store files for later retrieval, it is not a backup system. The whole point of a version control is to reduce the complications of dealing with several versions of a program. Lets face it, it is called ‘version control’ for a reason.
Version Control Systems (VCS) are programs used for version control. Some common version control systems out there currently are SubVersion (svn), Concurrent Versions System (cvs), Git (git), and Mercurial (hg). Today we will be talking about git.
NOTE: A lot of this terminology might be specific to git.
A repository, or ‘repo’ for short, is where the main project is being held. The main project can either be remote, or in a different folder. It is usually where the project started, and is often called the origin of the project.
Every project, upon creation, uses only one branch called the ‘master’ branch. When you ‘branch’ or ‘fork’ a project, you are basically making a copy of the project with it’s own history of version control. You can think of branches as making copies of your project.
A ‘commit’ is the action of writing, or merging any changes you have made to a project stored as a local copy.
Pushing is when a local copy of your project is then copied, or pushed onto another project, usually the main repository (remote origin). It is like merging.
Pulling is the same as pushing, but you are copying, or pulling another project into your local copy of the project. It is like merging.
When your local copy has been updated, and the remote copy has been updated since then, you must merge. Merging can either be resolved by the server itself, or it will produce a conflict which must be resolved by the user.
Conflicts are caused by a merge which has modified files that have differences between them. These differences are then resolved or fixed by the user, and the merge can then be completed successfully.
Refers to the latest commit.
Tags are used to give a specific commit within the version control history a special name which you can then use to refer to that version of the project. ex. version 1.0, version 2.0b, version 2.0f
same as local copy
Git is a version control system, which applies the distributed approach of version control. It is a source code management system with emphasis on speed. It was originally designed and developed by Linux Torvalds himself.
Distributed Version Control is a peer-to-peer approach to version control. It is flexible in the sense that anyone can grab the project, work on it, and make new versions without ever collaborating with the main project. It resembles that of a remote backup system. The main idea to consider in regards to distributed systems, is there is no central, or designated server for any given project. This makes git a very flexible system.
Yes! It’s called Centralized Version Control, and it requires you to talk to a master server. Very inflexible.
$ sudo apt-get install git
or if the system is an older version ubuntu (I think <10.04)
$ sudo apt-get install git-init
Install msysgit
Before you start using git, it is recommended that you first provide a user.name and user.email upon which the repositories can refer to when making commits. This can be done with two simple functions.
$ git config –global user.name “John Doe”
$ git config –global user.email [email protected]
If you wish to change the editor which handles, modify the configuration:
$ git config –global core.editor emacs
However, this is untested for windows.
Each git repository has a .git/config designated to it, which is modified to include the user.name and user.email, along with several other configuration options. The –global option, however, modifies ~/.gitconfig which contains your git default configuration values which are used with newly initialized git repositories or newly cloned repositories.
So if you wish to only change settings within one specific git repository, you remove the –global option.
Open a terminal (In windows, open Git Bash) type:
$ mkdir testingGit
$ cd testingGit
$ git init
$ touch readme.txt
$ git add readme.txt
$ git commit -m “First Commit”
$ mkdir testingGit
$ cd testingGit
We create a folder for testing purposes and change into that directory. Renaming the folder before or after you initialize a git repository has no effect on that repository.
$ git init
This initializes that folder as a git repository and creates folder called .git in the working directory. the ‘.git’ folder contains everything that git requires to track and provide version control capabilities for that folder.
$ touch readme.txt
$ git add readme.txt
The first statement touches the file, which means it creates it, and doesn’t place anything within the file. You can just as easily save a blank text file from notepad or nano.
git requires that you provide exactly which files you would like to commit. When a file isn’t being chosen for a commit, it is called being unstaged. In order to stage a file for commit, you need to add it to the staging area. This is done by calling git add [file]
$ git commit -m “First Commit”
In this command, we are simply commiting our staged files into the repository. The -m argument allows you to provide a commit message on the commandline. Not doing so would end up opening a separate text editor to create a commit message within that text editor. If you prefer to produce commit messages that way, but prefer a certain editor, you can change what editor git will invoke by setting the EDITOR environment variable in .bashrc.
Open a terminal (In windows, open Git Bash), and switching to a directory where you store projects, type:
$ git clone git@addressToServer:nameOfRepo.git
$ git clone git@[host]:[repository name].git
cloning a repository is as simple as giving the name of the server and the name of the respository. A few things you will require in order to fetch a remote repository is the credentials to access the remote server, and credentials to access the repository (for gitosis specifically).
- Open a terminal (git bash in windows)
- First, we must check to see if you have an ssh-key, navigate
to the ssh configuration folder, located at ‘.ssh’
$ cd ~/.ssh
and check to see if a file named id_rsa.pub exists. if it does, skip to step 3
- If you don’t have an id_rsa.pub, we need to make a new set of keys. This is done by typing ssh-keygen.
$ ssh-keygen
a set of prompts will show up, but aren’t required to be filled out, just press enter and use all of the defaults. This will produce the desired id_rsa.pub file located in the ~/.ssh/ folder.
- Contact an administrator and send id_rsa.pub to them, they require your ‘public key’ in order to allow you access to the git server.
Windows systems follow the same procedure as linux, except it might be difficult determining where the .ssh folder is located. First you must open up a git bash shell, provided with msysgit. From there, it can usually be located by going:
$ cd ~
$ pwd
which will then print the location of the HOME folder designed for your windows system. The public key (id_rsa.pub) will then be located in ~/.ssh/
$ git add [files to be commited, which were modified or newly added]
$ git commit -m [description of the commit]
Commiting is very simple, however, in order to understand committing, you need to understand what is being commited. Git handles files as being either ‘staged’ or ‘unstaged.’ A staged file is a file which will be commited.
To stage a file, you must first add it to the ‘staging area’
$ git add [file to be staged]
To view the status of files that have been staged or unstaged, or files that aren’t even being tracked at all, use the command:
$ git status
To unstage a file from being commited
$ git reset [filename]
git reset is basically the exact opposite of git add. Instead of staging files for commiting, it will unstage files.
In more advanced cases, git reset can be used to reset whole commits.
You can recover from a bad reset by viewing the reflog with
$ git reflog
and ‘reseting’ to that state of your reference log
Example:
git reset HEAD^ #reset to the previous commit
#oh no! I want to go back!
git reset HEAD@{1}
View changes between your current unstaged area and a particular commit
$ git diff <commit> [filename]
View changes between two commits
$ git diff <commit> <commit> [filename]
View changes made to files from your previous commit (HEAD)
$ git diff <filename>
Look at changes made from one commit to the next commit (not very useful)
$ git show <commit>
There are two functions which offer different behaviour in how you want to view changes made to files.
The first one git diff, is usually used to view changes between your current unstaged files, and previous commits. Calling git diff by default
$ git diff
will show the differences between your unstaged files and the previous commit (HEAD)
to show the differences for a single file:
$ git diff readme.txt
First thing to note for commits, is how to identify different commits in a repository. To identify different commits, you can use their unique identifier (UID), their tag, or even their branch if you are comparing the HEAD of two different branches.
Usually the UID is unique enough, such that you only need to provide the first 4 alphanumeric letters in order to identify any particular id.
In order to view the commits made, you can use git log to view every commit made on your current branch. This log will also show the UID assigned to each commit.
ex.
$ git diff f7ed [file] <– optional
where f7ed refers to the first 4 letters of a uid for the commit shown in the git log.
git diff can also be used to view changes between commits by simply providing two commit uids in a row. The function itself is able to distinguish between whether you are providing paths or commit information.
$ git diff f7ed 43us [file] <– optional
Assuming the server has a new repository called ‘newRepo’ setup and you have priviledges to manipulate that server and repo. This part is required to initialize the remote repository.
$ mkdir newRepo
$ cd newRepo
$ git init
$ #populate it with your stuff]
$ git add . # be sure to stage everything that needs to be staged
$ git commit -m “First Commit”
$ git remote add origin [email protected]:newRepo.git
$ git push -u origin master
$ mkdir newRepo
$ cd newRepo
$ git init
$ #populate it with your stuff]
$ git add . # be sure to stage everything that needs to be staged
$ git commit -m “First Commit”
The first part is initializing a local repo, staging and commiting.
$ git remote add origin [email protected]:newRepo.git
This command adds a new remote repository named ‘origin’ which is at the url ‘[email protected]:newRepo.git’
$ git push -u origin master
This command will update the remote repository ‘origin’ for the branch ‘master’
The special option ‘-u’ is used to make any later git push operations use the given remote repository as the default.
From there, you can use ‘git push’ and ‘git pull’ to gain access to the remote repository.
$ git push [repository] [refspec]
ex.
$ git push origin master
By default, when you call
$ git push
you are using the default remote respository. This can either be manually chosen from a remote list, or you can change the default by using the -u option whilst pushing.
$ git push -u origin master
git tag -a [name of tag] -m [message about tag]
git push –tags
ex.
git tag -a version-1_2 -m “Version includes better exception handling”
git push –tags
Tags are a means in which several versions of a program can be logged within a branch. Tags can also be used to keep track of a special
http://www.sbf5.com/~cduan/technical/git/
http://monsterboxpro.com/blog/2010/02/22/how-to-properly-commit-to-your-git-repository-rebasing/
