Unverified Commit 62ea29d5 authored by Laurent Modolo's avatar Laurent Modolo
Browse files

tp.md: add section on committing and branching

parent 26dbeaac
......@@ -43,11 +43,14 @@ editor = vim
co = checkout
ci = commit
st = status
lo = log --graph --decorate --date-order
lg = "log --pretty=format:\"%h - %an : $s\""
lo = log --graph --decorate --date-order --all"
lg = "log --pretty=format:\"%h - %an : %s\""
lt = "git log --graph --oneline --all"
unstage = "reset HEAD"
```
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
![git areas](img/three_git_areas.png)
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.
```sh
git clone https://gitlab.biologie.ens-lyon.fr/LBMC/file_handle.git git_basis_tp1
git -c http.sslVerify=false clone https://lmodolo@gitlab.biologie.ens-lyon.fr/LBMC/file_handle.git git_basis_tp1
cd git_basis_tp1
ls -l
```
......@@ -281,8 +498,8 @@ git remote -v
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)
......@@ -331,7 +548,7 @@ Clone **W**’s repository:
```sh
git clone https://gitlab.biologie.ens-lyon.fr/<W_name>/git_basis.git git_basis_tp2
git clone -c http.sslVerify=false https://gitlab.biologie.ens-lyon.fr/<W_name>/git_basis.git git_basis_tp2
git clone https://gitlab.biologie.ens-lyon.fr/<W_name>/git_basis.git git_basis_tp2
cd git_basis_tp2
git remote -v
git checkout -b tp2
......@@ -360,7 +577,7 @@ git status
Developer **C** is now ahead of `remote/master` by one commit.
```sh
git -c http.sslVerify=false push
git push
```
The command is not working. Git writes a useful message giving you the right
......@@ -373,7 +590,7 @@ get the last version of the project.
```sh
git branch
git -c http.sslVerify=false fetch perso
git fetch perso
git status
git branch
```
......@@ -408,7 +625,7 @@ While **W** is contributing to the redaction of the documentation, developer
**C** continue to work on it:
```sh
git -c http.sslVerify=false fetch
git fetch
git status
```
......@@ -428,13 +645,13 @@ Then `file_handle.py` will return the absolute path to the last version of
git add README.md
git commit -m "README.md: add -f option description"
git status
git -c http.sslVerify=false push
git push
````
## Developer **W**:
```sh
git -c http.sslVerify=false push
git push
```
When **W** tries to push his modifications to the remote repository he has an
......@@ -443,7 +660,7 @@ Git advise you to use the command `git pull`. We are not going to use this
command and instead to:
```sh
git -c http.sslVerify=false fetch
git fetch
git status
git merge FETCH_HEAD
```
......@@ -484,7 +701,7 @@ to complete the merge:
```sh
git add README.md
git commit
git -c http.sslVerify=false push
git push
```
# Conclusion
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment