You can replace `vim` by any other editor of your choice, like `nano` (easier to learn) or `gedit` (graphical).
The **alias** section of the configuration is for shortcuts of git commands.
`git checkout` is now equivalent to `git co` to minimize the number of key
pressed.
...
...
@@ -107,21 +110,235 @@ With this second method, you will have to replace every `https://gitlab.biologie
# Part 1: Git alone
Git is a powerful tool to keep track of changes in your project and to manage
your modifications history. In this first part of the TP you will practice
different git commands to keep track of your work and modifications with Git.
Git is a powerful tool to keep track of changes in your project and to manage your modifications history.
In this first part of the TP you will practice different git commands to keep track of your work and modifications with Git.
## Your first git repository
### Creation of a git repository
Start by creating a folder `alpha` in which you are going to write your project
```sh
mkdir alpha
cd alpha
```
Once in the alpha folder, you can initialize a git repository.
A git repository is a project tracked and indexed by git.
```sh
git init
ls -la
```
The `git init` command create an hidden `.git` folder at the root of your project.
You should not temper with the content of the `.git` folder.
Everythings in the `.git` folder belong to git the rest of the `alpha` folder belong to you.
When you issue `git` command the content of the `.git` folder is accessed or modified by git.
### Using git to track changes
There is nothing in our repository:
```sh
git status
git st
```
We defined `st` as an alias of `status` in the `~/.gitconfig` file, so the two command are equivalent.
Our first code:
```sh
mkdir src
git st
echo 'a' > src/dict.txt
git st
```
Git don't track folders, only files. For git folders are just structures to organise files.
With the creation of `dict.txt` git is aware of a change in the repository.
There are *untracked files*.
To start tracking file we use the command `git add` :
```sh
git add src/dict.txt
git st
```
There are now changes to be committed, this means that git is now following the state of the `src/dict.txt` file.
The current state of `src/dict.txt` is recorded.
```sh
echo 'b' > src/dict.txt
git st
```
We changed the state of `src/dict.txt`, but those changes are not staged for commit.
The previous states of `src/dict.txt` is still recorded *somewhere* even if it differs from its current state.
This *somewhere* is called the staging area (where you stage changes).
You can save the state of the staging area definitively with the command `git commit`
```sh
git commit -m "a: my first commit"
git st
```
You cleared the change to be committed and wrote them in a commit.
```sh
git log
git lo
```
You wrote your first commit with an unique identifier:
`c7a4cb9c7665b422081794402155af9dcfdbeab1`
In git, there are 3 areas:
- The working area (everything in `alpha/` except the folder `.git`)
- The staging area
- The repository
The repository is a chain of commit beginning with your first commit.
### Navigating a git repository
Let's create a new commit with the changes made to `src/dict.txt`:
```sh
git add src/dict.txt
git commit -m "b: my second commit"
git st
git lo
```
You have a second point in your commit history.
You can navigate to a given point of the repository with the command `git checkout`:
```sh
cat src/dict.txt
git checkout c7a4cb9
cat src/dict.txt
```
You don't have to give the complete commit identifier for the command `git checkout`, only an unique subset of it.
The state, of the file `src/dict.txt` is back to the one at the time of the first commit.
The `git checkout` or `git co` command rewrite your whole working area to match the state of the targeted commit.
```sh
git lo
```
The `git lo` command don't display your second commit anymore.
Git commits only know of their direct ancestor(s).
The other change is in the first line of the `git lo` command:
`(HEAD -> master)` became (HEAD).
This change mean that you are in a *detached HEAD* state , the command `git st` also gives you this information.
```sh
git st
```
In git commit are chained one after another starting with the first commit.
Therefore, you can always go back in the commit history.
The repository, is not only made of commit but also of labels.
Labels point to a commit and can be the target of the `git co` command.
They are two types of labels:
- branches
- tags
If the first commit is the root of a growing tree of commits, branches are the leafs of the tree.
They change after each commit from pointing to the ancestor of the new commit, to pointing to the new commit.
The default branch in git is called `master`
Contrary to branches tags are anchored to a fixed commit.
*HEAD*, is a special label that indicate your position in the tree of commit.
You can add a tag to your first commit with the command `git tag`
```sh
git tag -a v0.1 -m "my version 0.1"
git tag
git lo
```
You now have one tag in your repository.
The commit `c7a4cb9` is pointed by the tag `v0.1`.
```sh
git co master
git st
git lo
```
We are back at the leaf of the git repository.
### Growing the repository tree
We only have one branch, the `master` branch in our repository.
This mean that we only have one timeline in our history.
In git, you can have as many branches as you want, to tests out things for example.
The following command create the branch `dev` and move us (*HEAD*) to it.
```sh
git co -b dev
git st
git lo
```
```sh
echo '1' > src/num.txt
git add src/num.txt
git commit -m "1: first commit in dev"
git lo
```
If we have two branches `dev` and `master`, it's hard to tell them apart (`master` is shorter).
```sh
git co master
echo 'c' > src/dict.txt
git add src/dict.txt
git commit -m "c: third commit in master"
git lo
```
Congratulation you have a fork in your git repository !
Lets make another one called `dict` from the branch `master` where `src/dict.txt` contain the letter `d`.
### Merging branches
When you are ready to incorporate your new code in your main branch you need to merge the branch containing the new code into your main branch.
You can merge branch with the command `git merge`.
This command is going to try to merge the targeted branch into the branch you are on (*HEAD*).
## Cloning a git repository
We start by cloning an existing repository. `file_handle.py` is a small python
script to handle the dating and the access to dated files in a format compatible
with the [guide of good practices at the LBMC](http://www.ens-lyon.fr/LBMC/intranet/fichiers/bioinfo/good-practices.pdf).
The `git clone <url>` command retrieves the whole history of a project and setup a
working area based on the last point in this history.
We start by cloning an existing repository.
`file_handle.py` is a small python script to handle the dating and the access to dated files in a format compatible with the [guide of good practices at the LBMC](http://www.ens-lyon.fr/LBMC/intranet/fichiers/bioinfo/good-practices.pdf).
The `git clone <url>` command retrieves the whole history of a project and setup a working area based on the last point in this history.
Then we use the following commands to push our local copy to our remote repository:
```sh
git -c http.sslVerify=false push -u perso --all
git -c http.sslVerify=false push -u perso --tags # tags need to be pushed separatly
git push -u perso --all
git push -u perso --tags # tags need to be pushed separatly
```
## merging branches
...
...
@@ -301,7 +518,7 @@ However, the reverse operation is possible:
git checkout master
git branch -v
git merge tp1
git -c http.sslVerify=false push perso
git push perso
```
You can see the graph of our modifications at the following address [http://gitlab.biologie.ens-lyon.fr/user_name/git_basis/network/master](http://gitlab.biologie.ens-lyon.fr/user_name/git_basis/network/master)
