[linuxmotion]

Welcome all, for those of you who are reading this you may have heard of a program that is called git that is used to manage the source code of various projects. I will first start off with a little history of GIT and then will proceed into the usage of GIT.

Note: All text with <TEXT> means to replace TEXT with the proper text/path/name
For these examples we will be using github.com, which you can create an account for free at.

History
Section A: A brief history and overview of git
Installation:
Section B: Install from package manage
Section C: Installation from source
Usage:
Section D: Git basics
Section E: Git pull
Section F: Branching and git merge
Section G: Git rebase
Section H: Git workflows

 

[linuxmotion]

History of GIT
SECTION A:
WILL COME LATER

 

[linuxmotion]

Installations

SECTION B: Install from package manger
All systems will install from the command line
Ubuntu: sudo apt-get install git-core

SECTION C: Installation from source:

First you will need some development packages

$ sudo apt-get install build-essential libssl-dev libcurl3 libexpat-dev tk​

Then you will need to get the git source from

http://git-scm.com/ or https://github.com/git/git​

From there change to the directory of the source code

$ cd <path_to_source>​

Make the configuration file

$ ./configure && make configure​

Create the package

$ make all -j<number of cores>​

Install Git (for all users)

$ sudo make install​

 

[linuxmotion]

Section D: Git basics
After git is installed you should setup a couple of setting
git config --global user.name ""
git config --global user.email ""
Try not to think of git as a complex program but as many simple programs rolled into one, each with there own purpose. Almost all of Git's commands are prefixed by.... you guessed it, $git.
So to start of lets get an already created git repository or git repo.

$ git clone [email protected]:linuxmotion/GitGuides.git

This shell command means invoke the git command and create a git repo called GitGuides
using the information from the url to grab the data. This is the most basic of commands. Optionally you can specify the directory to clone into is called by adding it after the URL.

$ git clone [email protected]:linuxmotion/GitGuides.git Guides

Now lets say you whant to create a new git repo from scratch. We create a new clean git directory by first creating a empty directory. After the directory is created we will then initialize the repo.

$ mkdir
$ cd
$ git init

Now that the repo is initialized we can add some files to repository. We add files to git repository by first creating a file then using 'git add '. Here I am telling git to include all the files the are in the current working directory, optionally you can individually specify which files to inlcude.

$ touch README
$ git add .
Or
$ git add

Once the files are added we can then 'commit' them to the repo. 'Committing' means that we want to include that file in the repository and track the changes that are made to that file. Commits are the saved state of the repo. Commits take a message that allows them to be looked over with a title and message so that users can tell what has happened. If 'git commit' is used without passing the -m flag, or message flag, the default text editor will be brought up to prepare a message for the commit.

$ git commit
or
$ git commit -m''

Now that we have created the git repository and commited some files we can now upload or 'push' the changes to a semi-central location github.com. Assuming that you used github.com to create the repoistory to push to and is the repo is called GitGuides then the URL I would use is [email protected]:linuxmotion/GitGuides.git. First to push to a location you will have to add a remote, or a place to download/upload changes from.

$ git remote add origin [email protected]:linuxmotion/GitGuides.git
$ git push origin master

Optionally you specify what branch that 'git push' will push to without arguments by specifying the upstream branch to track with. From the current branch we issue the set-upstream subcommand. Since we are on the master branch this set the master branch to track the master branch from the remote.

$ git branch --set-upstream master origin/master

With the upstream set we can now push the changes to github using if the branch is created in the upstream repo, otherwise you must use 'git push '

$ git push

Now you may be asking why you didnt have to add the remote when you cloned the first repo. Well when you clone a repository using git clone, a tracking branch is set up automatically called master that tracks origin/master.

There you go, now you can get a already created repo, create a repo yourself and you can push changes to the repo. You may be wondering, 'How do I get changes from others that commited on the project'. Since that can be a little more tricky it will be covered in the next section

 

[linuxmotion]

SECTION E: Git Remote
To continue the guide properly one will need to know the basics of remotes, or places that code is stored at. A remote can be the local computer, a computer on a local network, or a location on the Internet.

SECTION E: Git pull
Now that you can create, and push changes to a git repo its time to learn how create a branch and grab external changes. Assuming that you have created a project called GitGuides, have commited to it, and that others can also commit to, I will now show how to pull in changes that others have commited while you were away. Assuming that you have not made more changes since the time that someone else has commited we will start by issuing a 'git pull'

$ git pull <remote> <branch>

Since we have setup a tracking branch from the earlier example we can issue a simple command that will pull in changes from the remote tracking branch.

$ git pull

Since this example assumes that you havent made any changes since the others have commited while you were away. This will 'pull' in all the files cleanly. We will reiterate about 'git pull' when we deal with branches and how a simple yet affective workflow can be achieved.</remote>

 

[linuxmotion]

SECTION F: Branching and git merge Here is where git starts to really shine. So far we have only made changes or grabbed changes while development doesn't conflict or only one user has commited. In reality this doesn't happen for every project. When developing with android there are time when four of us are working on the same file, completely independent of each other. Well you may be thinking I'm going to need to decipher which code to keep and which to not. Thankfully git has great algorithms for combining code. The basis of this relies in the branching scheme that git uses along with the way it views a projects changes. First lets assume that the project GitGuides has a team of writers that continually make changes. If they were all committing to the one master branch, when pushing or pulling you would get errors telling you that it cant force the update. Meaning that changes were made to the master branch while you were making changes to the master barnch without first having those changes localy. To solve this problem we create a new branch named 'intro_guide' from the current master branch. Then we switch to that branch using 'git checkout'.

$ git branch intro_guide
$ git checkout intro_guide

A shorthand form that will create a branch at the same point as the current branch and then switch to that branch is

$ git checkout -b intro_guide

From here if you wanted to switch between any named local branches or remote branch you want using

$ git checkout
or
$ git checkout <remote_name>

Now that we can switch branches lets switch to the intro_guide branch

$ git checkout intro_guide

From here make some changes then commit them and specificly add them.

$ echo "change one" >> IntroGuide.txt
$ git add IntroGuide.txt
$ git commit -m'Added change one'
$ echo "change Two" >> IntroGuide.txt
$ git add IntroGuide.txt
$ git commit -m'Added change two'[/INDENT]

From here we want to push the changes up. While we were doing this some of the other authors have also made changes to the master branch. If we were on the master branch when we commited, when we push we would get an errror saying that it 'failed to push some ref specs'. Since we are not on the master branch when we push it will push to the intro_guide branch on github. This is not what we want exactly. So in preperation for the push we switch back to the master branch

$ git checkout master

Now we use 'git pull' to pull in the master branch changes.

$ git pull
or (if there is no tracking branch)
$ git pull origin master

Now the master branch is up to date. From here there are two way that I use, both are the same just opposite from the base starting point. We can start by merging the intro_guide branch into the master branch or merge the master branch into the intro_guide branch. If the same file has been changed in the same places you will still get a merge error, but the error will tell you where the conflict is. Also when this happens it will give you a commit hash that will be used to finish the merge when the conflcits are resolved and added using 'git add '. Assuming that we are on the intro_guide branch we can merge the master branch with

$ git merge master[/INDENT]

Assuming that we are on the master branch we can merge the intro_guide branch with

$ git merge intro_guide[/INDENT]

If the merge fails with a conflict error, open the offending files and look through them. You will find that there are within the file. These are the changed locations.Anything within the first set are the local changes, anything within the second set is the remote changes.Once the merge is completed the resulting branch has the history for master on your feature branch. You can then either completely replace the master branch with the reulting branch or you can push the feature branch to master. To replace the master branch with the resulting intro_guide branch use

$ git branch -D master
$ git checkout -b master
$ git branch -set-upstream origin/master
$ git push

or if you skip the upstream setting you can manually push

$ git push origin intro_guide:master

The ':' in between the branches mean to push from :There we go we can now pull changes from a repo, merge those changes into our, repo, and then push those changes back.</remote_name>

 

[linuxmotion]

Section g:
Will come later

 

[linuxmotion]

Section h:
Will com later

 

[liquid0624]

Very very nicely written guide for github well done bro

 

[Captainkrtek]

awesome guide so far, keep it up man! :grin3: