Using Git

From Tecniq

Warning, this page is a Work In Progress.

As such, the information contained within this page is incomplete.

Dylan Swift, Moderator, http://tecniq.info

Using Git: this is a basic tutorial on what git is, command for git, how to use git, etc. Git is an open-source, source code revision control system created by Linux Torvalds. It allows for fast, inexpensive branching, merging, history etc.

Introduction

Git is a fast (inexpensive) source code revision control system. It incorporates history, undo, commit, sharing, branching and merging functions

git tracks changes, not files
git allows users to create their own branches
git repositories are local & file based
git servers (git://, ssh://, http://, rsync://) can be used for sharing

Basics

Git is a file based revision control system that tracks changes made to files that have been added to the repository, or inidicates if there are new files not yet added to the repository

Git allows a user to create their own branches, removing any need for administrator assistance. Git allows users to share their repository, or format patches for submission via email. Git shows differences between the users current code and other branches / other users code on accessible servers.

Before you start in earnest, you should do a few things:

read the man page, especially the gittutorial man page (also see references)

set your username

git config --global user.name "Your Name"

set you email address

git config --global user.email you@yourdomain.example.com

Other Configuration Options

set the user interface to colourise

git config --global color.ui true

using the --global switch forces git to store the configuration values in your global configuration file at /home/<user>/.gitconfig
if you omit the --global switch then the value is local to the current git repository (./.git/config)

You can also set aliases to the git subcommands:

git config --global alias.lol log --pretty-oneline --abbrev-commit --graph --decorate

uses the short command git lol to replace the long command git log --pretty-oneline --abbrev-commit --graph --decorate

Getting Started

Start by creating a repository. Change directory to the location of your working code (or where this code will be kept). Issue the initialise command

git init

If you issue a ls -la command you will notice a .git directory. It is within this directory that git stores all the difference information between versions.

Now create some files (either new files, or by unpacking / moving existing code) & fill them with content
Now you need to tell git to track these files

git add <filename>

or

git add .

for all files in the current directory & subdirectories.

Now you can commit these files

git commit -m "commit message"

the -m "commit message" is optional, and if you omit it you will be presented with a vi session for you to edit the commit information yourself.
N.B. it is best practice to start the commit message with a short summary (say 50 chars or less), followed by a blank line, followed by your comments. This is because many systems have commit message to email scripts in place, and will use the 1 line summary as a subject line, with the bulk of the commit message as the body of the email.

(Any more changes to the files will require you to add then commit again.)

To see the current status use

git status

To see the last updates use

git log

Using Branches

>>>Remember branches are CHEAP<<< - ie they consume little in the way of resources to create them

Create a new branch with

git branch <branchname>

Show the existing branches with

git branch

Change branch with

git checkout <branchname>

Compare a branch with the current branch

git diff <branchname>

Merge a branch with the current branch

git merge <branchname>

Merge branch 1 into branch 2

git checkout branch2
git merge branch1

Note this is different to the reverse (branch 2 into branch 1) in terms of the history recorded in the branches if there are no conflicts.

Delete a branch

git branch -d <branchname>

If there are un-merged changes then this will fail. To force a deletion use a capital D.

Synchronising Remote Repositories

Assuming you have created your repository locally and populated the code and you are ready to share your work with the world:

goto your online repository and create the new repository - the method depends on the provider of the repository
specify the remote repository in git
```
git remote add origin <url>

eg git remote add origin git://git@github/dswift/test.git
```
this adds the remote repository as the location 'origin'
push your code
```
git push origin master
```
this pushes your master to the remote repository defined previously as 'origin'

Now the second user:

Clone the remote repository
```
git clone <url>
```
Note that at this moment you have a complete history of the entire repository - all the versions and history is included
make the necessary changes and commit locally
push the new copy to the remote repository
```
git push origin master
```
Note that you are pushing your master copy to the origin server.

Note also that the origin is defined automatically by the clone command, ie no need to define it with remote add

Now the primary user again:

download the new code
```
git fetch
```
this gets the latest code and stores it under origin/master. It does not update your master, therefore you will not lose any work you are currently working on
see the new code
```
git branch -a
```
view the changes in the new code
```
git diff origin/master
```
merge (or not) the changes

Additional Commands

Cherry picking changes

Assuming 2 branches with 2 changes each:

===M0-->M1-->M2
    \
     \R1-->R2

and you would like to take the change made in R2 (ie diff R2 R1), but not the change in R1 (ie diff R1 M0), to make a checkout M2R2

using git log to find the SHA (remember the git lol alias shown earlier?)

while in the master branch (assuming that's where you wish to merge into) issue the command git cherry-pick <SHA> and you should get the following:

===M0-->M1-->M2-->M2R2
    \
     \R1-->R2

Workflows

Traditionally workflow with a tradition source code revision system would have been along the lines of a single master location for the source code & multiple copies. The first person to check in wins, the second & subsequent check ins from other users require manual merging.

whygitisbetterthanx suggests 2 new workflows:

For a smaller projects/groups a master copy is available from where multiple developers can check out code. To submit changes they have to make their branches available to a lieutenant who merges them back into the master copy
for larger projects/groups the lieutenants merge the code into their own copy of the repository. These lieutenants make their code available to a dictator who merges these back into the master copy

see http://whygitisbetterthanx.com for diagrams