fixing obsolescent multipage articles
This commit is contained in:
Yann Esposito (Yogsototh)
parent
c3586f0fc3
commit
4f6185f294
24 changed files with 1974 additions and 2305 deletions
|
|
@ -1,7 +1,8 @@
|
|||
-----
|
||||
kind: article
|
||||
image: /Scratch/img/blog/03_losthighway/intro.jpg
|
||||
menupriority: 1
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
created_at: 2009-08-04T12:00:00+02:00
|
||||
title: A try to demystify 'Lost Highway'
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
|
|
@ -11,7 +12,6 @@ tags:
|
|||
- David Lynch
|
||||
- Lost Highway
|
||||
- alternate reality
|
||||
|
||||
-----
|
||||
|
||||
blogimage("intro.jpg","Lost Highway")
|
||||
|
|
@ -22,7 +22,6 @@ blogimage("intro.jpg","Lost Highway")
|
|||
|
||||
Lost Higway is a really good movie. You keep watching it event it seem totally obscure. This is one of the strength of David Lynch.
|
||||
|
||||
|
||||
The first time I watched Lost Highway, I was a bit lost.
|
||||
Here some of explanations of Lost Highway I found on the Internet:
|
||||
|
||||
|
|
@ -52,10 +51,93 @@ Like the protagonist, everybody see what he want to see in this movie. It is an
|
|||
|
||||
Generally, we stay in this movie and we fail explaining everything. There is almost always a point that don't fit within the interpretation of the movie. This is why trying to find a unique good interpretation of this movie is a mistake.
|
||||
|
||||
|
||||
## Interprétation ≠ Explanation
|
||||
|
||||
I give an **interpretation** and not an **explanation**. Just to tell my vision of the movie should be very different from yours.
|
||||
There is certainly many coherent explanations.
|
||||
|
||||
I write this post because I believe I had found an interpretation which seems coherent for most of the movie.
|
||||
|
||||
# Movie's keys
|
||||
|
||||
<div class="encadre" style="text-align: center">
|
||||
<strong>
|
||||
All is in Fred's memory
|
||||
</strong>
|
||||
</div>
|
||||
|
||||
In a first, it is clear for me, it is not a fantastic movie. If you follow this line, you'll face many problem explaining some scenes.
|
||||
|
||||
My hypothesis is the movie describe the Fred's representation of reality.
|
||||
Each of his tries to escape reality will fail.
|
||||
|
||||
Fred had commited an horrible act, a murder, and try to *repair* his memory to accepts it. He'll then create alternative realities.
|
||||
|
||||
- In a first time he kills his wife (Renee) because he believes she cheated at him.
|
||||
- In the second part, he's weaker and will be manipulated by the blond equivalent of Renee to kill Dick Laurent.
|
||||
- In a third part, he kills Dick Laurent
|
||||
|
||||
## Why this interpretation can be valid?
|
||||
|
||||
Because of the dialog at the begining of the movie. Cops ask Fred if he's own a video camera:
|
||||
|
||||
> "Do you own a video camera?"
|
||||
> "No, Fred hates them."
|
||||
> "I like to remember things my own way."
|
||||
> "What do you mean by that?"
|
||||
> "How I remember them, not necessarily the way they happened."
|
||||
|
||||
Then, what we see is not reality but the Fred's perception. Fred is the God of the reality we see. This is why some God/Devil interpretation of the movie works not so bad.
|
||||
|
||||
|
||||
## Who is the mysterious man?
|
||||
|
||||
leftblogimage( "mysteryman.jpg" , "l'homme mystérieux" )
|
||||
|
||||
Who's this mysterious man? He tells Fred it's him who invited him in his house. He's present at the party and in the house of Fred in the same time. Eyes wide open, looking everything Fred's doing?
|
||||
|
||||
It's a key of the movie. In my humble opinion, I believe it represents the bad part of Fred. Certainly jalousy. If I was catholic, I'll said he's Satan. He observe, film but don't act. He helps Fred to kill Dick Laurent.
|
||||
Fred had let him enter and cannot let him go.
|
||||
As _Iago_ of Shakespeare is imprisonned by its own jalousy.
|
||||
The Mysterious Man help Fred doing the acts of violence.
|
||||
It also force Fred to remember the reality.
|
||||
|
||||
When he makes love to his wife (Renee), he sees the face of the Mysterious Man instead of his wife's face. In reality, it's the same person for Fred. It should be her who's the origin of his interior badness.
|
||||
|
||||
|
||||
## Who's at the origin of the video tapes?
|
||||
|
||||
Certainly it's the mysterious man (Fred himself) who makes them.
|
||||
Their reason should be:
|
||||
|
||||
+ Remember the reality to Fred. From Fred point-of-view, video tapes are the reality. He tries to forget reality. But, finally, the video tapes go to the end: the murder of his wife.
|
||||
+ It may also be a reference to pornographic video tapes, made by Renee.
|
||||
|
||||
## What really happened?
|
||||
|
||||
There is many possibilities here. But we have many indices. Here is a supposition.
|
||||
|
||||
### #1 Hypothesis
|
||||
|
||||
The protagonist is a garagist fallen in love with a porno actress. He believe the producer is the bad guy who go again his will. Then he kills Dick Laurent.
|
||||
|
||||
### #2 Hypothesis
|
||||
|
||||
He was really married, he had killed his wife. The the remorse let him create an alternate self, which live in a kind of perfect world. But after the time pass, his obsession about the murder came again. And nobody could know if he had killed Andy or not.
|
||||
|
||||
## which one then?
|
||||
|
||||
The second hypothesis seems better. We can make much more interpretation with it. It explain in most part the strange phone call from Dick Laurent to Pete.
|
||||
But the first hypothesis remain coherent. And, we should probably make an in depth explanantion using the first hypothesis. And I'm not sure it would be better.
|
||||
|
||||
One of the strength of this movie is to understand there is many other coherent hypothesis. It is an expression of the [Rashomon effect](http://en.wikipedia.org/wiki/Rashomon_effect). Many different persons could describe in a coherent manner what they saw. But each description contradicts the others.
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
There is much to tell about this movie. But I believe I put all essential keys here. It is a proof this movie is not a random one.
|
||||
|
||||
I believe it is essential to remember the "test of Rorschach effet" when watching this movie.
|
||||
|
||||
I'd like to know or opinion ; is my interpration wrong?
|
||||
|
|
|
|||
|
|
@ -1,42 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 1
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: A try to demystify 'Lost Highway'
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Movie's keys
|
||||
-----
|
||||
|
||||
# Movie's keys
|
||||
|
||||
<div class="encadre" style="text-align: center">
|
||||
<strong>
|
||||
All is in Fred's memory
|
||||
</strong>
|
||||
</div>
|
||||
|
||||
In a first, it is clear for me, it is not a fantastic movie. If you follow this line, you'll face many problem explaining some scenes.
|
||||
|
||||
My hypothesis is the movie describe the Fred's representation of reality.
|
||||
Each of his tries to escape reality will fail.
|
||||
|
||||
Fred had commited an horrible act, a murder, and try to *repair* his memory to accepts it. He'll then create alternative realities.
|
||||
|
||||
- In a first time he kills his wife (Renee) because he believes she cheated at him.
|
||||
- In the second part, he's weaker and will be manipulated by the blond equivalent of Renee to kill Dick Laurent.
|
||||
- In a third part, he kills Dick Laurent
|
||||
|
||||
## Why this interpretation can be valid?
|
||||
|
||||
Because of the dialog at the begining of the movie. Cops ask Fred if he's own a video camera:
|
||||
|
||||
> "Do you own a video camera?"
|
||||
> "No, Fred hates them."
|
||||
> "I like to remember things my own way."
|
||||
> "What do you mean by that?"
|
||||
> "How I remember them, not necessarily the way they happened."
|
||||
|
||||
Then, what we see is not reality but the Fred's perception. Fred is the God of the reality we see. This is why some God/Devil interpretation of the movie works not so bad.
|
||||
|
||||
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 2
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: A try to demystify 'Lost Highway'
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Who is the mystery man?
|
||||
-----
|
||||
|
||||
## Who is the mysterious man?
|
||||
|
||||
leftblogimage( "mysteryman.jpg" , "l'homme mystérieux" )
|
||||
|
||||
Who's this mysterious man? He tells Fred it's him who invited him in his house. He's present at the party and in the house of Fred in the same time. Eyes wide open, looking everything Fred's doing?
|
||||
|
||||
It's a key of the movie. In my humble opinion, I believe it represents the bad part of Fred. Certainly jalousy. If I was catholic, I'll said he's Satan. He observe, film but don't act. He helps Fred to kill Dick Laurent.
|
||||
Fred had let him enter and cannot let him go.
|
||||
As _Iago_ of Shakespeare is imprisonned by its own jalousy.
|
||||
The Mysterious Man help Fred doing the acts of violence.
|
||||
It also force Fred to remember the reality.
|
||||
|
||||
When he makes love to his wife (Renee), he sees the face of the Mysterious Man instead of his wife's face. In reality, it's the same person for Fred. It should be her who's the origin of his interior badness.
|
||||
|
||||
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 3
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: A try to demystify 'Lost Highway'
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Who's at the origin of the video tapes?
|
||||
-----
|
||||
|
||||
## Who's at the origin of the video tapes?
|
||||
|
||||
|
||||
Certainly it's the mysterious man (Fred himself) who makes them.
|
||||
Their reason should be:
|
||||
|
||||
+ Remember the reality to Fred. From Fred point-of-view, video tapes are the reality. He tries to forget reality. But, finally, the video tapes go to the end: the murder of his wife.
|
||||
+ It may also be a reference to pornographic video tapes, made by Renee.
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 4
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: A try to demystify 'Lost Highway'
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: What really happened?
|
||||
-----
|
||||
|
||||
## What really happened?
|
||||
|
||||
There is many possibilities here. But we have many indices. Here is a supposition.
|
||||
|
||||
|
||||
### #1 Hypothesis
|
||||
|
||||
The protagonist is a garagist fallen in love with a porno actress. He believe the producer is the bad guy who go again his will. Then he kills Dick Laurent.
|
||||
|
||||
|
||||
### #2 Hypothesis
|
||||
|
||||
|
||||
|
||||
He was really married, he had killed his wife. The the remorse let him create an alternate self, which live in a kind of perfect world. But after the time pass, his obsession about the murder came again. And nobody could know if he had killed Andy or not.
|
||||
|
||||
|
||||
## which one then?
|
||||
|
||||
|
||||
|
||||
The second hypothesis seems better. We can make much more interpretation with it. It explain in most part the strange phone call from Dick Laurent to Pete.
|
||||
But the first hypothesis remain coherent. And, we should probably make an in depth explanantion using the first hypothesis. And I'm not sure it would be better.
|
||||
|
||||
|
||||
|
||||
|
||||
One of the strength of this movie is to understand there is many other coherent hypothesis. It is an expression of the [Rashomon effect](http://en.wikipedia.org/wiki/Rashomon_effect). Many different persons could describe in a coherent manner what they saw. But each description contradicts the others.
|
||||
|
||||
|
||||
newcorps
|
||||
|
||||
## Conclusion
|
||||
|
||||
|
||||
|
||||
There is much to tell about this movie. But I believe I put all essential keys here. It is a proof this movie is not a random one.
|
||||
|
||||
|
||||
|
||||
|
||||
I believe it is essential to remember the "test of Rorschach effet" when watching this movie.
|
||||
|
||||
|
||||
|
||||
I'd like to know or opinion ; is my interpration wrong?
|
||||
|
|
@ -2,22 +2,22 @@
|
|||
isHidden: false
|
||||
menupriority: 1
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
created_at: 2009-11-12T12:00:00+02:00
|
||||
title: Git for n00b
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: introduction
|
||||
tags:
|
||||
tags:
|
||||
- git
|
||||
-----
|
||||
|
||||
begindiv(intro)
|
||||
<div class="intro">
|
||||
|
||||
A detailed tutorial of <a href="http://git-scm.org">Git</a> for people knowing very few about versions systems. You'll understand utility of such program and how we use modern version control system. I try to stay as pragmatic as possible.
|
||||
|
||||
enddiv
|
||||
</div>
|
||||
|
||||
newcorps
|
||||
---
|
||||
|
||||
# Begin with conclusion
|
||||
|
||||
|
|
@ -25,13 +25,13 @@ Here is the list of sufficient and necessary command to use [Git][git]. There is
|
|||
|
||||
Get a project from the web:
|
||||
|
||||
<div><code class="zsh">
|
||||
~~~~~~ {.zsh}
|
||||
git clone ssh://server/path/to/project
|
||||
</code></div>
|
||||
~~~~~~
|
||||
|
||||
Everyday [Git][git] usage:
|
||||
|
||||
<div><code class="zsh">
|
||||
~~~~~~ {.zsh}
|
||||
# get modifications from other
|
||||
git pull
|
||||
# read what was done
|
||||
|
|
@ -53,8 +53,570 @@ git commit -a -m "Fix bug #321"
|
|||
|
||||
# send local modifications to other
|
||||
git push
|
||||
</code></div>
|
||||
~~~~~~
|
||||
|
||||
This article is written for people knowing very few about versionning systems. It is also written for those who had didn't followed progress since CVS or subversion (SVN). This is why, in a first time I'll explain quickly which are the goal of such systems. Secondly, I'll explain how to install and configure [Git][git]. Then, I give the command for each feature a <abbr title="Decentralized Concurent Versions System">DCVS</abbr> must have.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# [Git][git] for what?
|
||||
|
||||
<div class="intro">
|
||||
|
||||
If you just want to use [Git][git] **immediately**, just read dark part. You read this part later to understand correctly foundations of version systems and not doing strange things.
|
||||
|
||||
</div>
|
||||
|
||||
[Git][git] is a <abbr title="Decentralized Concurent Versions System">DCVS</abbr>, which means a Decentralized Concurrent Versions System. Let's analyze each part of this long term:
|
||||
|
||||
### Versions System
|
||||
|
||||
Firstly, versions system manage files.
|
||||
When somebody work with files without a versions system, the following happens frequently:
|
||||
|
||||
When you modify a somehow critical file you don't want to loose. You copy naturally this file with another name. For example:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cp fichier_important.c fichier_important.c.bak
|
||||
~~~~~~
|
||||
|
||||
In consequence of what, the new file, play the role of *backup*. If you break everything, you can always return in the last state by overwriting your modifications.
|
||||
Of course, this method is not very professional and is a bit limited. If you make many modifications, you'll end with many files with strange names like:
|
||||
|
||||
<div>
|
||||
~~~~~~ {.zsh}
|
||||
fichier_important.c.bak
|
||||
fichier_important.c.old
|
||||
fichier_important.c.Bakcup
|
||||
fichier_important.c.BAK.2009-11-14
|
||||
fichier_important.c.2009.11.14
|
||||
fichier_important.c.12112009
|
||||
old.fichier_important.c
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
If you want to make it works correctly, you'll have to use naming convention. Files take many place even if you modify most of time only some lines.
|
||||
|
||||
*Fortunately, versions system are here to help.*
|
||||
|
||||
You only have to signal you want a new version of a file and the versions system will do the job for you. It will record the backup where it could be easily recovered. Generally, systems version do it better than you, making the backup only of the modified lines and not the total file.
|
||||
|
||||
Once upon a time versions were managed for each file separately. I think about CVS. Then it naturally appears projects are a coherent set of files. Recover each file separately was a tedious work. This is why versions number passed from files to the entire project.
|
||||
|
||||
It is therefore possible to say, "I want to get back three days earlier".
|
||||
|
||||
<div class="black">
|
||||
|
||||
*What gives versions system?* (I didn't mention everything at all)
|
||||
|
||||
- automatic backups: *back in time*,
|
||||
- gives the ability to see differences between each version,
|
||||
- put a *tag* on some version to be able to refer to them easily,
|
||||
- gives the ability to see an historic of all modifications. Generally the user must add a comment for each new version.
|
||||
|
||||
</div>
|
||||
|
||||
### concurrent:
|
||||
|
||||
Version Systems are already useful to manage its own projects. They help to organize and resolve partially backup problems. I say partially because you have to backup your repository on a decent file system. But versions system are really interesting is on projects done by many people.
|
||||
|
||||
Let's begin by an example, a two person project ; Alex and Beatrice. On a file containing a *Lovecraft*'s gods list:
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
~~~~~~ {.zsh}
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
Say Alex is home and modify the file:
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
after that he send the file on the project server. Then on the server there is the Alex file:
|
||||
|
||||
A bit later, Beatrice who had not get the Alex file on the server make the modification:
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Beatrice send her file on the server
|
||||
|
||||
Alex modification is *lost*. One more time, versions system are here to help.
|
||||
|
||||
A version system would had *merge* the two files at the time Beatrice send the file on the server. And like by magic, on the server the file would be:
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
In real life, at the moment Beatrice want to send her modifications, the versions system alert her a modification had occurred on the server. Then she uses a command which pull the modification from the server to her local computer. And this command update her file. After that, Beatrice send again the new file on the server.
|
||||
|
||||
<div class="black">
|
||||
|
||||
**In what Concurrent Versions System help?**
|
||||
|
||||
- get without any problem others modifications,
|
||||
- send without any problem its own modifications to others,
|
||||
- manage conflicts. I didn't speak about it, but sometimes a conflict can occur (when two different people modify the same line on a file for example). SVC help to resolve such problem. More on that later,
|
||||
- help to know who done what and when.
|
||||
|
||||
</div>
|
||||
|
||||
### decentralized
|
||||
|
||||
This word became popular only recently about CVS. And it mainly means two things:
|
||||
|
||||
First, until really recently (SVN), you'll have to be connected to the distant server to get informations about a project. Like get the history. New decentralized systems work with a local *REPOSITORY* (directory containing backups and many informations linked to the versions system functionalities). Hence, one can view the history of a project without the need of being connected.
|
||||
|
||||
All instances of a project can live *independently*.
|
||||
|
||||
To be more precise, DCVS are base on the *branch* notion.
|
||||
|
||||
Practically, it has great importance. It means, everybody work separately, and the system help to glue all their work.
|
||||
|
||||
It is even more than just that. It help to code independently each feature and bug fixes. Under other system it was far more difficult.
|
||||
|
||||
Typical example:
|
||||
|
||||
> I develop my project. I'm ameliorating something. An urgent bug is reported.
|
||||
>
|
||||
> With a DCVS I can easily, get back to the version with the bug. Fix it. Send the fix. Get back to my feature work. And even, use the fix for the new version with my new feature.
|
||||
>
|
||||
> In a not decentralized version system, doing such a thing is possible but not natural. Decentralization means it become natural to use a branch for each separable work.
|
||||
|
||||
<div class="black">
|
||||
|
||||
**Advantages given by DCVS:**
|
||||
|
||||
- Ability to work offline,
|
||||
- Ability to create many *atomic* patches,
|
||||
- Help the maintenance of many different versions of the same application.
|
||||
|
||||
</div>
|
||||
|
||||
## To resume
|
||||
|
||||
Let's resume what we can easily do with DCVS:
|
||||
|
||||
**Versions Systems**
|
||||
|
||||
- back in time,
|
||||
- list differences between versions,
|
||||
- name some versions to refer to them easily
|
||||
- show history of modifications
|
||||
|
||||
**Concurrent**
|
||||
|
||||
- get others modifications,
|
||||
- send its modifications to others,
|
||||
- know who done what and when,
|
||||
- conflicts management.
|
||||
|
||||
**Decentralized**
|
||||
|
||||
- Easily manipulate branches
|
||||
|
||||
Now let's see how to obtain all these things easily with [Git][git].
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Before usage, configuration
|
||||
|
||||
## install
|
||||
|
||||
Under Linux Ubuntu or Debian:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ sudo apt-get install git
|
||||
~~~~~~
|
||||
|
||||
Under Mac OS X:
|
||||
|
||||
* install [MacPorts](http://macports.org/install.php)
|
||||
* install [Git][git]
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ sudo port selfupdate
|
||||
|
||||
$ sudo port install git-core
|
||||
~~~~~~
|
||||
|
||||
## Global configuration
|
||||
|
||||
Save the following file as your `~/.gitconfig`.
|
||||
|
||||
~~~~~~
|
||||
[color]
|
||||
branch = auto
|
||||
diff = auto
|
||||
status = auto
|
||||
[alias]
|
||||
st = status
|
||||
co = checkout
|
||||
br = branch
|
||||
lg = log --pretty=oneline --graph
|
||||
logfull = log --pretty=fuller --graph --stat -p
|
||||
unstage = reset HEAD
|
||||
# there should be an article on what this command do
|
||||
uncommit = !zsh -c '"if (($0)); then nb=$(( $0 - 1 )); else nb=0; fi; i=0; while ((i<=nb)); do git revert -n --no-edit HEAD~$i; ((i++)); done; git commit -m \"revert to $0 version(s) back\""'
|
||||
undomerge = reset --hard ORIG_HEAD
|
||||
conflict = !gitk --left-right HEAD...MERGE_HEAD
|
||||
# under Mac OS X, you should use gitx instead
|
||||
# conflict = !gitx --left-right HEAD...MERGE_HEAD
|
||||
[branch]
|
||||
autosetupmerge = true
|
||||
~~~~~~
|
||||
|
||||
You can achieve the same result using for each entry the command: `git config --global`. Next, configure your name and your email. For example, if your name is John Doe and your email is `john.doe@email.com`. Launch the following commands:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git config --global user.name John Doe
|
||||
|
||||
$ git config --global user.email john.doe@email.com
|
||||
~~~~~~
|
||||
|
||||
Here it is. Base configuration is over. The file containing alias will help to type shorter commands.
|
||||
|
||||
## Get a project
|
||||
|
||||
If a project is already versionned with [Git][git] you should have an `URL` of the sources. Then use the following command:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cd ~/Projets
|
||||
$ git clone git://main.server/path/to/file
|
||||
~~~~~~
|
||||
|
||||
If there is no git server but you've got an `ssh` access. Just replace the `git://host` by `ssh://user@host`. In order not to type your password each time, use:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ ssh-keygen -t rsa
|
||||
~~~~~~
|
||||
|
||||
Reply to question and **do not enter** a password. Then copy your keys to the distant server. This is not the safest way to do this. The safest being, using `ssh-agent`.
|
||||
|
||||
The easiest way if you have `ssh-copy-id`:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
me@locahost$ ssh-copy-id ~/.ssh/id_rsa.pub me@main.server
|
||||
~~~~~~
|
||||
|
||||
or manually
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
me@locahost$ scp ~/.ssh/id_rsa.pub me@main.server:
|
||||
me@locahost$ ssh me@main.server
|
||||
password:
|
||||
me@main.server$ cat id_rsa.pub >> ~/.ssh/authorized_keys
|
||||
me@main.server$ rm id_rsa.pub
|
||||
me@main.server$ logout
|
||||
~~~~~~
|
||||
|
||||
Now you don't need to write your password to access the `main.server`.
|
||||
|
||||
## Creating a new project
|
||||
|
||||
Suppose you already have a project with files. Then it is really easy to version it.
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cd /path/to/project
|
||||
$ git init
|
||||
$ git add .
|
||||
$ git commit -m "Initial commit"
|
||||
~~~~~~
|
||||
|
||||
Let do a small remark. If you don't want to *version* every file. Typically intermediate compilation file, swap files... Then you need to exclude them. Just before launching the `git add .` command. You need to create a `.gitignore` file in the root directory of your project. This file will contain all exclude *pattern*. For example:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
*.o
|
||||
*.bak
|
||||
*.swp
|
||||
*~
|
||||
~~~~~~
|
||||
|
||||
Now, if you want to create a repository on a distant server, it *must* not be in `bare` mode. The repository will contain only versionning informations, but not the files of the project. To achieve that:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cd /path/to/local/project
|
||||
$ git clone --bare . ssh://server/path/to/project
|
||||
~~~~~~
|
||||
|
||||
Others will be able to get your modifications.
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
git clone ssh://server/path/to/project
|
||||
~~~~~~
|
||||
|
||||
## Abstract of the second step
|
||||
|
||||
You now have a local directory on your computer. It is versionned and you can say it is, because there is a `.git` directory at the root (and the root only) of your project. This directory contain all necessary informations for [Git][git] to version your project.
|
||||
|
||||
Now you only need to know how to use it.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Here we go!
|
||||
|
||||
Here is one from many way to use [Git][git]. This method is sufficient to work on a project. Not there is many other *workflows*.
|
||||
|
||||
## Basic usage
|
||||
|
||||
Work with [Git][git] immediately:
|
||||
|
||||
+ Get modification done by others `git pull`,
|
||||
+ See details of these modifications `git log`,
|
||||
+ Many times:
|
||||
+ *Make an atomic modification*
|
||||
+ Verify details of this modification: `git status` and `git diff`,
|
||||
+ Add some file to be versionned if necessary:<br/>`git add [file]`,
|
||||
+ Save you modifications <br/>`git commit -a -m "message"`,
|
||||
+ Send your modifications to others: `git push` (redo a `git pull` if push return an error).
|
||||
|
||||
With these few commands you can use [Git][git]. Even if it is sufficient, you need to know one more thing before really begin ; How to manage *conflicts*.
|
||||
|
||||
### Conflicts management
|
||||
|
||||
Conflicts can arise when you change the same line of code on the same file from another branch you're merging. It can seems a bit intimidating, but with [Git][git] this kind of thing is really simple to handle.
|
||||
|
||||
#### example
|
||||
|
||||
You start from the following file
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
~~~~~~ {.zsh}
|
||||
Zoot
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
and you modify one line
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
except during this time, another user had also modified the same line and had done a `push`.
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot<span class="StringConstant"><strong>, just Zoot</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Now when you do a:
|
||||
|
||||
<div>
|
||||
~~~~~~ {.zsh}
|
||||
$ git pull
|
||||
remote: Counting objects: 5, done.
|
||||
remote: Total 3 (delta 0), reused 0 (delta 0)
|
||||
Unpacking objects: 100% (3/3), done.
|
||||
From /home/yogsototh/tmp/conflictTest
|
||||
d3ea395..2dc7ffb master -> origin/master
|
||||
Auto-merging foo
|
||||
CONFLICT (content): Merge conflict in foo
|
||||
Automatic merge failed; fix conflicts and then commit the result.
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
Our file `foo` now contains:
|
||||
|
||||
<div>
|
||||
<pre class="twilight">
|
||||
<<<<<<< HEAD:foo
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
=======
|
||||
<span>Zoot<span class="StringConstant"><strong>, just Zoot</strong></span></span>
|
||||
>>>>>>> 2dc7ffb0f186a407a1814d1a62684342cd54e7d6:foo
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
#### Conflict resolution
|
||||
|
||||
To resolve the conflict you only have to edit the file for example, writing:
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the not so pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
and to commit
|
||||
|
||||
<div>
|
||||
~~~~~~ {.zsh}
|
||||
git commit -a -m "conflict resolved"
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
Now you're ready to use [Git][git].
|
||||
[Git][git] provide many other functionnalities. Now we'll see some [Git][git] usages older CVS couldn't handle.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Why Git is cool?
|
||||
|
||||
Because with [Git][git] you can work on many part of some project totally independently. This is the true efficiency of decentralisation.
|
||||
|
||||
Each branch use the same directory. Then you can easily change your branch. You can also change branch when some files are modified. You can then dispatch your work on many different branches and merge them on one master branch at will.
|
||||
|
||||
Using the `git rebase` you can decide which modifications should be forget or merged into only one modification.
|
||||
|
||||
What does it mean for real usage? You can focus on coding. For example, you can code, a fix for bug b01 and for bug b02 and code a feature f03. Once finished you can create a branch by bug and by feature. And finally you can merge these modifications on a main branch.
|
||||
|
||||
All was done to code and decide how to organize your versions after. In other VCS it is not as natural as in [Git][git].
|
||||
|
||||
With [Git][git] you can depend of many different sources. Then, there is not necessarily a 'master' repository where everybody puts its modifications.
|
||||
|
||||
What changes the most with [Git][git] when you come from SVN, it's the idea of a centralized project on one server. With [Git][git] many people could work on the same project but not necessarily on the same *repository* as main reference. One can easily fix a bug and send a patch to many different versions of a project.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Command List
|
||||
|
||||
## Command for each functionality
|
||||
|
||||
In the first part, we saw the list of resolved problem by [Git][git]. To resume [Git][git] should do:
|
||||
|
||||
- get others modifications,
|
||||
- send modifications to others,
|
||||
- get back in time,
|
||||
- list differences between each version,
|
||||
- name some versions in order to refer easily to them,
|
||||
- write an historic of modifications,
|
||||
- know who did what and when,
|
||||
- manage conflicts,
|
||||
- easily manage branches.
|
||||
|
||||
### get others modifications
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git pull
|
||||
~~~~~~
|
||||
|
||||
### send modifications to others
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git push
|
||||
~~~~~~
|
||||
|
||||
or more generally
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git pull
|
||||
$ git push
|
||||
~~~~~~
|
||||
|
||||
### get back in time
|
||||
|
||||
#### For all tree
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git checkout
|
||||
~~~~~~
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git revert
|
||||
~~~~~~
|
||||
|
||||
revert three version before (see my `.gitconfig` file).
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git uncommit 3
|
||||
~~~~~~
|
||||
|
||||
Undo the las merge (if something goes wrong)
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git revertbeforemerge
|
||||
~~~~~~
|
||||
|
||||
#### For one file
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git checkout file
|
||||
$ git checkout VersionHash file
|
||||
$ git checkout HEAD~3 file
|
||||
~~~~~~
|
||||
|
||||
### list differences between each version
|
||||
|
||||
list files being modified
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git status
|
||||
~~~~~~
|
||||
|
||||
differences between last version files and local files
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git diff
|
||||
~~~~~~
|
||||
|
||||
differences between some version and local files
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git diff VersionHash fichier
|
||||
~~~~~~
|
||||
|
||||
### name some version to refer to them in the future
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git tag 'toto'
|
||||
~~~~~~
|
||||
|
||||
### show historic of modifications
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git log
|
||||
$ git lg
|
||||
$ git logfull
|
||||
~~~~~~
|
||||
|
||||
### know who did what and when
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git blame fichier
|
||||
~~~~~~
|
||||
|
||||
### handle conflicts
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git conflict
|
||||
~~~~~~
|
||||
|
||||
### manage branches
|
||||
|
||||
To create a branch:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git branch branch_name
|
||||
~~~~~~
|
||||
|
||||
To change the current branch:
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git checkout branch_name
|
||||
~~~~~~
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
|
|||
|
|
@ -1,190 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 1
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git for n00b
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Git for what?
|
||||
tags:
|
||||
- git
|
||||
-----
|
||||
|
||||
# [Git][git] for what?
|
||||
|
||||
begindiv(intro)
|
||||
|
||||
If you just want to use [Git][git] **immediately**, just read dark part. You read this part later to understand correctly foundations of version systems and not doing strange things.
|
||||
|
||||
enddiv
|
||||
|
||||
[Git][git] is a <abbr title="Decentralized Concurent Versions System">DCVS</abbr>, which means a Decentralized Concurrent Versions System. Let's analyze each part of this long term:
|
||||
|
||||
### Versions System
|
||||
|
||||
Firstly, versions system manage files.
|
||||
When somebody work with files without a versions system, the following happens frequently:
|
||||
|
||||
When you modify a somehow critical file you don't want to loose. You copy naturally this file with another name. For example:
|
||||
|
||||
<div><code class="zsh">$ cp fichier_important.c fichier_important.c.bak</code></div>
|
||||
|
||||
In consequence of what, the new file, play the role of *backup*. If you break everything, you can always return in the last state by overwriting your modifications.
|
||||
Of course, this method is not very professional and is a bit limited. If you make many modifications, you'll end with many files with strange names like:
|
||||
|
||||
<div>
|
||||
<code class="zsh">
|
||||
fichier_important.c.bak
|
||||
fichier_important.c.old
|
||||
fichier_important.c.Bakcup
|
||||
fichier_important.c.BAK.2009-11-14
|
||||
fichier_important.c.2009.11.14
|
||||
fichier_important.c.12112009
|
||||
old.fichier_important.c
|
||||
</code>
|
||||
</div>
|
||||
|
||||
If you want to make it works correctly, you'll have to use naming convention. Files take many place even if you modify most of time only some lines.
|
||||
|
||||
*Fortunately, versions system are here to help.*
|
||||
|
||||
You only have to signal you want a new version of a file and the versions system will do the job for you. It will record the backup where it could be easily recovered. Generally, systems version do it better than you, making the backup only of the modified lines and not the total file.
|
||||
|
||||
Once upon a time versions were managed for each file separately. I think about CVS. Then it naturally appears projects are a coherent set of files. Recover each file separately was a tedious work. This is why versions number passed from files to the entire project.
|
||||
|
||||
It is therefore possible to say, "I want to get back three days earlier".
|
||||
|
||||
begindiv(black)
|
||||
|
||||
*What gives versions system?* (I didn't mention everything at all)
|
||||
|
||||
- automatic backups: *back in time*,
|
||||
- gives the ability to see differences between each version,
|
||||
- put a *tag* on some version to be able to refer to them easily,
|
||||
- gives the ability to see an historic of all modifications. Generally the user must add a comment for each new version.
|
||||
|
||||
enddiv
|
||||
|
||||
### concurrent:
|
||||
|
||||
Version Systems are already useful to manage its own projects. They help to organize and resolve partially backup problems. I say partially because you have to backup your repository on a decent file system. But versions system are really interesting is on projects done by many people.
|
||||
|
||||
Let's begin by an example, a two person project ; Alex and Beatrice. On a file containing a *Lovecraft*'s gods list:
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<code class="zsh">
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
</code></div>
|
||||
|
||||
Say Alex is home and modify the file:
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
after that he send the file on the project server. Then on the server there is the Alex file:
|
||||
|
||||
A bit later, Beatrice who had not get the Alex file on the server make the modification:
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Beatrice send her file on the server
|
||||
|
||||
Alex modification is *lost*. One more time, versions system are here to help.
|
||||
|
||||
A version system would had *merge* the two files at the time Beatrice send the file on the server. And like by magic, on the server the file would be:
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
In real life, at the moment Beatrice want to send her modifications, the versions system alert her a modification had occurred on the server. Then she uses a command which pull the modification from the server to her local computer. And this command update her file. After that, Beatrice send again the new file on the server.
|
||||
|
||||
begindiv(black)
|
||||
|
||||
**In what Concurrent Versions System help?**
|
||||
|
||||
- get without any problem others modifications,
|
||||
- send without any problem its own modifications to others,
|
||||
- manage conflicts. I didn't speak about it, but sometimes a conflict can occur (when two different people modify the same line on a file for example). SVC help to resolve such problem. More on that later,
|
||||
- help to know who done what and when.
|
||||
|
||||
enddiv
|
||||
|
||||
### decentralized
|
||||
|
||||
This word became popular only recently about CVS. And it mainly means two things:
|
||||
|
||||
First, until really recently (SVN), you'll have to be connected to the distant server to get informations about a project. Like get the history. New decentralized systems work with a local *REPOSITORY* (directory containing backups and many informations linked to the versions system functionalities). Hence, one can view the history of a project without the need of being connected.
|
||||
|
||||
All instances of a project can live *independently*.
|
||||
|
||||
To be more precise, DCVS are base on the *branch* notion.
|
||||
|
||||
Practically, it has great importance. It means, everybody work separately, and the system help to glue all their work.
|
||||
|
||||
It is even more than just that. It help to code independently each feature and bug fixes. Under other system it was far more difficult.
|
||||
|
||||
Typical example:
|
||||
|
||||
> I develop my project. I'm ameliorating something. An urgent bug is reported.
|
||||
>
|
||||
> With a DCVS I can easily, get back to the version with the bug. Fix it. Send the fix. Get back to my feature work. And even, use the fix for the new version with my new feature.
|
||||
>
|
||||
> In a not decentralized version system, doing such a thing is possible but not natural. Decentralization means it become natural to use a branch for each separable work.
|
||||
|
||||
begindiv(black)
|
||||
|
||||
**Advantages given by DCVS: **
|
||||
|
||||
- Ability to work offline,
|
||||
- Ability to create many *atomic* patches,
|
||||
- Help the maintenance of many different versions of the same application.
|
||||
|
||||
enddiv
|
||||
|
||||
## To resume
|
||||
|
||||
Let's resume what we can easily do with DCVS:
|
||||
|
||||
**Versions Systems**
|
||||
|
||||
- back in time,
|
||||
- list differences between versions,
|
||||
- name some versions to refer to them easily
|
||||
- show history of modifications
|
||||
|
||||
**Concurrent**
|
||||
|
||||
- get others modifications,
|
||||
- send its modifications to others,
|
||||
- know who done what and when,
|
||||
- conflicts management.
|
||||
|
||||
**Decentralized**
|
||||
|
||||
- Easily manipulate branches
|
||||
|
||||
Now let's see how to obtain all these things easily with [Git][git].
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,113 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 3
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git for n00b
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: The Adventure Begins
|
||||
tags:
|
||||
- git
|
||||
|
||||
-----
|
||||
|
||||
# Here we go!
|
||||
|
||||
Here is one from many way to use [Git][git]. This method is sufficient to work on a project. Not there is many other *workflows*.
|
||||
|
||||
## Basic usage
|
||||
|
||||
Work with [Git][git] immediately:
|
||||
|
||||
+ Get modification done by others `git pull`,
|
||||
+ See details of these modifications `git log`,
|
||||
+ Many times:
|
||||
+ *Make an atomic modification*
|
||||
+ Verify details of this modification: `git status` and `git diff`,
|
||||
+ Add some file to be versionned if necessary:<br/>`git add [file]`,
|
||||
+ Save you modifications <br/>`git commit -a -m "message"`,
|
||||
+ Send your modifications to others: `git push` (redo a `git pull` if push return an error).
|
||||
|
||||
With these few commands you can use [Git][git]. Even if it is sufficient, you need to know one more thing before really begin ; How to manage *conflicts*.
|
||||
|
||||
### Conflicts management
|
||||
|
||||
Conflicts can arise when you change the same line of code on the same file from another branch you're merging. It can seems a bit intimidating, but with [Git][git] this kind of thing is really simple to handle.
|
||||
|
||||
#### example
|
||||
|
||||
You start from the following file
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<code class="zsh">
|
||||
Zoot
|
||||
</code>
|
||||
</div>
|
||||
|
||||
and you modify one line
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
except during this time, another user had also modified the same line and had done a `push`.
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot<span class="StringConstant"><strong>, just Zoot</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Now when you do a:
|
||||
|
||||
<div>
|
||||
<code class="zsh">
|
||||
$ git pull
|
||||
remote: Counting objects: 5, done.
|
||||
remote: Total 3 (delta 0), reused 0 (delta 0)
|
||||
Unpacking objects: 100% (3/3), done.
|
||||
From /home/yogsototh/tmp/conflictTest
|
||||
d3ea395..2dc7ffb master -> origin/master
|
||||
Auto-merging foo
|
||||
CONFLICT (content): Merge conflict in foo
|
||||
Automatic merge failed; fix conflicts and then commit the result.
|
||||
</code>
|
||||
</div>
|
||||
|
||||
Our file `foo` now contains:
|
||||
|
||||
<div>
|
||||
<pre class="twilight">
|
||||
<<<<<<< HEAD:foo
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
=======
|
||||
<span>Zoot<span class="StringConstant"><strong>, just Zoot</strong></span></span>
|
||||
>>>>>>> 2dc7ffb0f186a407a1814d1a62684342cd54e7d6:foo
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
#### Conflict resolution
|
||||
|
||||
To resolve the conflict you only have to edit the file for example, writing:
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the not so pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
and to commit
|
||||
|
||||
<div>
|
||||
<code class="zsh">
|
||||
git commit -a -m "conflict resolved"
|
||||
</code>
|
||||
</div>
|
||||
|
||||
Now you're ready to use [Git][git].
|
||||
[Git][git] provide many other functionnalities. Now we'll see some [Git][git] usages older CVS couldn't handle.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,142 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 30
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git for n00b
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Command List
|
||||
tags:
|
||||
- git
|
||||
|
||||
-----
|
||||
|
||||
# Command List
|
||||
|
||||
## Command for each functionality
|
||||
|
||||
In the first part, we saw the list of resolved problem by [Git][git]. To resume [Git][git] should do:
|
||||
|
||||
- get others modifications,
|
||||
- send modifications to others,
|
||||
- get back in time,
|
||||
- list differences between each version,
|
||||
- name some versions in order to refer easily to them,
|
||||
- write an historic of modifications,
|
||||
- know who did what and when,
|
||||
- manage conflicts,
|
||||
- easily manage branches.
|
||||
|
||||
### get others modifications
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git pull
|
||||
</code></div>
|
||||
|
||||
### send modifications to others
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git push
|
||||
</code></div>
|
||||
|
||||
or more generally
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git pull
|
||||
$ git push
|
||||
</code></div>
|
||||
|
||||
### get back in time
|
||||
|
||||
#### For all tree
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git checkout
|
||||
</code></div>
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git revert
|
||||
</code></div>
|
||||
|
||||
revert three version before (see my `.gitconfig` file).
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git uncommit 3
|
||||
</code></div>
|
||||
|
||||
Undo the las merge (if something goes wrong)
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git revertbeforemerge
|
||||
</code></div>
|
||||
|
||||
#### For one file
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git checkout file
|
||||
$ git checkout VersionHash file
|
||||
$ git checkout HEAD~3 file
|
||||
</code></div>
|
||||
|
||||
### list differences between each version
|
||||
|
||||
list files being modified
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git status
|
||||
</code></div>
|
||||
|
||||
differences between last version files and local files
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git diff
|
||||
</code></div>
|
||||
|
||||
differences between some version and local files
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git diff VersionHash fichier
|
||||
</code></div>
|
||||
|
||||
### name some version to refer to them in the future
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git tag 'toto'
|
||||
</code></div>
|
||||
|
||||
### show historic of modifications
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git log
|
||||
$ git lg
|
||||
$ git logfull
|
||||
</code></div>
|
||||
|
||||
### know who did what and when
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git blame fichier
|
||||
</code></div>
|
||||
|
||||
### handle conflicts
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git conflict
|
||||
</code></div>
|
||||
|
||||
### manage branches
|
||||
|
||||
To create a branch:
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git branch branch_name
|
||||
</code></div>
|
||||
|
||||
To change the current branch:
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git checkout branch_name
|
||||
</code></div>
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 10
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git for n00b
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Understanding
|
||||
tags:
|
||||
- git
|
||||
|
||||
-----
|
||||
|
||||
# Why Git is cool?
|
||||
|
||||
Because with [Git][git] you can work on many part of some project totally independently. This is the true efficiency of decentralisation.
|
||||
|
||||
Each branch use the same directory. Then you can easily change your branch. You can also change branch when some files are modified. You can then dispatch your work on many different branches and merge them on one master branch at will.
|
||||
|
||||
Using the `git rebase` you can decide which modifications should be forget or merged into only one modification.
|
||||
|
||||
What does it mean for real usage? You can focus on coding. For example, you can code, a fix for bug b01 and for bug b02 and code a feature f03. Once finished you can create a branch by bug and by feature. And finally you can merge these modifications on a main branch.
|
||||
|
||||
All was done to code and decide how to organize your versions after. In other VCS it is not as natural as in [Git][git].
|
||||
|
||||
With [Git][git] you can depend of many different sources. Then, there is not necessarily a 'master' repository where everybody puts its modifications.
|
||||
|
||||
What changes the most with [Git][git] when you come from SVN, it's the idea of a centralized project on one server. With [Git][git] many people could work on the same project but not necessarily on the same *repository* as main reference. One can easily fix a bug and send a patch to many different versions of a project.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,143 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 2
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git for n00b
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Configure before Use
|
||||
tags:
|
||||
- git
|
||||
-----
|
||||
|
||||
# Before usage, configuration
|
||||
|
||||
## install
|
||||
|
||||
Under Linux Ubuntu or Debian:
|
||||
|
||||
<div><code class="zsh">$ sudo apt-get install git</code></div>
|
||||
|
||||
Under Mac OS X:
|
||||
|
||||
* install [MacPorts](http://macports.org/install.php)
|
||||
* install [Git][git]
|
||||
|
||||
<div><code class="zsh">
|
||||
$ sudo port selfupdate
|
||||
|
||||
$ sudo port install git-core
|
||||
</code></div>
|
||||
|
||||
## Global configuration
|
||||
|
||||
Save the following file as your `~/.gitconfig`.
|
||||
|
||||
<div><code class="zsh" file="gitconfig">
|
||||
[color]
|
||||
branch = auto
|
||||
diff = auto
|
||||
status = auto
|
||||
[alias]
|
||||
st = status
|
||||
co = checkout
|
||||
br = branch
|
||||
lg = log --pretty=oneline --graph
|
||||
logfull = log --pretty=fuller --graph --stat -p
|
||||
unstage = reset HEAD
|
||||
# there should be an article on what this command do
|
||||
uncommit = !zsh -c '"if (($0)); then nb=$(( $0 - 1 )); else nb=0; fi; i=0; while ((i<=nb)); do git revert -n --no-edit HEAD~$i; ((i++)); done; git commit -m \"revert to $0 version(s) back\""'
|
||||
undomerge = reset --hard ORIG_HEAD
|
||||
conflict = !gitk --left-right HEAD...MERGE_HEAD
|
||||
# under Mac OS X, you should use gitx instead
|
||||
# conflict = !gitx --left-right HEAD...MERGE_HEAD
|
||||
[branch]
|
||||
autosetupmerge = true
|
||||
</code></div>
|
||||
|
||||
You can achieve the same result using for each entry the command: `git config --global`. Next, configure your name and your email. For example, if your name is John Doe and your email is `john.doe@email.com`. Launch the following commands:
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git config --global user.name John Doe
|
||||
|
||||
$ git config --global user.email john.doe@email.com
|
||||
</code></div>
|
||||
|
||||
Here it is. Base configuration is over. The file containing alias will help to type shorter commands.
|
||||
|
||||
## Get a project
|
||||
|
||||
If a project is already versionned with [Git][git] you should have an `URL` of the sources. Then use the following command:
|
||||
|
||||
<div><code class="zsh">
|
||||
$ cd ~/Projets
|
||||
$ git clone git://main.server/path/to/file
|
||||
</code></div>
|
||||
|
||||
If there is no git server but you've got an `ssh` access. Just replace the `git://host` by `ssh://user@host`. In order not to type your password each time, use:
|
||||
|
||||
<div><code class="zsh">
|
||||
$ ssh-keygen -t rsa
|
||||
</code></div>
|
||||
|
||||
Reply to question and **do not enter* a password. Then copy your keys to the distant server. This is not the safest way to do this. The safest being, using `ssh-agent`.
|
||||
|
||||
The easiest way if you have `ssh-copy-id`:
|
||||
<div><code class="zsh">
|
||||
me@locahost$ ssh-copy-id ~/.ssh/id_rsa.pub me@main.server
|
||||
</code></div>
|
||||
|
||||
or manually
|
||||
|
||||
<div><code class="zsh">
|
||||
me@locahost$ scp ~/.ssh/id_rsa.pub me@main.server:
|
||||
me@locahost$ ssh me@main.server
|
||||
password:
|
||||
me@main.server$ cat id_rsa.pub >> ~/.ssh/authorized_keys
|
||||
me@main.server$ rm id_rsa.pub
|
||||
me@main.server$ logout
|
||||
</code></div>
|
||||
|
||||
Now you don't need to write your password to access the `main.server`.
|
||||
|
||||
## Creating a new project
|
||||
|
||||
Suppose you already have a project with files. Then it is really easy to version it.
|
||||
|
||||
<div><code class="zsh">
|
||||
$ cd /path/to/project
|
||||
$ git init
|
||||
$ git add .
|
||||
$ git commit -m "Initial commit"
|
||||
</code></div>
|
||||
|
||||
Let do a small remark. If you don't want to *version* every file. Typically intermediate compilation file, swap files... Then you need to exclude them. Just before launching the `git add .` command. You need to create a `.gitignore` file in the root directory of your project. This file will contain all exclude *pattern*. For example:
|
||||
|
||||
<div><code class="zsh">
|
||||
*.o
|
||||
*.bak
|
||||
*.swp
|
||||
*~
|
||||
</code></div>
|
||||
|
||||
Now, if you want to create a repository on a distant server, it *must* not be in `bare` mode. The repository will contain only versionning informations, but not the files of the project. To achieve that:
|
||||
|
||||
<div><code class="zsh">
|
||||
$ cd /path/to/local/project
|
||||
$ git clone --bare . ssh://server/path/to/project
|
||||
</code></div>
|
||||
|
||||
Others will be able to get your modifications.
|
||||
|
||||
<div><code class="zsh">
|
||||
git clone ssh://server/path/to/project
|
||||
</code></div>
|
||||
|
||||
## Abstract of the second step
|
||||
|
||||
You now have a local directory on your computer. It is versionned and you can say it is, because there is a `.git` directory at the root (and the root only) of your project. This directory contain all necessary informations for [Git][git] to version your project.
|
||||
|
||||
Now you only need to know how to use it.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,7 +1,8 @@
|
|||
-----
|
||||
kind: article
|
||||
image: /Scratch/img/blog/03_losthighway/intro.jpg
|
||||
menupriority: 1
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
created_at: 2009-08-04T12:00:00+02:00
|
||||
title: Lost Highway démystifié (un peu)
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
|
|
@ -11,7 +12,6 @@ tags:
|
|||
- David Lynch
|
||||
- Lost Highway
|
||||
- Réalité alternée
|
||||
|
||||
-----
|
||||
|
||||
blogimage("intro.jpg","Lost Highway")
|
||||
|
|
@ -43,7 +43,6 @@ Il faut garder à l'esprit qu'il n'existe pas une seule interprétation possible
|
|||
Je donne quelques clés aidant à suivre le film **sans être complètement perdu**.
|
||||
Ces clés devraient vous aider à vous faire votre propre idée du film.
|
||||
|
||||
|
||||
## Le test de Rorschach
|
||||
|
||||
leftblogimage("rorschach.gif","test de Rorschach")
|
||||
|
|
@ -60,3 +59,104 @@ Je donne une **interprétation** et non pas une **explication**. Ma vision des c
|
|||
Il y a certainement beaucoup d'autres explications qui restent cohérentes.
|
||||
|
||||
J'écris cet article, parce que j'ai l'impression d'en avoir trouver une qui marche pour plus de 97% du film (peut-être 100%, mais j'en doute, il faudrait que je le revois encore une fois).
|
||||
|
||||
# Les clefs du films
|
||||
|
||||
<div class="encadre" style="text-align: center">
|
||||
<strong>
|
||||
Tout se passe dans la mémoire de Fred
|
||||
</strong>
|
||||
</div>
|
||||
|
||||
Tout d'abord, il est clair que comprendre le film comme simplement un film fantastique ne fonctionne pas. En suivant ce point d'entrée on en fini pas de se heurter à des détails incompréhensibles.
|
||||
|
||||
Mon *hypothèse de départ* c'est que le film dépeint la représentation de la réalité que s'en fait Fred.
|
||||
Chaque fois qu'il essaye d'échapper à la réalité, celle-ci finira par le rattraper.
|
||||
|
||||
Fred a commis un acte horrible, un meurtre, et essaye de *réparer* sa mémoire pour accepter son acte. Il va alors s'inventer des *réalitées alternatives*.
|
||||
|
||||
- Dans un premier temps il tue sa femme (Renée) parce qu'elle le trompe.
|
||||
- Dans la deuxième partie, il est plus faible. La version blonde de Renée va le manipuler pour tuer Dick Laurent.
|
||||
- Dans la troisième partie il tue Dick Laurent
|
||||
|
||||
## Quelle est la validité de ce choix ?
|
||||
|
||||
Cette interprétation me semble valide à cause du dialogue au début du film avec les policiers qui demandent au protagoniste s'il a une caméra :
|
||||
|
||||
> "Do you own a video camera?"
|
||||
> "No, Fred hates them."
|
||||
> "I like to remember things my own way."
|
||||
> "What do you mean by that?"
|
||||
> "How I remember them, not necessarily the way they happened."
|
||||
|
||||
Ce que l'on peut traduire approximativement par :
|
||||
|
||||
> – Avez-vous une caméra ?
|
||||
> – Non, Fred les détestes.
|
||||
> – J'aime me rappeler les choses à ma façon.
|
||||
> – Qu'entendez-vous par là ?
|
||||
> – Je me rappelle des choses pas nécessairement comme elles se sont passées.
|
||||
|
||||
Ainsi, ce que l'on voit n'est pas la réalité, mais la réalité telle que le conçoit Fred. Il est donc le Dieu de cette réalité. Ainsi les interprétations mystiques faisant intervenir le Diable ont une certaine validité.
|
||||
|
||||
## Qui est l'homme mystérieux ?
|
||||
|
||||
leftblogimage( "mysteryman.jpg" , "l'homme mystérieux" )
|
||||
|
||||
Qui est donc ce personnage étrange et inquiétant ?
|
||||
Un être capable d'ubiquité qui dit être invité par Fred dans sa maison ?
|
||||
Sans sourcils, le visage blême, les yeux écarquillés fixant sans relâche les faits et gestes de Fred.
|
||||
|
||||
C'est certainement une des clés du film.
|
||||
À mon avis, il représente la partie *mauvaise* de Fred.
|
||||
Certainement la jalousie. Si j'étais Catholique je dirai Satan, le tentateur.
|
||||
Il n'agit jamais, mais ne fait qu'observer et filmer.
|
||||
Par contre c'est lui qui donne les armes à Fred pour tuer Dick Laurent.
|
||||
Fred l'a laissé entrer chez lui et il ne peut plus s'en débarrasser.
|
||||
Un peu comme le _Iago_ de Shakespeare est enfermé dans sa jalousie.
|
||||
Le personnage mystérieux prend toute l'importance, il le ronge de l'intérieur.
|
||||
Il aide Fred à accomplir les actes de violences et aussi l'oblige à se souvenir de la réalité.
|
||||
|
||||
Quand il fait l'amour à Renée il voit le visage de l'homme mystérieux à la place du visage de sa femme. En réalité, il s'agit de la même personne d'après Fred. Ce serait donc elle qui est la source de son mal intérieur.
|
||||
|
||||
|
||||
## Qui filme et dépose les cassettes ?
|
||||
|
||||
C'est certainement l'homme mystérieux (ou Fred lui-même) qui est à l'origine de ces cassettes.
|
||||
Le rôle des cassettes est double :
|
||||
|
||||
+ Rappeler à Fred la réalité. D'après Fred les cassettes video correspondent à la réalité. Il a beau essayer de se cacher la réalité, les cassettes finissent par aller jusqu'au bout et il se voit en train de tuer Renée.
|
||||
+ La cassette peut aussi faire référence aux cassettes de films pornographique dans laquelle Renée a peut-être tournée dans la réalité ?
|
||||
|
||||
## Que s'est-il vraiment passé ?
|
||||
|
||||
Ici, tout n'est pas donné, on garde une assez grande liberté. Mais on a des indices.
|
||||
|
||||
### Hypothese n°1
|
||||
|
||||
Je dirais que le protagoniste est un garagiste qui est tombé amoureux d'une actrice porno. Il l'a certainement vu la première fois accompagnant le fameux Dick Laurent. Voyant qu'il ne peut pas l'avoir pour lui, fou de jalousie il tue Dick Laurent dans un motel où celui-ci à couché avec Renée.
|
||||
|
||||
On a la liberté de décider s'il a vraiment tué la femme ou pas.
|
||||
Dans ma première vision du film, j'avais envie de dire qu'il ne la tue pas. Mais qu'une fois le meurtre commis, il va chez elle, sonne pour lui annoncer la mort de Dick Laurent. Il a alors juste le temps de s'enfuir, la police à ses trousses.
|
||||
|
||||
### Hypothese n°2
|
||||
|
||||
La première partie resemble à la réalité. Il a vraiment tué sa femme. Il se fait arrété et condamné (certainement à mort). Par contre on ne sait pas s'il est aussi allé tuer Andy.
|
||||
|
||||
## alors c'est laquelle ?
|
||||
|
||||
La seconde hypothèse me semble plus vraisemblable, car il y a plus de recoupements possibles.
|
||||
La première me semble aussi cohérente. C'est cette première hypothèse que j'avais émise lors de mon premier visionnage du film.
|
||||
|
||||
Ce qui montre la force de ce film c'est de se dire qu'il y a de nombreuses autres hypothèses qui pourraient aussi bien fonctionner. C'est le fameux [effet Rashomon](http://en.wikipedia.org/wiki/Rashomon_effect). Plusieurs personnes peuvent décrire de façon cohérentes ce qu'elles ont vu, mais toutes les descriptions sont incohérentes entres-elles.
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
Il y aurait encore beaucoup à dire sur l'analyse de ce film. Mais il me semble que j'ai rassemblé l'essentiel des clés pour sa compréhension.
|
||||
|
||||
Il me semble qu'avoir à l'esprit l'effet "test de Rorschach" est essentiel lors de la visualisation de ce film.
|
||||
|
||||
J'aimerai avoir votre opinion ; mon interprétation tient-elle la route ?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,66 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 1
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: Lost Highway démystifié (un peu)
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Les clefs du film
|
||||
tags:
|
||||
- film
|
||||
- David Lynch
|
||||
- Lost Highway
|
||||
- Réalité alternée
|
||||
|
||||
-----
|
||||
|
||||
# Les clefs du films
|
||||
|
||||
<div class="encadre" style="text-align: center">
|
||||
<strong>
|
||||
Tout se passe dans la mémoire de Fred
|
||||
</strong>
|
||||
</div>
|
||||
|
||||
|
||||
Tout d'abord, il est clair que comprendre le film comme simplement un film fantastique ne fonctionne pas. En suivant ce point d'entrée on en fini pas de se heurter à des détails incompréhensibles.
|
||||
|
||||
|
||||
|
||||
|
||||
Mon *hypothèse de départ* c'est que le film dépeint la représentation de la réalité que s'en fait Fred.
|
||||
Chaque fois qu'il essaye d'échapper à la réalité, celle-ci finira par le rattraper.
|
||||
|
||||
|
||||
|
||||
|
||||
Fred a commis un acte horrible, un meurtre, et essaye de *réparer* sa mémoire pour accepter son acte. Il va alors s'inventer des *réalitées alternatives*.
|
||||
|
||||
|
||||
|
||||
- Dans un premier temps il tue sa femme (Renée) parce qu'elle le trompe.
|
||||
- Dans la deuxième partie, il est plus faible. La version blonde de Renée va le manipuler pour tuer Dick Laurent.
|
||||
- Dans la troisième partie il tue Dick Laurent
|
||||
|
||||
## Quelle est la validité de ce choix ?
|
||||
|
||||
|
||||
Cet interprétation me semble valide à cause du dialogue au début du film avec les policier qui demande au protagoniste s'il a une caméra :
|
||||
|
||||
|
||||
|
||||
> "Do you own a video camera?"
|
||||
> "No, Fred hates them."
|
||||
> "I like to remember things my own way."
|
||||
> "What do you mean by that?"
|
||||
> "How I remember them, not necessarily the way they happened."
|
||||
|
||||
Ce que l'on peut traduire approximativement par :
|
||||
|
||||
> – Avez-vous une caméra ?
|
||||
> – Non, Fred les détestes.
|
||||
> – J'aime me rappeler les choses à ma façon.
|
||||
> – Qu'entendez-vous par là ?
|
||||
> – Je me rapelle des choses pas nécessairement comme elles se sont passées.
|
||||
|
||||
Ainsi, ce que l'on voit n'est pas la réalité, mais la réalité telle que le conçoit Fred. Il est donc le Dieu de cette réalité. Ainsi les interprétations mystiques faisant intervenir le Diable ont une certaine validité.
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 2
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: Lost Highway démystifié (un peu)
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Qui est l'homme mystérieux ?
|
||||
tags:
|
||||
- film
|
||||
- David Lynch
|
||||
- Lost Highway
|
||||
- Réalité alternée
|
||||
|
||||
-----
|
||||
|
||||
## Qui est l'homme mystérieux ?
|
||||
|
||||
leftblogimage( "mysteryman.jpg" , "l'homme mystérieux" )
|
||||
|
||||
Qui est donc ce personnage étrange et inquiétant ?
|
||||
Un être capable d'ubiquité qui dit être invité par Fred dans sa maison ?
|
||||
Sans sourcils, le visage blême, les yeux écarquillés fixant sans relâche les faits et gestes de Fred.
|
||||
|
||||
|
||||
|
||||
C'est certainement une des clés du film.
|
||||
À mon avis, il représente la partie *mauvaise* de Fred.
|
||||
Certainement la jalousie. Si j'étais Catholique je dirai Satan, le tentateur.
|
||||
Il n'agit jamais, mais ne fait qu'observer et filmer.
|
||||
Par contre c'est lui qui donne les armes à Fred pour tuer Dick Laurent.
|
||||
Fred l'a laissé entrer chez lui et il ne peut plus s'en débarrasser.
|
||||
Un peu comme le _Iago_ de Shakespeare est enfermé dans sa jalousie.
|
||||
Le personnage mystérieux prend toute l'importance, il le ronge de l'intérieur.
|
||||
Il aide Fred à accomplir les actes de violences et aussi l'oblige à se souvenir de la réalité.
|
||||
|
||||
|
||||
|
||||
|
||||
Quand il fait l'amour à Renée il voit le visage de l'homme mystérieux à la place du visage de sa femme. En réalité, il s'agit de la même personne d'après Fred. Ce serait donc elle qui est la source de son mal intérieur.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 3
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: Lost Highway démystifié (un peu)
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Qui filme et dépose les cassettes ?
|
||||
tags:
|
||||
- film
|
||||
- David Lynch
|
||||
- Lost Highway
|
||||
- Réalité alternée
|
||||
|
||||
-----
|
||||
|
||||
## Qui filme et dépose les cassettes ?
|
||||
|
||||
|
||||
|
||||
C'est certainement l'homme mystérieux (ou Fred lui-même) qui est à l'origine de ces cassettes.
|
||||
Le rôle des cassettes est double :
|
||||
|
||||
|
||||
+ Rappeler à Fred la réalité. D'après Fred les cassettes video correspondent à la réalité. Il a beau essayer de se cacher la réalité, les cassettes finissent par aller jusqu'au bout et il se voit en train de tuer Renée.
|
||||
+ La cassette peut aussi faire référence aux cassettes de films pornographique dans laquelle Renée a peut-être tournée dans la réalité ?
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
-----
|
||||
kind: article
|
||||
menupriority: 4
|
||||
created_at: 2009-08-04T19:00:00+02:00
|
||||
title: Lost Highway démystifié (un peu)
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Que s'est-il vraiment passé ?
|
||||
tags:
|
||||
- film
|
||||
- David Lynch
|
||||
- Lost Highway
|
||||
- Réalité alternée
|
||||
|
||||
-----
|
||||
|
||||
## Que s'est-il vraiment passé ?
|
||||
|
||||
|
||||
Ici, tout n'est pas donné, on garde une assez grande liberté. Mais on a des indices.
|
||||
|
||||
|
||||
|
||||
### Hypothese n°1
|
||||
|
||||
Je dirais que le protagoniste est un garagiste qui est tombé amoureux d'une actrice porno. Il l'a certainement vu la première fois accompagnant le fameux Dick Laurent. Voyant qu'il ne peut pas l'avoir pour lui, fou de jalousie il tue Dick Laurent dans un motel où celui-ci à couché avec Renée.
|
||||
|
||||
On a la liberté de décider s'il a vraiment tué la femme ou pas.
|
||||
Dans ma première vision du film, j'avais envie de dire qu'il ne la tue pas. Mais qu'une fois le meurtre commis, il va chez elle, sonne pour lui annoncer la mort de Dick Laurent. Il a alors juste le temps de s'enfuir, la police à ses trousses.
|
||||
|
||||
|
||||
### Hypothese n°2
|
||||
|
||||
La première partie resemble à la réalité. Il a vraiment tué sa femme. Il se fait arrété et condamné (certainement à mort). Par contre on ne sait pas s'il est aussi allé tuer Andy.
|
||||
|
||||
## alors c'est laquelle ?
|
||||
|
||||
La seconde hypothèse me semble plus vraisemblable, car il y a plus de recoupements possibles.
|
||||
La première me semble aussi cohérente. C'est cette première hypothèse que j'avais émise lors de mon premier visionnage du film.
|
||||
|
||||
Ce qui montre la force de ce film c'est de se dire qu'il y a de nombreuses autres hypothèses qui pourraient aussi bien fonctionner. C'est le fameux [effet Rashomon](http://en.wikipedia.org/wiki/Rashomon_effect). Plusieurs personnes peuvent décrire de façon cohérentes ce qu'elles ont vu, mais toutes les descriptions sont incohérentes entres-elles.
|
||||
|
||||
newcorps
|
||||
|
||||
## Conclusion
|
||||
|
||||
Il y aurait encore beaucoup à dire sur l'analyse de ce film. Mais il me semble que j'ai rassemblé l'essentiel des clés pour sa compréhension.
|
||||
|
||||
Il me semble qu'avoir à l'esprit l'effet "test de Rorschach" est essentiel lors de la visualisation de ce film.
|
||||
|
||||
J'aimerai avoir votre opinion ; mon interprétation tient-elle la route ?
|
||||
|
||||
|
|
@ -1,24 +1,23 @@
|
|||
-----
|
||||
-----
|
||||
isHidden: false
|
||||
menupriority: 1
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
created_at: 2009-11-12T12:00:00+02:00
|
||||
title: Git pour les nuls
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: la conclusion pour commencer
|
||||
tags:
|
||||
- git
|
||||
|
||||
-----
|
||||
|
||||
begindiv(intro)
|
||||
<div class="intro">
|
||||
|
||||
Voici un tutoriel <a href="http://git-scm.org">Git</a> détaillé pour ceux qui en connaissent très peu sur les systèmes de versions. Vous comprendrez l'utilité de tels systèmes et surtout comment on se sert des systèmes de versions modernes, le tout en restant le plus pragmatique possible.
|
||||
|
||||
enddiv
|
||||
</div>
|
||||
|
||||
newcorps
|
||||
---
|
||||
|
||||
# Pour commencer, la conclusion
|
||||
|
||||
|
|
@ -26,13 +25,13 @@ Voici la liste des commandes nécessaires et suffisantes pour utiliser [Git][git
|
|||
|
||||
Récupérer un projet :
|
||||
|
||||
<div><code class="zsh">
|
||||
~~~~~~ {.zsh}
|
||||
git clone ssh://server/path/to/project
|
||||
</code></div>
|
||||
~~~~~~
|
||||
|
||||
Utiliser [Git][git] tous les jours :
|
||||
|
||||
<div><code class="zsh">
|
||||
~~~~~~ {.zsh}
|
||||
# get modifications from other
|
||||
git pull
|
||||
# read what was done
|
||||
|
|
@ -54,8 +53,569 @@ git commit -a -m "Fix bug #321"
|
|||
|
||||
# send local modifications to other
|
||||
git push
|
||||
</code></div>
|
||||
~~~~~~
|
||||
|
||||
Cet article est écrit pour ceux qui en savent très peu sur les systèmes de version. Il est aussi écrit pour ceux qui n'ont pas suivi les progrès accomplis depuis CVS ou subversion (SVN). C’est pourquoi, dans un premier temps, j’explique rapidement quels sont les buts poursuivis par les systèmes de versions. J'explique ensuite comment installer et configurer [Git][git]. Puis, pour chaque action que doivent accomplir les <abbr title="Decentralized Concurent Versions System">DCVS</abbr> je donne les commandes [Git][git] qui y correspondent.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# [Git][git] pour quoi faire ?
|
||||
|
||||
<div class="intro">
|
||||
|
||||
Si tout ce qui vous intéresse c'est d'utiliser [Git][git] **tout de suite**. Lisez simplement les parties sur fond noir. Je vous conseille aussi de revenir relire tout ça un peu plus tard, pour mieux comprendre les fondements des systèmes de versions et ne pas faire de bêtises quand vous les utilisez.
|
||||
|
||||
</div>
|
||||
|
||||
[Git][git] est un <abbr title="Decentralized Concurent Versions System">DCVS</abbr>, c'est-à-dire un système de versions concurrentes décentralisé. Analysons chaque partie de cette appellation compliquée.
|
||||
|
||||
### Système de versions
|
||||
|
||||
Tout d'abord, les systèmes de versions gèrent des fichiers.
|
||||
Quand on travaille avec des fichiers sans système de version voilà ce qui arrive souvent :
|
||||
|
||||
Lorsqu'on modifie un fichier un peu critique et qu'on a pas envie de perdre, on se retrouve souvent à le recopier sous un autre nom. Par exemple
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cp fichier_important.c fichier_important.c.bak
|
||||
~~~~~~
|
||||
|
||||
Du coups, ce nouveau fichier joue le rôle de *backup*. Si on casse tout, on peut toujours écraser les modifications que nous avons faites. Évidemment le problème avec cette façon de faire c'est que ce n'est pas très professionnel. Et puis c'est un peu limité. Si on veut faire trois ou quatre modifications on se retrouve avec plein de fichiers. Parfois avec des nom bizarres comme :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
fichier_important.c.bak
|
||||
fichier_important.c.old
|
||||
fichier_important.c.Bakcup
|
||||
fichier_important.c.BAK.2009-11-14
|
||||
fichier_important.c.2009.11.14
|
||||
fichier_important.c.12112009
|
||||
old.fichier_important.c
|
||||
~~~~~~
|
||||
|
||||
Bon alors si on veut que ça marche il faut se fixer des conventions de nommage. Les fichiers prennent beaucoup de place alors que souvent il n'y a que quelques lignes différentes entre le fichier et son backup...
|
||||
|
||||
*Heureusement les systèmes de version viennent à la rescousse.*
|
||||
|
||||
Il suffit de signaler que l'on va faire une nouvelle version d'un fichier et le système de version se débrouille pour l'enregistrer quelque part où on pourra facilement le retrouver. Et en général, le système de version fait les choses bien. C'est-à-dire qu'il n'utilise que très peu d'espace disque pour faire ces backups.
|
||||
|
||||
Il fut un temps où les versions étaient gérées fichier par fichier. Je pense à CVS. Puis on s'est vite aperçu qu'un projet c'est un ensemble de fichiers cohérents. Et donc il ne suffit pas de pouvoir revenir en arrière par fichier, mais plutôt dans le temps. Les numéros de versions sont donc passé d'un numéro par fichier à un numéro par projet tout entier.
|
||||
|
||||
Ainsi on peut dire, «je veux revenir trois jours en arrière», et tous les fichiers se remettent à jour.
|
||||
|
||||
<div class="black">
|
||||
|
||||
*Qu'apportent les systèmes de versions ?* (je n'ai pas tout mentionné)
|
||||
|
||||
- backup automatique de tous les fichiers: *Revenir dans le temps.* ;
|
||||
- donne la possibilité de voir les différences entre chaque version et les différences entre la version en cours et les modifications locales ;
|
||||
- permet de poser un *tag* sur certaines versions et ainsi pouvoir s'y référer facilement ;
|
||||
- permet d’avoir un historique des modifications. Car en général il est demandé aux utilisateurs d’ajouter un petit commentaire à chaque nouvelle version.
|
||||
|
||||
</div>
|
||||
|
||||
### concurrentes
|
||||
|
||||
Les systèmes de versions sont déjà intéressants pour gérer ses projets personnels. Car ils permettent de mieux organiser celui-ci. De ne (presque) plus se poser de questions à propos des backups. Je dis presque parce qu'il faut quand même penser à protéger par backup son repository. Mais là où les systèmes de versions deviennent vraiment intéressants, c'est pour la gestion de projets à plusieurs.
|
||||
|
||||
Commençons par un exemple avec un projet fait par deux personnes ; Alex et Béatrice.
|
||||
Sur un fichier contenant une liste de dieux *Lovecraftiens* :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
~~~~~~
|
||||
|
||||
|
||||
Disons que Alex est chez lui, il modifie le fichier :
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
puis il envoi ce fichier sur le serveur du projet. Ainsi sur le serveur, il y a le fichier d'Alex.
|
||||
|
||||
Ensuite c'est Béatrice qui n'a pas récupéré le fichier d'Alex sur le serveur qui fait une modification.
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Puis Béatrice envoi son fichier sur le serveur.
|
||||
|
||||
La modification d'Alex est *perdue*. Encore une fois les systèmes de versions sont là pour résoudre ce type de soucis.
|
||||
|
||||
Un système de version aurait *mergé* les deux fichiers au moment où Béatrice voulait envoyer la modification sur le serveur. Et comme par magie, sur le serveur le fichier deviendra :
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
En pratique, au moment où Béatrice veut envoyer ses modifications, le système de version la préviens qu'une modification a eu lieu sur le serveur. Elle utilise la commande qui rapatrie les modifications localement et qui va mettre à jour le fichier. Ensuite Béatrice renvoie le nouveau fichier sur le serveur.
|
||||
|
||||
<div class="black">
|
||||
|
||||
**Qu'apportent les Systèmes de Versions Concurrentes ?**
|
||||
|
||||
- récupérer sans problème les modifications des autres ;
|
||||
- envoyer sans problème ses modifications aux autres ;
|
||||
- permet de gérer les conflits. Je n'en ai pas parlé, mais quand un conflit arrive (ça peut arriver si deux personnes modifient la même ligne avec deux contenus différents), les <abbr title="Systèmes de versions concurrentes">SVC</abbr> proposent leur aide pour les résoudre. J'en dirai un mot plus loin.
|
||||
- permet de savoir qui a fait quoi et quand
|
||||
|
||||
</div>
|
||||
|
||||
### décentralisé
|
||||
|
||||
Ce mot n'est devenu populaire que très récemment dans le milieu des systèmes de version. Et bien ça veut dire principalement deux choses.
|
||||
|
||||
Tout d'abord, jusqu'à très récemment (SVN) il fallait être connecté sur un serveur distant pour avoir des informations sur un projet. Comme avoir l'historique. Les nouveaux systèmes décentralisés permettent de travailler avec un *REPOSITORY* (le répertoire contenant tous les backups, et les différentes info nécessaires au fonctionnement du système de versions) local au projet. Ainsi on peut avoir l'historique du projet sans avoir à se connecter au serveur.
|
||||
|
||||
Toutes les instances de projets peuvent vivre de façon indépendantes.
|
||||
|
||||
Pour préciser, les systèmes de versions concurrentes décentralisés sont basés sur la notion de **branche**.
|
||||
|
||||
Et la signification pratique est très importante. Ça veut dire que tout les utilisateurs travaillent de façon complètement indépendante les uns des autres. Et c'est l'outil de version qui se charge de mettre tout ça ensemble.
|
||||
|
||||
Ça va même encore plus loin. Ça permet de développer plusieurs features de manière complètement indépendantes. Sous les autres systèmes c'était plus difficile.
|
||||
|
||||
L'exemple type :
|
||||
|
||||
> Je développe mon projet. Je suis en train de l'améliorer. Lorsqu'un bug urgent est reporté.
|
||||
>
|
||||
> Je peux très facilement avec un système décentralisé, revenir sur la version qui pose problème. Résoudre le bug. Renvoyer les modifications. Puis revenir à ma version avec les améliorations en cours. Et même récupérer la correction de bug dans ma nouvelle version avec les améliorations.
|
||||
>
|
||||
> Dans un système non décentralisé, cela est possible, mais fastidieux. Les systèmes décentralisés rendent ce type de comportement très naturels. Ainsi, il devient naturel de tirer des *branches* pour toutes les features, les bug...
|
||||
|
||||
<div class="black">
|
||||
|
||||
**Avantages donnés par la décentralisation des systèmes de versions concurrentes :**
|
||||
|
||||
- Possibilité de travailler sans être connecté au serveur de version ;
|
||||
- Possibilité de créer beaucoup de `patches` atomiques ;
|
||||
- Grande facilité de maintenance de plusieurs versions différentes de la même application.
|
||||
|
||||
</div>
|
||||
|
||||
## Pour résumer
|
||||
|
||||
Résumons l'ensemble des choses que l'on peut faire facilement avec un <abbr title="Decentralized Concurrent Versions System">DCVS</abbr> :
|
||||
|
||||
**Systèmes de versions**
|
||||
|
||||
- revenir dans le temps ;
|
||||
- lister les différences entre chaque version ;
|
||||
- nommer certaines versions pour s'y référer facilement ;
|
||||
- afficher l'historique des modifications.
|
||||
|
||||
**Concurrentes**
|
||||
|
||||
- récupérer les modifications des autres ;
|
||||
- envoyer ses modifications aux autres ;
|
||||
- permet de savoir qui a fait quoi et quand ;
|
||||
- gestion des conflits.
|
||||
|
||||
**Décentralisé**
|
||||
|
||||
- manipuler facilement des branches
|
||||
|
||||
Maintenant voyons comment obtenir toutes ces choses facilement avec [Git][git].
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Avant l'utilisation, la configuration
|
||||
|
||||
## installation
|
||||
|
||||
Sous Linux Ubuntu ou Debian :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ sudo apt-get install git
|
||||
~~~~~~
|
||||
|
||||
Sous Mac OS X :
|
||||
|
||||
* installez [MacPorts](http://macports.org/install.php)
|
||||
* installez [Git][git]
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ sudo port selfupdate
|
||||
|
||||
$ sudo port install git-core
|
||||
~~~~~~
|
||||
|
||||
## Configuration globale
|
||||
|
||||
Enregistrez le fichier suivant comme le fichier `~/.gitconfig`.
|
||||
|
||||
~~~~~~
|
||||
[color]
|
||||
branch = auto
|
||||
diff = auto
|
||||
status = auto
|
||||
[alias]
|
||||
st = status
|
||||
co = checkout
|
||||
br = branch
|
||||
lg = log --pretty=oneline --graph
|
||||
logfull = log --pretty=fuller --graph --stat -p
|
||||
unstage = reset HEAD
|
||||
# there should be an article on what this command do
|
||||
uncommit = !zsh -c '"if (($0)); then nb=$(( $0 - 1 )); else nb=0; fi; i=0; while ((i<=nb)); do git revert -n --no-edit HEAD~$i; ((i++)); done; git commit -m \"revert to $0 version(s) back\""'
|
||||
undomerge = reset --hard ORIG_HEAD
|
||||
conflict = !gitk --left-right HEAD...MERGE_HEAD
|
||||
# under Mac OS X, you should use gitx instead
|
||||
# conflict = !gitx --left-right HEAD...MERGE_HEAD
|
||||
[branch]
|
||||
autosetupmerge = true
|
||||
~~~~~~
|
||||
|
||||
Vous pouvez obtenir le même résultat en utilisant pour chaque entrée la commande `git config --global`.
|
||||
Configurez ensuite votre nom et votre email. Par exemple si vous vous appelez John Doe et que votre email est `john.doe@email.com`. Lancez les commandes suivantes :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git config --global user.name John Doe
|
||||
|
||||
$ git config --global user.email john.doe@email.com
|
||||
~~~~~~
|
||||
|
||||
Voilà, la configuration de base est terminée. J'ai créé dans le fichier de configuration global des *alias* qui vont permettre de taper des commandes un peu plus courtes.
|
||||
|
||||
## Récupération d'un projet déjà versionné
|
||||
|
||||
Si un projet est déjà versionné avec [Git][git] vous devez avoir une `URL` pointant vers les sources du projet. La commande a exécuter est alors très simple.
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cd ~/Projets
|
||||
$ git clone git://main.server/path/to/file
|
||||
~~~~~~
|
||||
|
||||
S'il n'y a pas de serveur git sur le serveur distant, mais que vous avez un accès `ssh`, il suffit de remplacer le `git` de l'url par `ssh`. Pour ne pas avoir à entrer votre mot de passe à chaque fois le plus simple est de procéder comme suit :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ ssh-keygen -t rsa
|
||||
~~~~~~
|
||||
|
||||
Répondez aux question et n'entrez **surtout PAS** de mot de passe. Ensuite copiez les clés sur le serveur distant. Ce n'est pas la façon la plus sûre de procéder. L'idéal étant d'écrire quand même un mot de passe et d'utiliser `ssh-agent`.
|
||||
|
||||
Ensuite le plus simple, si vous possédez `ssh-copy-id` (sous Ubuntu par exemple) :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
me@locahost$ ssh-copy-id -i ~/.ssh/id_rsa.pub me@main.server
|
||||
~~~~~~
|
||||
|
||||
ou manuellement :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
me@locahost$ scp ~/.ssh/id_rsa.pub me@main.server:
|
||||
me@locahost$ ssh me@main.server
|
||||
password:
|
||||
me@main.server$ cat id_rsa.pub >> ~/.ssh/authorized_keys
|
||||
me@main.server$ rm id_rsa.pub
|
||||
me@main.server$ logout
|
||||
~~~~~~
|
||||
|
||||
Maintenant vous n'avez plus besoin de taper votre mot de passe pour accéder à `main.server`. Et donc aussi pour les commandes `git`.
|
||||
|
||||
## Créer un nouveau projet
|
||||
|
||||
Supposons que vous avez déjà un projet avec des fichiers. Alors il est très facile de le versionner.
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cd /path/to/project
|
||||
$ git init
|
||||
$ git add .
|
||||
$ git commit -m "Initial commit"
|
||||
~~~~~~
|
||||
|
||||
Une petite précision. Si vous ne souhaitez pas *versionner* tous les fichiers. Par exemple, les fichiers de compilations intermédiaires. Alors il faut les exclure. Pour cela, avant de lancer la commande `git add .`. Il faut créer un fichier `.gitignore` qui va contenir les *pattern* que git doit ignorer. Par exemple :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
*.o
|
||||
*.bak
|
||||
*.swp
|
||||
*~
|
||||
~~~~~~
|
||||
|
||||
Maintenant si vous voulez créer un repository sur un serveur distant, il faut absolument qu'il soit en mode `bare`. C'est-à-dire que le repository ne contiendra que la partie contenant les informations utile à la gestion de git, mais pas les fichiers du projet. Sans rentrer dans les détails, il suffit de lancer :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ cd /path/to/local/project
|
||||
$ git clone --bare . ssh://server/path/to/project
|
||||
~~~~~~
|
||||
|
||||
Les autres pourront alors récupérer les modifications via la commande vue précédemment :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
git clone ssh://server/path/to/project
|
||||
~~~~~~
|
||||
|
||||
## Résumé de la seconde étape
|
||||
|
||||
Vous avez maintenant un répertoire sur votre ordinateur local. Il est versionné. Vous pouvez vous en rendre compte parcequ'à la racine (et à la racine seulement), il y a un répertoire `.git`. Ce répertoire contient tous les fichiers nécessaires au bon fonctionnement de [Git][git].
|
||||
|
||||
Il ne reste plus qu'à savoir comment s'en servir maintenant pour obtenir toutes les jolies promesses faites dans la première partie.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Et c'est parti !
|
||||
|
||||
Voici une parmi de nombreuses autres façon d'utiliser [Git][git]. Cette méthode est nécessaire et suffisante pour travailler seul ou en collaboration sur un projet commun. Cependant, on peut faire beaucoup mieux avec [Git][git] que ce *workflow* (en langage anglo-saxon).
|
||||
|
||||
## Utilisation basique
|
||||
|
||||
La façon immédiate de travailler avec [Git][git] :
|
||||
|
||||
+ récupérer les modifications des autres `git pull`
|
||||
+ voir les détails de ces modifications `git log`
|
||||
+ Plusieurs fois:
|
||||
+ *Faire une modification atomique*
|
||||
+ verifier le details de ses modifications `git status` et `git diff`
|
||||
+ indiquer si nécessaire que de nouveaux fichiers doivent être *versionnés* `git add [file]`
|
||||
+ enregistrer ses modifications <br/>`git commit -a -m "message"`
|
||||
+ envoyer ses modifications aux autres `git push` (refaire un `git pull` si le push renvoie une erreur).
|
||||
|
||||
Voilà, avec ces quelques commandes vous pouvez utiliser [Git][git] sur un projet avec d'autres personnes. Même si c'est suffisant, il faut quand même connaître une chose avant de se lancer ; la gestion des *conflits*.
|
||||
|
||||
### Gestion des conflits
|
||||
|
||||
Les conflits peuvent survenir lorsque vous modifiez les même lignes de codes sur le même fichier d'une autre branche que vous *mergez*. Ça peut sembler un peu intimidant, mais avec [Git][git] ce genre de chose est très facile a régler.
|
||||
|
||||
#### exemple
|
||||
|
||||
Vous partez du fichier suivant :
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
~~~~~~ {.zsh}
|
||||
Zoot
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
et vous modifiez une ligne
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
sauf que pendant ce temps, un autre utilisateur a aussi modifié cette ligne et a fait un `push` de sa modification.
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot<span class="StringConstant"><strong>, just Zoot</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Maintenant quand vous lancez la commande
|
||||
|
||||
<div>
|
||||
~~~~~~ {.zsh}
|
||||
$ git pull
|
||||
remote: Counting objects: 5, done.
|
||||
remote: Total 3 (delta 0), reused 0 (delta 0)
|
||||
Unpacking objects: 100% (3/3), done.
|
||||
From /home/yogsototh/tmp/conflictTest
|
||||
d3ea395..2dc7ffb master -> origin/master
|
||||
Auto-merging foo
|
||||
CONFLICT (content): Merge conflict in foo
|
||||
Automatic merge failed; fix conflicts and then commit the result.
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
Notre fichier `foo` contient alors :
|
||||
|
||||
<div>
|
||||
<pre class="twilight">
|
||||
<<<<<<< HEAD:foo
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
=======
|
||||
<span>Zoot<span class="StringConstant"><strong>, just Zoot</strong></span></span>
|
||||
>>>>>>> 2dc7ffb0f186a407a1814d1a62684342cd54e7d6:foo
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
#### Résolution du conflit
|
||||
|
||||
Régler le conflit, il suffit d'éditer le fichier, par exemple en écrivant :
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the not so pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
et de 'commiter' tout simplement :
|
||||
|
||||
<div>
|
||||
~~~~~~ {.zsh}
|
||||
git commit -a -m "conflict resolved"
|
||||
~~~~~~
|
||||
</div>
|
||||
|
||||
Maintenant vous êtes fin prêt pour utiliser [Git][git].
|
||||
Sauf que [Git][git], c'est un outil qui permet de faire beaucoup plus que juste ça. Nous allons maintenant voir comment utiliser les fonctionnalités de Git qui n'étaient pas disponibles avec CVS et consorts.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Pourquoi Git est cool ?
|
||||
|
||||
Parce que grace à [Git][git] vous pouvez travailler sur plusieurs partie du projet de façon complètement isolée les unes des autres. Ça c'est la partie décentralisée de [Git][git].
|
||||
|
||||
Toutes les branches locales utilisent le même répertoire. Ainsi on peu changer de branche très aisément et rapidement. On peut aussi changer de branche alors que certains fichier sont en cours de modifications. On peut même pousser le vice jusqu'à modifier un fichier, changer de branche, commiter une partie seulement des modifications de ce fichier dans la branche courante. Revenir dans l'ancienne branche et commiter à nouveau les modifications restantes. Et merger dans une troisième branche les deux modifications.
|
||||
|
||||
Avec la command `git rebase` on peut après coup, décider que certaines modifications devaient aller dans certaines branches, que d'autres ne servaient à rien. C'est une commande vraiment très puissante pour organiser l'historique.
|
||||
|
||||
En pratique, qu'est-ce que ça signifie ? Mieux qu'avec tous les autres systèmes de versions, vous pouvez utiliser [Git][git] pour vous concentrer sur votre code. En effet, on peut envoyer les commits après avoir coder. Par exemple, vous pouvez coder sur la résolution du bug b01, du bug b02 et de la feature f03. Puis ensuite, vous pouvez créer une branche par bug et par feature. Puis commiter les modifications pour chaque branche et chaque feature. Puis finalement merger tous les modifications dans la branche principale.
|
||||
|
||||
Tout a été pensé pour vous permettre de coder d'abord, puis de vous occuper du système de version plus tard. Bien entendu, faire des commit atomique au fur et à mesure du code permet de gagner du temps et de ne pas trop s'embêter pour organiser les branches. Mais rien ne vous y oblige. Par contre faire la même chose dans d'autres systèmes de versions n'est absolument pas naturel.
|
||||
|
||||
Avec [Git][git] vous pouvez aussi dépendre de plusieurs sources. Ainsi, plutôt que d'avoir un serveur centralisé, vous pouvez avoir plusieurs sources. Vous pouvez définir ce genre de chose très finement.
|
||||
|
||||
Ce qui change le plus avec [Git][git] c'est la vision d'un projet centralisé sur un serveur avec plusieurs personnes qui travaillent dessus. Avec [Git][git] plusieurs personnes peuvent travailler sur le même projet, mais sans nécessairement avoir un *repository* de référence. On peut très facilement résoudre un bug et envoyer le patch à plein d'autres versions du projet.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
||||
# Liste de commandes
|
||||
|
||||
## Les commandes pour chaque choses
|
||||
|
||||
Dans la première partie, nous avons vu la liste des problèmes résolus par [Git][git]. En résumé Git doit pouvoir :
|
||||
|
||||
- récupérer les modifications des autres ;
|
||||
- envoyer ses modifications aux autres ;
|
||||
- revenir dans le temps ;
|
||||
- lister les différences entre chaque version ;
|
||||
- nommer certaines versions pour s'y référer facilement ;
|
||||
- afficher l'historique des modifications ;
|
||||
- savoir qui a fait quoi et quand ;
|
||||
- gérer des conflits ;
|
||||
- manipuler facilement des branches.
|
||||
|
||||
### récupérer les modifications des autres
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git pull
|
||||
~~~~~~
|
||||
|
||||
### envoyer ses modifications aux autres
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git push
|
||||
~~~~~~
|
||||
|
||||
ou plus généralement
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git pull
|
||||
$ git push
|
||||
~~~~~~
|
||||
|
||||
### revenir dans le temps
|
||||
|
||||
#### Pour toute l'arborescence
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git checkout
|
||||
~~~~~~
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git revert
|
||||
~~~~~~
|
||||
|
||||
revenir trois versions en arrière
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git uncommit 3
|
||||
~~~~~~
|
||||
|
||||
Revenir avant le dernier merge (s'il s'est mal passé).
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git revertbeforemerge
|
||||
~~~~~~
|
||||
|
||||
#### Pour un seul fichier
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git checkout file
|
||||
$ git checkout VersionHash file
|
||||
$ git checkout HEAD~3 file
|
||||
~~~~~~
|
||||
|
||||
### lister les différences entre chaque version
|
||||
|
||||
liste les fichiers en cours de modifications
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git status
|
||||
~~~~~~
|
||||
|
||||
différences entre les fichiers de la dernière version et les fichiers locaux.
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git diff
|
||||
~~~~~~
|
||||
|
||||
liste les différences entre les fichier d'une certaine version et les fichiers locaux.
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git diff VersionHash fichier
|
||||
~~~~~~
|
||||
|
||||
### nommer certaines versions pour s'y référer facilement
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git tag 'toto'
|
||||
~~~~~~
|
||||
|
||||
### afficher l'historique des modifications
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git log
|
||||
$ git lg
|
||||
$ git logfull
|
||||
~~~~~~
|
||||
|
||||
### savoir qui a fait quoi et quand
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git blame fichier
|
||||
~~~~~~
|
||||
|
||||
### gérer des conflits
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git conflict
|
||||
~~~~~~
|
||||
|
||||
### manipuler facilement des branches
|
||||
|
||||
Pour créer une branche :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git branch branch_name
|
||||
~~~~~~
|
||||
|
||||
Pour changer de branche courante :
|
||||
|
||||
~~~~~~ {.zsh}
|
||||
$ git checkout branch_name
|
||||
~~~~~~
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
|
|||
|
|
@ -1,189 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 1
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git pour les nuls
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Git pour quoi faire ?
|
||||
-----
|
||||
|
||||
# [Git][git] pour quoi faire ?
|
||||
|
||||
begindiv(intro)
|
||||
|
||||
Si tout ce qui vous intéresse c'est d'utiliser [Git][git] **tout de suite**. Lisez simplement les parties sur fond noir. Je vous conseille aussi de revenir relire tout ça un peu plus tard, pour mieux comprendre les fondements des systèmes de versions et ne pas faire de bêtises quand vous les utilisez.
|
||||
|
||||
enddiv
|
||||
|
||||
[Git][git] est un <abbr title="Decentralized Concurent Versions System">DCVS</abbr>, c'est-à-dire un système de versions concurrentes décentralisé. Analysons chaque partie de cette appellation compliquée.
|
||||
|
||||
### Système de versions
|
||||
|
||||
Tout d'abord, les systèmes de versions gèrent des fichiers.
|
||||
Quand on travaille avec des fichiers sans système de version voilà ce qui arrive souvent :
|
||||
|
||||
Lorsqu'on modifie un fichier un peu critique et qu'on a pas envie de perdre, on se retrouve souvent à le recopier sous un autre nom. Par exemple
|
||||
|
||||
<div><code class="zsh">$ cp fichier_important.c fichier_important.c.bak</code></div>
|
||||
|
||||
Du coups, ce nouveau fichier joue le rôle de *backup*. Si on casse tout, on peut toujours écraser les modifications que nous avons faites. Évidemment le problème avec cette façon de faire c'est que ce n'est pas très professionnel. Et puis c'est un peu limité. Si on veut faire trois ou quatre modifications on se retrouve avec plein de fichiers. Parfois avec des nom bizarres comme :
|
||||
|
||||
<div>
|
||||
<code class="zsh">
|
||||
fichier_important.c.bak
|
||||
fichier_important.c.old
|
||||
fichier_important.c.Bakcup
|
||||
fichier_important.c.BAK.2009-11-14
|
||||
fichier_important.c.2009.11.14
|
||||
fichier_important.c.12112009
|
||||
old.fichier_important.c
|
||||
</code>
|
||||
</div>
|
||||
|
||||
Bon alors si on veut que ça marche il faut se fixer des conventions de nommage. Les fichiers prennent beaucoup de place alors que souvent il n'y a que quelques lignes différentes entre le fichier et son backup...
|
||||
|
||||
*Heureusement les systèmes de version viennent à la rescousse.*
|
||||
|
||||
Il suffit de signaler que l'on va faire une nouvelle version d'un fichier et le système de version se débrouille pour l'enregistrer quelque part où on pourra facilement le retrouver. Et en général, le système de version fait les choses bien. C'est-à-dire qu'il n'utilise que très peu d'espace disque pour faire ces backups.
|
||||
|
||||
Il fut un temps où les versions étaient gérées fichier par fichier. Je pense à CVS. Puis on s'est vite aperçu qu'un projet c'est un ensemble de fichiers cohérents. Et donc il ne suffit pas de pouvoir revenir en arrière par fichier, mais plutôt dans le temps. Les numéros de versions sont donc passé d'un numéro par fichier à un numéro par projet tout entier.
|
||||
|
||||
Ainsi on peut dire, «je veux revenir trois jours en arrière», et tous les fichiers se remettent à jour.
|
||||
|
||||
begindiv(black)
|
||||
|
||||
*Qu'apportent les systèmes de versions ?* (je n'ai pas tout mentionné)
|
||||
|
||||
- backup automatique de tous les fichiers: *Revenir dans le temps.* ;
|
||||
- donne la possibilité de voir les différences entre chaque version et les différences entre la version en cours et les modifications locales ;
|
||||
- permet de poser un *tag* sur certaines versions et ainsi pouvoir s'y référer facilement ;
|
||||
- permet d’avoir un historique des modifications. Car en général il est demandé aux utilisateurs d’ajouter un petit commentaire à chaque nouvelle version.
|
||||
|
||||
enddiv
|
||||
|
||||
### concurrentes
|
||||
|
||||
Les systèmes de versions sont déjà intéressants pour gérer ses projets personnels. Car ils permettent de mieux organiser celui-ci. De ne (presque) plus se poser de questions à propos des backups. Je dis presque parce qu'il faut quand même penser à protéger par backup son repository. Mais là où les systèmes de versions deviennent vraiment intéressants, c'est pour la gestion de projets à plusieurs.
|
||||
|
||||
Commençons par un exemple avec un projet fait par deux personnes ; Alex et Béatrice.
|
||||
Sur un fichier contenant une liste de dieux *Lovecraftiens* :
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<code class="zsh">
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
</code></div>
|
||||
|
||||
Disons que Alex est chez lui, il modifie le fichier :
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
puis il envoi ce fichier sur le serveur du projet. Ainsi sur le serveur, il y a le fichier d'Alex.
|
||||
|
||||
Ensuite c'est Béatrice qui n'a pas récupéré le fichier d'Alex sur le serveur qui fait une modification.
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Puis Béatrice envoi son fichier sur le serveur.
|
||||
|
||||
La modification d'Alex est *perdue*. Encore une fois les systèmes de versions sont là pour résoudre ce type de soucis.
|
||||
|
||||
Un système de version aurait *mergé* les deux fichiers au moment où Béatrice voulait envoyer la modification sur le serveur. Et comme par magie, sur le serveur le fichier deviendra :
|
||||
|
||||
<div style="width: 10em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Cthulhu
|
||||
<span class="Constant"><strong>Dagon</strong></span>
|
||||
Shubniggurath
|
||||
<span class="StringConstant"><strong>Soggoth</strong></span>
|
||||
Yogsototh
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
En pratique, au moment où Béatrice veut envoyer ses modifications, le système de version la préviens qu'une modification a eu lieu sur le serveur. Elle utilise la commande qui rapatrie les modifications localement et qui va mettre à jour le fichier. Ensuite Béatrice renvoie le nouveau fichier sur le serveur.
|
||||
|
||||
begindiv(black)
|
||||
|
||||
**Qu'apportent les Systèmes de Versions Concurrentes ?**
|
||||
|
||||
- récupérer sans problème les modifications des autres ;
|
||||
- envoyer sans problème ses modifications aux autres ;
|
||||
- permet de gérer les conflits. Je n'en ai pas parlé, mais quand un conflit arrive (ça peut arriver si deux personnes modifient la même ligne avec deux contenus différents), les <abbr title="Systèmes de versions concurrentes">SVC</abbr> proposent leur aide pour les résoudre. J'en dirai un mot plus loin.
|
||||
- permet de savoir qui a fait quoi et quand
|
||||
|
||||
enddiv
|
||||
|
||||
### décentralisé
|
||||
|
||||
Ce mot n'est devenu populaire que très récemment dans le milieu des systèmes de version. Et bien ça veut dire principalement deux choses.
|
||||
|
||||
Tout d'abord, jusqu'à très récemment (SVN) il fallait être connecté sur un serveur distant pour avoir des informations sur un projet. Comme avoir l'historique. Les nouveaux systèmes décentralisés permettent de travailler avec un *REPOSITORY* (le répertoire contenant tous les backups, et les différentes info nécessaires au fonctionnement du système de versions) local au projet. Ainsi on peut avoir l'historique du projet sans avoir à se connecter au serveur.
|
||||
|
||||
Toutes les instances de projets peuvent vivre de façon indépendantes.
|
||||
|
||||
Pour préciser, les systèmes de versions concurrentes décentralisés sont basés sur la notion de **branche**.
|
||||
|
||||
Et la signification pratique est très importante. Ça veut dire que tout les utilisateurs travaillent de façon complètement indépendante les uns des autres. Et c'est l'outil de version qui se charge de mettre tout ça ensemble.
|
||||
|
||||
Ça va même encore plus loin. Ça permet de développer plusieurs features de manière complètement indépendantes. Sous les autres systèmes c'était plus difficile.
|
||||
|
||||
L'exemple type :
|
||||
|
||||
> Je développe mon projet. Je suis en train de l'améliorer. Lorsqu'un bug urgent est reporté.
|
||||
>
|
||||
> Je peux très facilement avec un système décentralisé, revenir sur la version qui pose problème. Résoudre le bug. Renvoyer les modifications. Puis revenir à ma version avec les améliorations en cours. Et même récupérer la correction de bug dans ma nouvelle version avec les améliorations.
|
||||
>
|
||||
> Dans un système non décentralisé, cela est possible, mais fastidieux. Les systèmes décentralisés rendent ce type de comportement très naturels. Ainsi, il devient naturel de tirer des *branches* pour toutes les features, les bug...
|
||||
|
||||
begindiv(black)
|
||||
|
||||
**Avantages donnés par la décentralisation des systèmes de versions concurrentes : **
|
||||
|
||||
- Possibilité de travailler sans être connecté au serveur de version ;
|
||||
- Possibilité de créer beaucoup de `patches` atomiques ;
|
||||
- Grande facilité de maintenance de plusieurs versions différentes de la même application.
|
||||
|
||||
enddiv
|
||||
|
||||
## Pour résumer
|
||||
|
||||
Résumons l'ensemble des choses que l'on peut faire facilement avec un <abbr title="Decentralized Concurrent Versions System">DCVS</abbr> :
|
||||
|
||||
**Systèmes de versions**
|
||||
|
||||
- revenir dans le temps ;
|
||||
- lister les différences entre chaque version ;
|
||||
- nommer certaines versions pour s'y référer facilement ;
|
||||
- afficher l'historique des modifications.
|
||||
|
||||
**Concurrentes**
|
||||
|
||||
- récupérer les modifications des autres ;
|
||||
- envoyer ses modifications aux autres ;
|
||||
- permet de savoir qui a fait quoi et quand ;
|
||||
- gestion des conflits.
|
||||
|
||||
**Décentralisé**
|
||||
|
||||
- manipuler facilement des branches
|
||||
|
||||
Maintenant voyons comment obtenir toutes ces choses facilement avec [Git][git].
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,110 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 3
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git pour les nuls
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Utiliser git avec quelques commandes simples
|
||||
-----
|
||||
|
||||
# Et c'est parti !
|
||||
|
||||
Voici une parmi de nombreuses autres façon d'utiliser [Git][git]. Cette méthode est nécessaire et suffisante pour travailler seul ou en collaboration sur un projet commun. Cependant, on peut faire beaucoup mieux avec [Git][git] que ce *workflow* (en langage anglo-saxon).
|
||||
|
||||
## Utilisation basique
|
||||
|
||||
La façon immédiate de travailler avec [Git][git] :
|
||||
|
||||
+ récupérer les modifications des autres `git pull`
|
||||
+ voir les détails de ces modifications `git log`
|
||||
+ Plusieurs fois:
|
||||
+ *Faire une modification atomique*
|
||||
+ verifier le details de ses modifications `git status` et `git diff`
|
||||
+ indiquer si nécessaire que de nouveaux fichiers doivent être *versionnés* `git add [file]`
|
||||
+ enregistrer ses modifications <br/>`git commit -a -m "message"`
|
||||
+ envoyer ses modifications aux autres `git push` (refaire un `git pull` si le push renvoie une erreur).
|
||||
|
||||
Voilà, avec ces quelques commandes vous pouvez utiliser [Git][git] sur un projet avec d'autres personnes. Même si c'est suffisant, il faut quand même connaître une chose avant de se lancer ; la gestion des *conflits*.
|
||||
|
||||
### Gestion des conflits
|
||||
|
||||
Les conflits peuvent survenir lorsque vous modifiez les même lignes de codes sur le même fichier d'une autre branche que vous *mergez*. Ça peut sembler un peu intimidant, mais avec [Git][git] ce genre de chose est très facile a régler.
|
||||
|
||||
#### exemple
|
||||
|
||||
Vous partez du fichier suivant :
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<code class="zsh">
|
||||
Zoot
|
||||
</code>
|
||||
</div>
|
||||
|
||||
et vous modifiez une ligne
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
sauf que pendant ce temps, un autre utilisateur a aussi modifié cette ligne et a fait un `push` de sa modification.
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot<span class="StringConstant"><strong>, just Zoot</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
Maintenant quand vous lancez la commande
|
||||
|
||||
<div>
|
||||
<code class="zsh">
|
||||
$ git pull
|
||||
remote: Counting objects: 5, done.
|
||||
remote: Total 3 (delta 0), reused 0 (delta 0)
|
||||
Unpacking objects: 100% (3/3), done.
|
||||
From /home/yogsototh/tmp/conflictTest
|
||||
d3ea395..2dc7ffb master -> origin/master
|
||||
Auto-merging foo
|
||||
CONFLICT (content): Merge conflict in foo
|
||||
Automatic merge failed; fix conflicts and then commit the result.
|
||||
</code>
|
||||
</div>
|
||||
|
||||
Notre fichier `foo` contient alors :
|
||||
|
||||
<div>
|
||||
<pre class="twilight">
|
||||
<<<<<<< HEAD:foo
|
||||
Zoot <span class="Constant"><strong>the pure</strong></span>
|
||||
=======
|
||||
<span>Zoot<span class="StringConstant"><strong>, just Zoot</strong></span></span>
|
||||
>>>>>>> 2dc7ffb0f186a407a1814d1a62684342cd54e7d6:foo
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
#### Résolution du conflit
|
||||
|
||||
Régler le conflit, il suffit d'éditer le fichier, par exemple en écrivant :
|
||||
|
||||
<div style="width: 18em; margin-left: auto; margin-right: auto">
|
||||
<pre class="twilight">
|
||||
Zoot <span class="Constant"><strong>the not so pure</strong></span>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
et de 'commiter' tout simplement :
|
||||
|
||||
<div>
|
||||
<code class="zsh">
|
||||
git commit -a -m "conflict resolved"
|
||||
</code>
|
||||
</div>
|
||||
|
||||
Maintenant vous êtes fin prêt pour utiliser [Git][git].
|
||||
Sauf que [Git][git], c'est un outil qui permet de faire beaucoup plus que juste ça. Nous allons maintenant voir comment utiliser les fonctionnalités de Git qui n'étaient pas disponibles avec CVS et consorts.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,144 +0,0 @@
|
|||
-----
|
||||
|
||||
# Custom
|
||||
isHidden: false
|
||||
menupriority: 30
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git pour les nuls
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Liste de commandes
|
||||
tags:
|
||||
- git
|
||||
|
||||
-----
|
||||
|
||||
# Liste de commandes
|
||||
|
||||
## Les commandes pour chaque choses
|
||||
|
||||
Dans la première partie, nous avons vu la liste des problèmes résolus par [Git][git]. En résumé Git doit pouvoir :
|
||||
|
||||
- récupérer les modifications des autres ;
|
||||
- envoyer ses modifications aux autres ;
|
||||
- revenir dans le temps ;
|
||||
- lister les différences entre chaque version ;
|
||||
- nommer certaines versions pour s'y référer facilement ;
|
||||
- afficher l'historique des modifications ;
|
||||
- savoir qui a fait quoi et quand ;
|
||||
- gérer des conflits ;
|
||||
- manipuler facilement des branches.
|
||||
|
||||
### récupérer les modifications des autres
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git pull
|
||||
</code></div>
|
||||
|
||||
### envoyer ses modifications aux autres
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git push
|
||||
</code></div>
|
||||
|
||||
ou plus généralement
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git pull
|
||||
$ git push
|
||||
</code></div>
|
||||
|
||||
### revenir dans le temps
|
||||
|
||||
#### Pour toute l'arborescence
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git checkout
|
||||
</code></div>
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git revert
|
||||
</code></div>
|
||||
|
||||
revenir trois versions en arrière
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git uncommit 3
|
||||
</code></div>
|
||||
|
||||
Revenir avant le dernier merge (s'il s'est mal passé).
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git revertbeforemerge
|
||||
</code></div>
|
||||
|
||||
#### Pour un seul fichier
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git checkout file
|
||||
$ git checkout VersionHash file
|
||||
$ git checkout HEAD~3 file
|
||||
</code></div>
|
||||
|
||||
### lister les différences entre chaque version
|
||||
|
||||
liste les fichiers en cours de modifications
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git status
|
||||
</code></div>
|
||||
|
||||
différences entre les fichiers de la dernière version et les fichiers locaux.
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git diff
|
||||
</code></div>
|
||||
|
||||
liste les différences entre les fichier d'une certaine version et les fichiers locaux.
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git diff VersionHash fichier
|
||||
</code></div>
|
||||
|
||||
### nommer certaines versions pour s'y référer facilement
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git tag 'toto'
|
||||
</code></div>
|
||||
|
||||
### afficher l'historique des modifications
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git log
|
||||
$ git lg
|
||||
$ git logfull
|
||||
</code></div>
|
||||
|
||||
### savoir qui a fait quoi et quand
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git blame fichier
|
||||
</code></div>
|
||||
|
||||
### gérer des conflits
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git conflict
|
||||
</code></div>
|
||||
|
||||
### manipuler facilement des branches
|
||||
|
||||
Pour créer une branche :
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git branch branch_name
|
||||
</code></div>
|
||||
|
||||
Pour changer de branche courante :
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git checkout branch_name
|
||||
</code></div>
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 10
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git pour les nuls
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Comprendre
|
||||
tags:
|
||||
- git
|
||||
-----
|
||||
|
||||
# Pourquoi Git est cool ?
|
||||
|
||||
Parce que grace à [Git][git] vous pouvez travailler sur plusieurs partie du projet de façon complètement isolée les unes des autres. Ça c'est la partie décentralisée de [Git][git].
|
||||
|
||||
Toutes les branches locales utilisent le même répertoire. Ainsi on peu changer de branche très aisément et rapidement. On peut aussi changer de branche alors que certains fichier sont en cours de modifications. On peut même pousser le vice jusqu'à modifier un fichier, changer de branche, commiter une partie seulement des modifications de ce fichier dans la branche courante. Revenir dans l'ancienne branche et commiter à nouveau les modifications restantes. Et merger dans une troisième branche les deux modifications.
|
||||
|
||||
Avec la command `git rebase` on peut après coup, décider que certaines modifications devaient aller dans certaines branches, que d'autres ne servaient à rien. C'est une commande vraiment très puissante pour organiser l'historique.
|
||||
|
||||
En pratique, qu'est-ce que ça signifie ? Mieux qu'avec tous les autres systèmes de versions, vous pouvez utiliser [Git][git] pour vous concentrer sur votre code. En effet, on peut envoyer les commits après avoir coder. Par exemple, vous pouvez coder sur la résolution du bug b01, du bug b02 et de la feature f03. Puis ensuite, vous pouvez créer une branche par bug et par feature. Puis commiter les modifications pour chaque branche et chaque feature. Puis finalement merger tous les modifications dans la branche principale.
|
||||
|
||||
Tout a été pensé pour vous permettre de coder d'abord, puis de vous occuper du système de version plus tard. Bien entendu, faire des commit atomique au fur et à mesure du code permet de gagner du temps et de ne pas trop s'embêter pour organiser les branches. Mais rien ne vous y oblige. Par contre faire la même chose dans d'autres systèmes de versions n'est absolument pas naturel.
|
||||
|
||||
Avec [Git][git] vous pouvez aussi dépendre de plusieurs sources. Ainsi, plutôt que d'avoir un serveur centralisé, vous pouvez avoir plusieurs sources. Vous pouvez définir ce genre de chose très finement.
|
||||
|
||||
Ce qui change le plus avec [Git][git] c'est la vision d'un projet centralisé sur un serveur avec plusieurs personnes qui travaillent dessus. Avec [Git][git] plusieurs personnes peuvent travailler sur le même projet, mais sans nécessairement avoir un *repository* de référence. On peut très facilement résoudre un bug et envoyer le patch à plein d'autres versions du projet.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
|
|
@ -1,143 +0,0 @@
|
|||
-----
|
||||
isHidden: false
|
||||
menupriority: 2
|
||||
kind: article
|
||||
created_at: 2009-11-12T11:39:54+02:00
|
||||
title: Git pour les nuls
|
||||
author_name: Yann Esposito
|
||||
author_uri: yannesposito.com
|
||||
subtitle: Avant l'utilisation, la configuration
|
||||
-----
|
||||
|
||||
# Avant l'utilisation, la configuration
|
||||
|
||||
## installation
|
||||
|
||||
Sous Linux Ubuntu ou Debian :
|
||||
|
||||
<div><code class="zsh">$ sudo apt-get install git</code></div>
|
||||
|
||||
Sous Mac OS X :
|
||||
|
||||
* installez [MacPorts](http://macports.org/install.php)
|
||||
* installez [Git][git]
|
||||
|
||||
<div><code class="zsh">
|
||||
$ sudo port selfupdate
|
||||
|
||||
$ sudo port install git-core
|
||||
</code></div>
|
||||
|
||||
## Configuration globale
|
||||
|
||||
Enregistrez le fichier suivant comme le fichier `~/.gitconfig`.
|
||||
|
||||
<div><code class="zsh" file="gitconfig">
|
||||
[color]
|
||||
branch = auto
|
||||
diff = auto
|
||||
status = auto
|
||||
[alias]
|
||||
st = status
|
||||
co = checkout
|
||||
br = branch
|
||||
lg = log --pretty=oneline --graph
|
||||
logfull = log --pretty=fuller --graph --stat -p
|
||||
unstage = reset HEAD
|
||||
# there should be an article on what this command do
|
||||
uncommit = !zsh -c '"if (($0)); then nb=$(( $0 - 1 )); else nb=0; fi; i=0; while ((i<=nb)); do git revert -n --no-edit HEAD~$i; ((i++)); done; git commit -m \"revert to $0 version(s) back\""'
|
||||
undomerge = reset --hard ORIG_HEAD
|
||||
conflict = !gitk --left-right HEAD...MERGE_HEAD
|
||||
# under Mac OS X, you should use gitx instead
|
||||
# conflict = !gitx --left-right HEAD...MERGE_HEAD
|
||||
[branch]
|
||||
autosetupmerge = true
|
||||
</code></div>
|
||||
|
||||
Vous pouvez obtenir le même résultat en utilisant pour chaque entrée la commande `git config --global`.
|
||||
Configurez ensuite votre nom et votre email. Par exemple si vous vous appelez John Doe et que votre email est `john.doe@email.com`. Lancez les commandes suivantes :
|
||||
|
||||
<div><code class="zsh">
|
||||
$ git config --global user.name John Doe
|
||||
|
||||
$ git config --global user.email john.doe@email.com
|
||||
</code></div>
|
||||
|
||||
Voilà, la configuration de base est terminée. J'ai créé dans le fichier de configuration global des *alias* qui vont permettre de taper des commandes un peu plus courtes.
|
||||
|
||||
## Récupération d'un projet déjà versionné
|
||||
|
||||
Si un projet est déjà versionné avec [Git][git] vous devez avoir une `URL` pointant vers les sources du projet. La commande a exécuter est alors très simple.
|
||||
|
||||
<div><code class="zsh">
|
||||
$ cd ~/Projets
|
||||
$ git clone git://main.server/path/to/file
|
||||
</code></div>
|
||||
|
||||
S'il n'y a pas de serveur git sur le serveur distant, mais que vous avez un accès `ssh`, il suffit de remplacer le `git` de l'url par `ssh`. Pour ne pas avoir à entrer votre mot de passe à chaque fois le plus simple est de procéder comme suit :
|
||||
|
||||
<div><code class="zsh">
|
||||
$ ssh-keygen -t rsa
|
||||
</code></div>
|
||||
|
||||
Répondez aux question et n'entrez **surtout PAS** de mot de passe. Ensuite copiez les clés sur le serveur distant. Ce n'est pas la façon la plus sûre de procéder. L'idéal étant d'écrire quand même un mot de passe et d'utiliser `ssh-agent`.
|
||||
|
||||
Ensuite le plus simple, si vous possédez `ssh-copy-id` (sous Ubuntu par exemple) :
|
||||
|
||||
<div><code class="zsh">
|
||||
me@locahost$ ssh-copy-id -i ~/.ssh/id_rsa.pub me@main.server
|
||||
</code></div>
|
||||
|
||||
ou manuellement :
|
||||
|
||||
<div><code class="zsh">
|
||||
me@locahost$ scp ~/.ssh/id_rsa.pub me@main.server:
|
||||
me@locahost$ ssh me@main.server
|
||||
password:
|
||||
me@main.server$ cat id_rsa.pub >> ~/.ssh/authorized_keys
|
||||
me@main.server$ rm id_rsa.pub
|
||||
me@main.server$ logout
|
||||
</code></div>
|
||||
|
||||
Maintenant vous n'avez plus besoin de taper votre mot de passe pour accéder à `main.server`. Et donc aussi pour les commandes `git`.
|
||||
|
||||
## Créer un nouveau projet
|
||||
|
||||
Supposons que vous avez déjà un projet avec des fichiers. Alors il est très facile de le versionner.
|
||||
|
||||
<div><code class="zsh">
|
||||
$ cd /path/to/project
|
||||
$ git init
|
||||
$ git add .
|
||||
$ git commit -m "Initial commit"
|
||||
</code></div>
|
||||
|
||||
Une petite précision. Si vous ne souhaitez pas *versionner* tous les fichiers. Par exemple, les fichiers de compilations intermédiaires. Alors il faut les exclure. Pour cela, avant de lancer la commande `git add .`. Il faut créer un fichier `.gitignore` qui va contenir les *pattern* que git doit ignorer. Par exemple :
|
||||
|
||||
<div><code class="zsh">
|
||||
*.o
|
||||
*.bak
|
||||
*.swp
|
||||
*~
|
||||
</code></div>
|
||||
|
||||
Maintenant si vous voulez créer un repository sur un serveur distant, il faut absolument qu'il soit en mode `bare`. C'est-à-dire que le repository ne contiendra que la partie contenant les informations utile à la gestion de git, mais pas les fichiers du projet. Sans rentrer dans les détails, il suffit de lancer :
|
||||
|
||||
<div><code class="zsh">
|
||||
$ cd /path/to/local/project
|
||||
$ git clone --bare . ssh://server/path/to/project
|
||||
</code></div>
|
||||
|
||||
Les autres pourront alors récupérer les modifications via la commande vue précédemment :
|
||||
|
||||
<div><code class="zsh">
|
||||
git clone ssh://server/path/to/project
|
||||
</code></div>
|
||||
|
||||
## Résumé de la seconde étape
|
||||
|
||||
Vous avez maintenant un répertoire sur votre ordinateur local. Il est versionné. Vous pouvez vous en rendre compte parcequ'à la racine (et à la racine seulement), il y a un répertoire `.git`. Ce répertoire contient tous les fichiers nécessaires au bon fonctionnement de [Git][git].
|
||||
|
||||
Il ne reste plus qu'à savoir comment s'en servir maintenant pour obtenir toutes les jolies promesses faites dans la première partie.
|
||||
|
||||
[git]: http://git-scm.org "Git"
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -107,7 +107,7 @@
|
|||
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Copyright ©, Yann Esposito</a>
|
||||
</div>
|
||||
<div id="lastmod">
|
||||
Modified: 02/08/2013
|
||||
Modified: 02/26/2013
|
||||
</div>
|
||||
<div>
|
||||
Entirely done with
|
||||
|
|
|
|||
Loading…
Reference in a new issue