# examples on using git.

# inspired from http://www.vogella.com/articles/Git/article.html

# we will create a new project, create a remote repository from it, and

# create a second clone of it, and show how to interact between them.

temp1 temp2

/ \ |

/ \ |

/ \ |

myproject myproject.git myproject

(original) (remote/bare (clone)

repo)

1. make a new directory to house our project. This is our starting point

-- mkdir temp1; cd temp1; mkdir myproject

-- cd myproject

2. copy our initial project code into this directory

3. initialize the git repository -- this will put our project under

version control

-- git init

add files to git for tracking

-- git add .

commit the files

-- git commit .

Notice that an editor window pops up (vi by default). It is very good

practice to put in a descriptive message about the change here. This

will be stored in the log this file / project, and help you understand

the history of changes.

4. make some changes -- add a new print line to the file

-- print *, "even fancier now"

and change the value of a

-- a = 4.0

ask git how the local copy differs from what is in the repo:

-- git diff example.f90

(can also just do "git diff" alone)

5 build it

-- gfortran -o example example.f90

look at the status of the project

-- git status

notice that it identifies the executable as untracked, and the

source file as modified

6. commit your changes to the source file

-- git commit .

review the history

-- git log example.f90

(git log -p will show the changes in the history)

This is your local initial repository. Now we want to create a remote

repository. This is a "bare repository". This does not include the

files themselves, but only the git repository files.

Remote repositories allow different people to sync up -- push, pull, etc.

7. clone our project in top-level directory (temp1/):

-- git clone --bare ~/temp/myproject

note the "--bare" -- this creates the bare repo. This is something

that you can push to and pull from.

now you have:

temp1/myproject/ -- your original git repo

temp1/myproject.git/ -- the bare repo

8. create the origin tag for our original repo

in temp1/myproject

-- git remote add origin ../myproject.git/

"origin" is a special name. For most users, the origin will be

set automatically to point to the place they cloned from. This

directory is the original creation point for the project, so it

didn't come from anywhere.

9. make some changes in temp1/myproject

-- emacs -nw README -- add some text

-- git commit .

-- git push

The "push" syncs our changes up with the origin (the remote repository).

So far this workflow is basically what a single user would do. Not all

that exciting. Now imagine someone else comes along. Working in a new

directory, temp2, they can clone our remote repo

10. In a new directory: temp2

-- git clone ~/temp/myproject.git

-- cd myproject

Note that we have all the files -- this is a new local copy of our

source tree that someone else can work on.

11. this new user makes some changes:

-- edit README, add some stuff

-- git commit .

-- git push

This pushes your changes to the remote repository

12. back to the original user in temp1/:

-- git pull ../myproject.git

This gets the new changes from the other user.

This is the simplest work flow -- these two users can share changes. Git

manages the history and syncs things up. It will also resolve conflicts

if there are changes to the same file, etc.

Fancier things:

A. if your bare repo is on a remote server, you can:

git clone username@server:/path/to/repo

to get a clone on your local machine. Now when you push and pull, you

will be prompted for your password.

B. rolling back to an earlier version via branching

branches are working places for the source. They let you

experiment and then either discard or merge your changes.

-- git branch

This shows the current branches

-- git checkout hash

where hash is the first commit

This will switch us to a new (detached) branch looking at the source

at an earlier instance in time.

-- git branch

We are no longer on the master

-- git checkout master

Back to the master source -- latest time

We can use this to make a named branch for experimentation

-- git checkout -b experiment

This creates a new branch called experiment and switches us to it.

Note that right now, the source is identical to what we started

with.

Add to example.f90:

-- print *, "experiment"

-- git commit .

This commits our change to example.f90 on the experiment branch only.

Now go back to master:

-- git checkout master

Notice that the experimental change is not there.

Say we are happy with our experiment and want to merge it into the

main (master) source:

We are already on master, so

-- git merge experiment

C. destructive rolling back

In the git logs, there is a hash next to each change. This uniquely

identifies the version of the code. You can force your repo to go

back in time as:

git reset --hard hash

Note: this destroys the changes after that in your local copy of the

repo. Don't worry, you can always clone again from the remote.

Don't do this in your only copy of a repo (i.e. one that has never

been cloned).

There are other methods of just getting old versions

(look at revert, for example)

D. you can put a link to your bare repo on the web and anyone can

anonymously clone it:

http://bender.astro.sunysb.edu/hydro_by_example/download/

I make this a separate bare repo that is not writable to by others.

This bare repo is update nightly via cron through this script:

cd /home/www/hydro_by_example/download

# _stage/pyro2 has as its origin the remote repo that I interact

# with when developing

cd _stage/pyro2

git pull

# this pushes any updates we just got from my main remote repo

# to the version I have for distribution

git push --all ../../pyro2.git/

# this command is necessary to make the changes available over

# the web

cd ../../pyro2.git/

git update-server-info -f