From 7bb5cc56090fad706f3a62db69815d2d239930f1 Mon Sep 17 00:00:00 2001 From: humboldtux Date: Thu, 20 Mar 2014 14:23:37 +0100 Subject: [PATCH 01/22] fr version --- _layouts/fr_reference.html | 107 ++++ fr/.gitignore | 2 + fr/about.html | 9 + fr/basic/index.html | 973 +++++++++++++++++++++++++++++++++++++ fr/branching/index.html | 864 ++++++++++++++++++++++++++++++++ fr/cookbook.html | 12 + fr/creating/index.html | 142 ++++++ fr/images/snapshots.png | Bin 0 -> 23231 bytes fr/index.html | 112 +++++ fr/inspect/index.html | 475 ++++++++++++++++++ fr/remotes/index.html | 440 +++++++++++++++++ 11 files changed, 3136 insertions(+) create mode 100755 _layouts/fr_reference.html create mode 100644 fr/.gitignore create mode 100644 fr/about.html create mode 100644 fr/basic/index.html create mode 100644 fr/branching/index.html create mode 100644 fr/cookbook.html create mode 100644 fr/creating/index.html create mode 100644 fr/images/snapshots.png create mode 100644 fr/index.html create mode 100644 fr/inspect/index.html create mode 100644 fr/remotes/index.html diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html new file mode 100755 index 0000000..9cb4cdf --- /dev/null +++ b/_layouts/fr_reference.html @@ -0,0 +1,107 @@ + + + + + Git Reference + + + + + + + + + + + + +
+ +
+ Git Reference +
+ +
+ +
+   +
+ + + +
+ {{ content }} +
+ +
+
+ + diff --git a/fr/.gitignore b/fr/.gitignore new file mode 100644 index 0000000..a16c005 --- /dev/null +++ b/fr/.gitignore @@ -0,0 +1,2 @@ +_site +*~ diff --git a/fr/about.html b/fr/about.html new file mode 100644 index 0000000..02b0199 --- /dev/null +++ b/fr/about.html @@ -0,0 +1,9 @@ +--- +layout: reference +--- +
+

Who Did This?

+
+

The Git Reference site was put together by the GitHub + team.

+
diff --git a/fr/basic/index.html b/fr/basic/index.html new file mode 100644 index 0000000..b381b86 --- /dev/null +++ b/fr/basic/index.html @@ -0,0 +1,973 @@ +--- +layout: reference +--- + +
+

+ + book + + Basic Snapshotting +

+
+

+ Git is all about composing and saving snapshots of your project and then + working with and comparing those snapshots. This section will explain + the commands needed to compose and commit snapshots of your project. +

+ +

+ An important concept here is that Git has an 'index', which acts as sort + of a staging area for your snapshot. This allows you to build up a series + of well composed snapshots from changed files in your working directory, + rather than having to commit all of the file changes at once. +

+ +

+ In a nutshell, you will use git add to start tracking new + files and also to stage changes to already tracked files, then + git status and git diff to see what has been + modified and staged and finally git commit to record your + snapshot into your history. This will be the basic workflow that you use + most of the time. +

+ +
+
+ +
+

+ + docs   + book + + git add + adds file contents to the staging area +

+ +
+

+ In Git, you have to add file contents to your staging area before you + can commit them. If the file is new, you can run git add + to initially add the file to your staging area, but even if the file + is already "tracked" - ie, it was in your last commit - you still need + to call git add to add new modifications to your staging + area. Let's see a few examples of this. +

+ +

Going back to our Hello World example, once we've initiated the project, + we would now start adding our files to it and we would do that with + git add. We can use git status to see what the + state of our project is. +

+ +
+$ git status -s
+?? README
+?? hello.rb
+
+ + So right now we have two untracked files. We can now add them. + +
+$ git add README hello.rb
+
+ + Now if we run git status again, we'll see that they've been + added. + +
+$ git status -s
+A  README
+A  hello.rb
+
+ +

+ It is also common to recursively add all files in a new project by specifying + the current working directory like this: git add .. Since Git + will recursively add all files under a directory you give it, if you give it + the current working directory, it will simply start tracking every file + there. In this case, a git add . would have done the same + thing as a git add README hello.rb, or for that matter so would + git add *, but that's only because we don't have subdirectories + which the * would not recurse into. +

+ +

OK, so now if we edit one of these files and run git status + again, we will see something odd.

+
+$ vim README
+$ git status -s
+AM README
+A  hello.rb
+
+ +

The 'AM' status means that the file has been modified on disk since we + last added it. This means that if we commit our snapshot right now, we will + be recording the version of the file when we last ran git add, + not the version that is on our disk. Git does not assume that what the file + looks like on disk is necessarily what you want to snapshot - you have to + tell Git with the git add command. +

+ +

+ In a nutshell, + you run git add on a file when you want to + include whatever changes you've made to it in your next commit snapshot. + Anything you've changed that is not added will not be included - this means + you can craft your snapshots with a bit more precision than most other SCM + systems.

+ +

For a very interesting example of using this flexibility to stage only + parts of modified files at a time, see the '-p' option to + git add in the Pro Git book.

+ + +
+ +
+ +
+

+ + docs   + book + + git status + view the status of your files in the working directory and staging area +

+ +
+

As you saw in the git add section, in order to see what the + status of your staging area is compared to the code in your working + directory, you can run the git status command. Using the + -s option will give you short output. + Without that flag, the git status command will give you more + context and hints. Here is the same status output with and without the + -s. The short output looks like this: +

+ +
+$ git status -s
+AM README
+A  hello.rb
+
+ + Where the same status with the long output looks like this: + +
+$ git status
+# On branch master
+#
+# Initial commit
+#
+# Changes to be committed:
+#   (use "git rm --cached <file>..." to unstage)
+#
+# new file:   README
+# new file:   hello.rb
+#
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   README
+#
+
+ +

You can easily see how much more compact the short output is, but the + long output has useful tips and hints as to what commands you may want to + use next. +

+ +

Git will also tell you about files that were deleted since your last + commit or files that were modified or staged since your last commit.

+ +
+$ git status -s
+M  README
+ D hello.rb
+
+ + You can see there are two columns in the short status output. The first + column is for the staging area, the second is for the working directory. + So for example, if you have the README file staged and then you modify + it again without running git add a second time, you'll see + this: + +
+$ git status -s
+MM README
+ D hello.rb
+
+ +

+ In a nutshell, + you run git status to see if anything has been modified + and/or staged since your last commit so you can decide if you want to + commit a new snapshot and what will be recorded in it. +

+ +
+
+ +
+

+ + docs   + book + + git diff + shows diff of what is staged and what is modified but unstaged +

+ +
+

There are two main uses of the git diff command. One use we + will describe here, the other we will describe later in the + "Inspection and Comparison" + section. The way we're going to use it here is to describe the + changes that are staged or modified on disk but unstaged.

+ +

+ git diff + show diff of unstaged changes +

+ +

Without any extra arguments, a simple git diff will display + in unified diff format (a patch) what code or content you've changed in your + project since the last commit that are not yet staged for the next commit + snapshot. +

+ +
+$ vim hello.rb
+$ git status -s
+ M hello.rb
+$ git diff
+diff --git a/hello.rb b/hello.rb
+index d62ac43..8d15d50 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+
+ +

So where git status will show you what files have changed + and/or been staged since your last commit, git diff will + show you what those changes actually are, line by line. It's generally + a good follow-up command to git status +

+ +

+ git diff --cached + show diff of staged changes +

+ +

The git diff --cached command will show you what contents + have been staged. That is, this will show you the changes that will + currently go into the next commit snapshot. So, if you were to stage + the change to hello.rb in the example above, + git diff by itself won't show you any output because it will + only show you what is not yet staged. +

+ +
+$ git status -s
+ M hello.rb
+$ git add hello.rb 
+$ git status -s
+M  hello.rb
+$ git diff
+$ 
+
+ +

If you want to see the staged changes, you can run + git diff --cached instead.

+ +
+$ git status -s
+M  hello.rb
+$ git diff
+$ 
+$ git diff --cached
+diff --git a/hello.rb b/hello.rb
+index d62ac43..8d15d50 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+
+ +

+ git diff HEAD + show diff of all staged or unstaged changes +

+ +

If you want to see both staged and unstaged changes together, you + can run git diff HEAD - this basically means you want to + see the difference between your working directory and the last commit, + ignoring the staging area. If we make another change to our + hello.rb file then we'll have some changes staged and some + changes unstaged. Here are what all three diff commands + will show you:

+
+$ vim hello.rb 
+$ git diff
+diff --git a/hello.rb b/hello.rb
+index 4f40006..2ae9ba4 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
++  # says hello
+   def self.hello
+     puts "hola mundo"
+   end
+
+ end
+$ git diff --cached
+diff --git a/hello.rb b/hello.rb
+index 2aabb6e..4f40006 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+$ git diff HEAD
+diff --git a/hello.rb b/hello.rb
+index 2aabb6e..2ae9ba4 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,8 @@
+ class HelloWorld
+
++  # says hello
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+
+ +

+ git diff --stat + show summary of changes instead of a full diff +

+ +

If we don't want the full diff output, but we want more than the + git status output, we can use the --stat + option, which will give us a summary of changes instead. Here is the + same example as above, but using the --stat option instead. +

+ +
+$ git status -s
+MM hello.rb
+$ git diff --stat
+ hello.rb |    1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+$ git diff --cached --stat
+ hello.rb |    2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+$ git diff HEAD --stat
+ hello.rb |    3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+ +

+ You can also provide a file path at the end of any of these options + to limit the diff output to a specific file or subdirectory. +

+ + +

+ In a nutshell, + you run git diff to see details of the git status + command - how files have been modified or staged on a line by line + basis. +

+ + +
+
+ +
+

+ + docs   + book + + git commit + records a snapshot of the staging area +

+ +
+ +

Now that you have staged the content you want to snapshot with the + git add command, you run git commit to actually + record the snapshot. + Git records your name and email address with every commit you make, + so the first step is to tell Git what these are. +

+ +
+$ git config --global user.name 'Your Name'
+$ git config --global user.email you@somedomain.com
+
+ +

Let's stage and commit all the changes to our + hello.rb file. In this first example, we'll use the + -m option to provide the commit message on the command line. +

+ +
+$ git add hello.rb 
+$ git status -s
+M  hello.rb
+$ git commit -m 'my hola mundo changes'
+[master 68aa034] my hola mundo changes
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+ +

Now we have recorded the snapshot. If we run git status + again, we will see that we have a "clean working directory", which means + that we have not made any changes since our last commit - there is no + un-snapshotted work in our checkout.

+ +
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+
+ +

If you leave off the -m option, Git will try to open a + text editor for you to write your commit message. In vim, + which it will default to if it can find nothing else in your settings, + the screen might look something like this: +

+ +
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   hello.rb
+#
+~
+~
+".git/COMMIT_EDITMSG" 9L, 257C
+
+ +

At this point you add your actual commit message at the top of the + document. Any lines starting with '#' will be ignored - Git will put + the output of the git status command in there for you as + a reminder of what you have modified and staged.

+ +

In general, it's very important to write a good commit message. + For open source projects, it's generally a rule to write your message + more or less in this format:

+ +
+Short (50 chars or less) summary of changes
+
+More detailed explanatory text, if necessary.  Wrap it to about 72
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); some git tools can get confused if you run the
+two together.
+
+Further paragraphs come after blank lines.
+
+ - Bullet points are okay, too
+
+ - Typically a hyphen or asterisk is used for the bullet, preceded by a
+   single space, with blank lines in between, but conventions vary
+   here
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   hello.rb
+#
+~
+~
+~
+".git/COMMIT_EDITMSG" 25L, 884C written
+
+ +

+ The commit message is very important. Since much of the power of + Git is this flexibility in carefully crafting commits locally and then + sharing them later, it is very powerful to be able to write three or + four commits of logically separate changes so that your work may be more + easily peer reviewed. Since there is a separation between committing and + pushing those changes, do take the time to make it easier for the people + you are working with to see what you've done by putting each logically + separate change in a separate commit with a nice commit message so it + is easier for them to see what you are doing and why.

+ +

+ git commit -a + automatically stage all tracked, modified files before the commit +

+ +

If you think the git add stage of the workflow is too + cumbersome, Git allows you to skip that part with the -a + option. This basically tells Git to run git add on any file + that is "tracked" - that is, any file that was in your last commit and + has been modified. This allows you to do a more Subversion style workflow + if you want, simply editing files and then running git commit -a + when you want to snapshot everything that has been changed. You still need + to run git add to start tracking new files, though, just like + Subversion. +

+ +
+$ vim hello.rb
+$ git status -s
+ M  hello.rb
+$ git commit -m 'changes to hello file'
+# On branch master
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   hello.rb
+#
+no changes added to commit (use "git add" and/or "git commit -a")
+$ git commit -am 'changes to hello file'
+[master 78b2670] changes to hello file
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+ +

Notice how if you don't stage any changes and then run + git commit, Git will simply give you the output of the + git status command, reminding you that nothing is staged. + The important part of that message has been highlighted, saying that nothing + is added to be committed. If you use -a, it will add and + commit everything at once. +

+ +

This now lets you complete the entire snapshotting workflow - you + make changes to your files, then use git add to stage + files you want to change, git status and git diff + to see what you've changed, and then finally git commit + to actually record the snapshot forever.

+ +

+ In a nutshell, + you run git commit to record the snapshot of your staged + content. This snapshot can then be compared, shared and reverted to + if you need to. +

+ +
+
+ +
+

+ + docs   + book + + git reset + undo changes and commits +

+ +
+

git reset is probably the most confusing command written + by humans, but it can be very useful once you get the hang of it. + There are three specific invocations of it that are generally + helpful. +

+ +

+ git reset HEAD + unstage files from index and reset pointer to HEAD +

+ +

First, you can use it to unstage something that has been + accidentally staged. Let's say that you have modified two files and want + to record them into two different commits. You should stage and commit + one, then stage and commit the other. If you accidentally stage both of + them, how do you un-stage one? You do it with + git reset HEAD -- file. Technically you don't have to + add the -- - it is used to tell Git when you have stopped + listing options and are now listing file paths, but it's probably good to + get into the habit of using it to separate options from paths even if you + don't need to. +

+ +

Let's see what it looks like to unstage something. Here we have + two files that have been modified since our last commit. We will stage + both, then unstage one of them.

+ +
+$ git status -s
+ M README
+ M hello.rb
+$ git add .
+$ git status -s
+M  README
+M  hello.rb
+$ git reset HEAD -- hello.rb 
+Unstaged changes after reset:
+M hello.rb
+$ git status -s
+M  README
+ M hello.rb
+
+ +

Now you can run a git commit which will just record + the changes to the README file, not the now unstaged + hello.rb. +

+ +

+ In case you're curious, what it's actually doing here is it is resetting + the checksum of the entry for that file in the "index" to be what it was + in the last commit. Since git add checksums a file and adds + it to the "index", git reset HEAD overwrites that with what + it was before, thereby effectively unstaging it. +

+ +

+ If you want to be able to just run git unstage, you can easily + setup an alias in Git. Just run + git config --global alias.unstage "reset HEAD". + Once you have run that, you can then just run + git unstage [file] instead. +

+ +

If you forget the command to unstage something, Git is helpful in + reminding you in the output of the normal git status + command. For example, if you run git status without + the -s when you have staged files, it will tell you + how to unstage them:

+ +
+$ git status
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#   modified:   README
+#   modified:   hello.rb
+#
+
+ +

When you run git reset without specifying a flag + it defaults to --mixed. The other options are + --soft and --hard.

+ +

+ git reset --soft + moves HEAD to specified commit reference, index and staging are untouched +

+ +

The first thing git reset does is undo the last + commit and put the files back onto the stage. If you include the + --soft flag this is where it stops. For example, + if you run git reset --soft HEAD~ (the parent of the + HEAD) the last commit will be undone and the files touched + will be back on the stage again.

+ +
+$ git status -s
+M  hello.rb
+$ git commit -am 'hello with a flower'
+[master 5857ac1] hello with a flower
+ 1 files changed, 3 insertions(+), 1 deletions(-)
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+$ git reset --soft HEAD~
+$ git status -s
+M  hello.rb
+
+ +

This is basically doing the same thing as + git commit --amend, allowing you to do more work + before you roll in the file changes into the same commit.

+ +

+ git reset --hard + unstage files AND undo any changes in the working directory since last commit +

+ +

The third option is to go --hard and make your working + directory look like the index, unstage files and undo any changes made + since the last commit. + This is the most dangerous option and not working directory safe. Any + changes not in the index or have not been commited will be lost.

+ +
+$ git status
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   README
+#
+# Changes not staged for commit:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   README
+#
+$ git reset --hard HEAD
+HEAD is now at 5857ac1 hello with a flower
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+
+ +

In the above example, while we had both changes ready to commit and + ready to stage, a git reset --hard wiped them out. + The working tree and staging area are reset to the tip of the current + branch or HEAD.

+ +

You can replace HEAD with a commit SHA-1 or another + parent reference to reset to that specific point.

+ +

+ In a nutshell, + you run git reset HEAD to undo the last commit, unstage + files that you previously ran git add on and wish to not + include in the next commit snapshot

+ +
+
+ +
+

+ + docs   + book + + git rm + remove files from the staging area +

+ +
+ +

git rm will remove entries from the staging area. + This is a bit different from git reset HEAD which "unstages" + files. To "unstage" means it reverts the staging area to what was + there before we started modifying things. git rm on the + other hand just kicks the file off the stage entirely, so that it's not + included in the next commit snapshot, thereby effectively deleting it.

+ +

By default, a git rm file will remove the file from the + staging area entirely and also off your disk (the working directory). To + leave the file in the working directory, you can use git rm --cached + .

+ +

+ git mv + git rm --cached orig; mv orig new; git add new +

+ +

+ Unlike most other version control systems, Git does not track file renames. + Instead, it just tracks the snapshots and then figures out what files were + likely renamed by comparing snapshots. If a file was removed from one + snapshot and another file was added to the next one and the contents are + similar, Git figures it was most likely a rename. So, although the + git mv command exists, it is superfluous - all it does is a + git rm --cached, moves the file on disk, then runs a + git add on the new file. You don't really need to use it, but + if it's easier, feel free. +

+ +

+ In its normal form the command is used to delete files. + But it's often easier to just remove the files off your disk and + then run git commit -a, which will also automatically remove + them from your index.

+ +

+ In a nutshell, + you run git rm to remove files from being tracked in Git. It + will also remove them from your working directory. +

+ +
+
+ +
+

+ + docs   + book + + git stash + save changes made in the current index and working directory for later +

+ +
+ +

You're in the middle of some changes but something comes up that you + need to jump over to, like a so-urgent-right-now bugfix, but don't want + to commit or lose your current edits. git stash is there for you. +

+ +

+ git stash + add current changes to the stack +

+ +

Stashing takes the current state of the working directory and index, + puts it on a stack for later, and gives you back a clean working directory. + It will then leave you at the state of the last commit. +

+ +

If you have untracked files, git stash will not include + them. You can either stage those files with git add (you don't + have to commit) before stashing, or, if you have a recent Git version + (1.7.7 or above), you can use git stash -u to also stash also + unversioned files.

+ +
+$ git status -s
+M hello.rb
+$ git stash
+Saved working directory and index state WIP on master: 5857ac1 hello with a flower
+HEAD is now at 5857ac1 hello with a flower
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+
+ +

+ git stash list + view stashes currently on the stack +

+ +

It's helpful to know what you've got stowed on the stash and this is where + git stash list comes in. Running this command will display a queue + of current stash items. +

+ +
+$ git stash list
+stash@{0}: WIP on master: 5857ac1 hello with a flower
+
+ +

The last item added onto the stash will be referenced by + stash@{0} and increment those already there by one. +

+ +
+$ vim hello.rb
+$ git commit -am 'it stops raining'
+[master ee2d2c6] it stops raining
+1 files changed, 1 insertions(+), 1 deletions(-)
+$ vim hello.rb
+$ git stash
+Saved working directory and index state WIP on master: ee2d2c6 it stops raining
+HEAD is now at ee2d2c6 it stops raining
+$ git stash list
+stash@{0}: WIP on master: ee2d2c6 it stops raining
+stash@{1}: WIP on master: 5857ac1 hello with a flower
+
+ +

+ git stash apply + grab the item from the stash list and apply to current working directory +

+ +

When you're ready to continue from where you left off, run the + git stash apply command to bring back the saved changes + onto the working directory. +

+ +
+$ git stash apply
+# On branch master
+# Changes not staged for commit:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   hello.rb
+#
+no changes added to commit (use "git add" and/or "git commit -a")
+
+ +

By default it will reapply the last added stash item to the working + directory. This will be the item referenced by stash@{0}. + You can grab another stash item instead if you reference it in the arguments + list. For example, git stash apply stash@{1} will apply the item + referenced by stash@{1}. +

+ +

If you also want to remove the item from the stack at the same time, + use git stash pop instead. +

+ +

+ git stash drop + remove an item from the stash list +

+ +

When you're done with the stashed item and/or want to remove it from the + list, run the git stash drop command. By default this will + remove the last added stash item. You can also remove a specific item if + you include it as an argument. +

+ +

In this example, our stash list has at least two items, but we want + to get rid of the item added before last, which is referenced by + stash@{1}. +

+ +
+$ git stash drop stash@{1}
+Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
+
+ +

If you want to remove of all the stored items, just run + the git stash clear command. But only do this if you're + sure you're done with the stash. +

+ +

+ In a nutshell, run git stash to quickly save + some changes that you're not ready to commit or save, but want to come + back to while you work on something else. +

+ +
+
+ +

On to Branching and Merging »

+ diff --git a/fr/branching/index.html b/fr/branching/index.html new file mode 100644 index 0000000..96112be --- /dev/null +++ b/fr/branching/index.html @@ -0,0 +1,864 @@ +--- +layout: reference +--- + +
+

+ + book + + Branching and Merging +

+
+

Branching in Git is one of its many great features. If you have used other + version control systems, it's probably helpful to forget most of what you + think about branches - in fact, it may be more helpful to think of them + practically as contexts since that is how you will most often be + using them. When you checkout different branches, you change contexts + that you are working in and you can quickly context-switch back and forth + between several different branches. +

+ +

+ In a nutshell you can create a branch with + git branch (branchname), switch into that context with + git checkout (branchname), record commit snapshots while + in that context, then can switch back and forth easily. When you switch + branches, Git replaces your working directory with the snapshot of the + latest commit on that branch so you don't have to have multiple directories + for multiple branches. You merge branches together with + git merge. You can easily merge multiple times from the same + branch over time, or alternately you can choose to delete a branch + immediately after merging it. +

+ +
+
+ +
+

+ + docs   + book + + git branch + list, create and manage working contexts +

+ +
+ +

+ + docs   + book + + git checkout + switch to a new branch context +

+ +
+

The git branch command is a general branch management tool + for Git and can do several different things. We'll cover the basic ones + that you'll use most - listing branches, creating branches and deleting + branches. We will also cover basic git checkout here which + switches you between your branches. +

+ +

+ git branch + list your available branches +

+ +

Without arguments, git branch will list out the local + branches that you have. The branch that you are currently working on will + have a star next to it and if you have + coloring turned on, + will show the current branch in green. +

+ +
+$ git branch
+* master
+
+ +

This means that we have a 'master' branch and we are currently on it. + When you run git init it will automatically create a 'master' + branch for you by default, however there is nothing special about the name - + you don't actually have to have a 'master' branch but since it's the default + that is created, most projects do. +

+ +

+ git branch (branchname) + create a new branch +

+ +

So let's start by creating a new branch and switching to it. You can do + that by running git branch (branchname). +

+ +
+$ git branch testing
+$ git branch
+* master
+  testing
+
+ +

Now we can see that we have a new branch. When you create a branch this + way it creates the branch at your last commit so if you record some commits + at this point and then switch to 'testing', it will revert your working + directory context back to when you created the branch in the first place - + you can think of it like a bookmark for where you currently are. Let's see + this in action - we use git checkout (branch) to switch the + branch we're currently on. +

+ +
+$ ls
+README   hello.rb
+$ echo 'test content' > test.txt
+$ echo 'more content' > more.txt
+$ git add *.txt
+$ git commit -m 'added two files'
+[master 8bd6d8b] added two files
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 more.txt
+ create mode 100644 test.txt
+$ ls
+README   hello.rb more.txt test.txt
+$ git checkout testing
+Switched to branch 'testing'
+$ ls
+README   hello.rb
+
+ +

So now we can see that when we switch to the 'testing' branch, our new + files were removed. We could switch back to the 'master' branch and see + them re-appear.

+ +
+$ ls
+README   hello.rb
+$ git checkout master
+Switched to branch 'master'
+$ ls
+README   hello.rb more.txt test.txt
+
+ +

+ git branch -v + see the last commit on each branch +

+ +

If we want to see last commits on each branch + we can run git branch -v to see them.

+ +
+$ git branch -v
+* master      54b417d fix javascript issue
+  development 74c111d modify component.json file
+  testing     62a557a update test scripts
+
+ +

+ git checkout -b (branchname) + create and immediately switch to a branch +

+ +

+ In most cases you will be wanting to switch to the branch immediately, so + you can do work in it and then merging into a branch that only contains + stable work (such as 'master') at a later point when the work in your new + context branch is stable. You can do this pretty easily with + git branch newbranch; git checkout newbranch, but Git gives + you a shortcut for this: git checkout -b newbranch. +

+ +
+$ git branch
+* master
+$ ls
+README   hello.rb more.txt test.txt
+$ git checkout -b removals
+Switched to a new branch 'removals'
+$ git rm more.txt 
+rm 'more.txt'
+$ git rm test.txt 
+rm 'test.txt'
+$ ls
+README   hello.rb
+$ git commit -am 'removed useless files'
+[removals 8f7c949] removed useless files
+ 2 files changed, 0 insertions(+), 2 deletions(-)
+ delete mode 100644 more.txt
+ delete mode 100644 test.txt
+$ git checkout master
+Switched to branch 'master'
+$ ls
+README   hello.rb more.txt test.txt
+
+ +

You can see there how we created a branch, removed some of our files + while in the context of that branch, then switched back to our main branch + and we see the files return. Branching safely isolates work that we do into + contexts we can switch between.

+ +

+ If you start on work it is very useful to + always start it in a branch (because it's fast and easy to do) and then + merge it in and delete the branch when you're done. That way if what you're + working on doesn't work out you can easily discard it and if you're forced + to switch back to a more stable context your work in progress is easy to put + aside and then come back to.

+ +

+ git branch -d (branchname) + delete a branch +

+ +

If we want to delete a branch (such as the 'testing' branch in the + previous example, since there is no unique work on it), + we can run git branch -d (branch) to remove it.

+ +
+$ git branch
+* master
+  testing
+$ git branch -d testing
+Deleted branch testing (was 78b2670).
+$ git branch
+* master
+
+ +

+ git push (remote-name) :(branchname) + delete a remote branch +

+ +

When you're done with a remote branch, whether it's been merged + into the remote master or you want to abandon it and sweep it under + the rug, you'll issue a git push command with a specially + placed colon symbol to remove that branch.

+ +
+$ git push origin :tidy-cutlery
+To git@github.com:octocat/Spoon-Knife.git
+ - [deleted]         tidy-cutlery
+
+ +

In the above example you've deleted the "tidy-cutlery" branch + of the "origin" remote. A way to remember this is to think of the + git push remote-name local-branch:remote-branch syntax. + This states that you want to push your local branch to match that + of the remote. When you remove the local-branch portion + you're now matching nothing to the remote, effectively telling the + remote branch to become nothing. +

+ +

Alternatively, you can run + git push remote-name --delete branchname + which is a wrapper for the colon refspec (a source:destination pair) + of deleting a remote branch. +

+ +

+ In a nutshell you use git branch to list your + current branches, create new branches and delete unnecessary or + already merged branches. +

+ +
+
+ +
+

+ + docs   + book + + git merge + merge a branch context into your current one +

+ +
+

Once you have work isolated in a branch, you will eventually want to + incorporate it into your main branch. You can merge any branch into your + current branch with the git merge command. Let's take as a + simple example the 'removals' branch from above. If we create a branch + and remove files in it and commit our removals to that branch, it is + isolated from our main ('master', in this case) branch. To include those + deletions in your 'master' branch, you can just merge in the 'removals' + branch. +

+ +
+$ git branch
+* master
+  removals
+$ ls
+README   hello.rb more.txt test.txt
+$ git merge removals
+Updating 8bd6d8b..8f7c949
+Fast-forward
+ more.txt |    1 -
+ test.txt |    1 -
+ 2 files changed, 0 insertions(+), 2 deletions(-)
+ delete mode 100644 more.txt
+ delete mode 100644 test.txt
+$ ls
+README   hello.rb
+
+ +

+ more complex merges +

+ +

Of course, this doesn't just work for simple file additions and + deletions. Git will merge file modifications as well - in fact, it's very + good at it. For example, let's see what happens when we edit a file in + one branch and in another branch we rename it and then edit it and then + merge these branches together. Chaos, you say? Let's see. +

+ +
+$ git branch
+* master
+$ cat hello.rb 
+class HelloWorld
+  def self.hello
+    puts "Hello World"
+  end
+end
+
+HelloWorld.hello
+
+ +

So first we're going to create a new branch named 'change_class' and + switch to it so your class renaming changes are isolated. We're going to + change each instance of 'HelloWorld' to 'HiWorld'.

+ +
+$ git checkout -b change_class
+Switched to a new branch 'change_class'
+$ vim hello.rb 
+$ head -1 hello.rb 
+class HiWorld
+$ git commit -am 'changed the class name'
+[change_class 3467b0a] changed the class name
+ 1 files changed, 2 insertions(+), 4 deletions(-)
+
+ +

So now we've committed the class renaming changes to the 'change_class' + branch. To switch back to the 'master' branch the class name will + revert to what it was before we switched branches. Here we can change + something different (in this case the printed output) and at the same + time rename the file from hello.rb to ruby.rb. +

+ +
+$ git checkout master
+Switched to branch 'master'
+$ git mv hello.rb ruby.rb
+$ vim ruby.rb 
+$ git diff
+diff --git a/ruby.rb b/ruby.rb
+index 2aabb6e..bf64b17 100644
+--- a/ruby.rb
++++ b/ruby.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "Hello World"
++    puts "Hello World from Ruby"
+   end
+
+ end
+$ git commit -am 'added from ruby'
+[master b7ae93b] added from ruby
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+ rename hello.rb => ruby.rb (65%)
+
+ +

Now those changes are recorded in the 'master' branch. Notice that the + class name is back to 'HelloWorld', not 'HiWorld'. To incorporate + the 'HiWorld' change we can just merge in the 'change_class' + branch. However, the name of the file has changed since we branched, + what will Git do?

+ +
+$ git branch
+  change_class
+* master
+$ git merge change_class
+Renaming hello.rb => ruby.rb
+Auto-merging ruby.rb
+Merge made by recursive.
+ ruby.rb |    6 ++----
+ 1 files changed, 2 insertions(+), 4 deletions(-)
+$ cat ruby.rb
+class HiWorld
+  def self.hello
+    puts "Hello World from Ruby"
+  end
+end
+
+HiWorld.hello
+
+ +

Well, it will just figure it out. Notice that there are no merge conflicts + and the file that had been renamed now has the 'HiWorld' class name change + that was done in the other branch. Pretty cool.

+ +

+ merge conflicts +

+ +

So, Git merges are magical, we never ever have to deal with merge + conflicts again, right? Not quite. In situations where the same block + of code is edited in different branches there is no way for a computer + to figure it out, so it's up to us. Let's see another example of changing + the same line in two branches. +

+ +
+$ git branch
+* master
+$ git checkout -b fix_readme
+Switched to a new branch 'fix_readme'
+$ vim README 
+$ git commit -am 'fixed readme title'
+[fix_readme 3ac015d] fixed readme title
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+ +

Now we have committed a change to one line in our README file in a + branch. Now let's change the same line in a different way back on + our 'master' branch.

+ +
+$ git checkout master
+Switched to branch 'master'
+$ vim README 
+$ git commit -am 'fixed readme title differently'
+[master 3cbb6aa] fixed readme title differently
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+ +

Now is the fun part - we will merge the first branch into our master + branch, causing a merge conflict.

+ +
+$ git merge fix_readme
+Auto-merging README
+CONFLICT (content): Merge conflict in README
+Automatic merge failed; fix conflicts and then commit the result.
+$ cat README 
+<<<<<<< HEAD
+Many Hello World Examples
+=======
+Hello World Lang Examples
+>>>>>>> fix_readme
+
+This project has examples of hello world in
+nearly every programming language.
+
+ +

You can see that Git inserts standard merge conflict markers, much like + Subversion, into files when it gets a merge conflict. Now it's up to us + to resolve them. We will do it manually here, but check out + git mergetool + if you want Git to fire up a graphical mergetool + (like kdiff3, emerge, p4merge, etc) instead. +

+ +
+$ vim README   # here I'm fixing the conflict
+$ git diff
+diff --cc README
+index 9103e27,69cad1a..0000000
+--- a/README
++++ b/README
+@@@ -1,4 -1,4 +1,4 @@@
+- Many Hello World Examples
+ -Hello World Lang Examples
+++Many Hello World Lang Examples
+
+  This project has examples of hello world in
+
+ +

A cool tip in doing merge conflict resolution in Git is that if you + run git diff, it will show you both sides of the conflict + and how you've resolved it as shown here. Now it's time to mark + the file as resolved. In Git we do that with git add - + to tell Git the file has been resolved you have to stage it.

+ +
+$ git status -s
+UU README
+$ git add README 
+$ git status -s
+M  README
+$ git commit 
+[master 8d585ea] Merge branch 'fix_readme'
+
+ +

And now we've successfully resolved our merge conflict and committed + the result.

+ +

+ In a nutshell you use git merge to combine another + branch context into your current branch. It automatically figures out + how to best combine the different snapshots into a new snapshot with the + unique work of both. +

+ +
+
+ +
+

+ + docs   + book + + git log + show commit history of a branch +

+ +
+ +

So far we have been committing snapshots of your project and switching + between different isolated contexts, but what if we've forgotten how we've + got to where we are? Or what if we want to know how one branch differs + from another? Git provides a tool that shows you all the commit messages + that have lead up to the snapshot you are currently on, which is called + git log.

+ +

To understand the log command, you have to understand what information + is stored when you run the git commit command to store a + snapshot. In addition to the manifest of files and commit message and + information about the person who committed it, Git also stores the commit + that you based this snapshot on. That is, if you clone a project, what was + the snapshot that you modified to get to the snapshot that you saved? This + is helpful to give context to how the project got to where it is and allows + Git to figure out who changed what. If Git has the snapshot you save and + the one you based it on, then it can automatically figure out what you + changed. The commit that a new commit was based on is called the "parent". +

+ +

To see a chronological list of the parents of any branch, you can run + git log when you are in that branch. For example, if we run + git log in the Hello World project that we have been working + on in this section, we'll see all the commit messages that we've done. +

+ +
+$ git log
+commit 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
+Merge: 3cbb6aa 3ac015d
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:59:47 2010 +0200
+
+    Merge branch 'fix_readme'
+
+    Conflicts:
+        README
+
+commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:53 2010 +0200
+
+    fixed readme title differently
+
+commit 3ac015da8ade34d4c7ebeffa2053fcac33fb495b
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:36 2010 +0200
+
+    fixed readme title
+
+commit 558151a95567ba4181bab5746bc8f34bd87143d6
+Merge: b7ae93b 3467b0a
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:37:05 2010 +0200
+
+    Merge branch 'change_class'
+...
+
+ +

To see a more compact version of the same history, we can use the + --oneline option.

+ +
+$ git log --oneline
+8d585ea Merge branch 'fix_readme'
+3cbb6aa fixed readme title differently
+3ac015d fixed readme title
+558151a Merge branch 'change_class'
+b7ae93b added from ruby
+3467b0a changed the class name
+17f4acf first commit
+
+ +

What this is telling us is that this is the history of the development + of this project. If the commit messages are descriptive, this can inform + us as to what all changes have been applied or have influenced the current + state of the snapshot and thus what is in it.

+ +

We can also use it to see when the history was branched and merged with + the very helpful --graph option. Here is the same command + but with the topology graph turned on:

+ +
+$ git log --oneline --graph
+*   8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+*   558151a Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+
+ +

Now we can more clearly see when effort diverged and then was merged + back together. This is very nice for seeing what has happened or what + changes are applied, but + it is also incredibly useful for managing your branches. Let's create a new + branch, do some work in it and then switch back and do some work in our + master branch, then see how the log command can help us figure + out what is happening on each.

+ +

First we'll create a new branch to add the Erlang programming language + Hello World example - we want to do this in a branch so that we don't + muddy up our stable branch with code that may not work for a while so we + can cleanly switch in and out of it.

+ +
+$ git checkout -b erlang
+Switched to a new branch 'erlang'
+$ vim erlang_hw.erl
+$ git add erlang_hw.erl 
+$ git commit -m 'added erlang'
+[erlang ab5ab4c] added erlang
+ 1 files changed, 5 insertions(+), 0 deletions(-)
+ create mode 100644 erlang_hw.erl
+
+ +

Since we're having fun playing in functional programming languages we + get caught up in it and also add a Haskell example program while still in + the branch named 'erlang'.

+ +
+$ vim haskell.hs
+$ git add haskell.hs 
+$ git commit -m 'added haskell'
+[erlang 1834130] added haskell
+ 1 files changed, 4 insertions(+), 0 deletions(-)
+ create mode 100644 haskell.hs
+
+ +

Finally, we decide that we want to change the class name of our Ruby + program back to the way it was. So, we can go back to the master branch + and change that and we decide to just commit it directly in the master + branch instead of creating another branch.

+ +
+$ git checkout master
+Switched to branch 'master'
+$ ls
+README  ruby.rb
+$ vim ruby.rb 
+$ git commit -am 'reverted to old class name'
+[master 594f90b] reverted to old class name
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+
+ +

So, now say we don't work on the project for a while, we have other + things to do. When we come back we want to know what the 'erlang' branch + is all about and where we've left off on the master branch. Just by looking + at the branch name, we can't know that we made Haskell changes in there, but + using git log we easily can. If you give Git a branch name, + it will show you just the commits that are "reachable" in the history of + that branch, that is the commits that influenced the final snapshot.

+ +
+$ git log --oneline erlang
+1834130 added haskell
+ab5ab4c added erlang
+8d585ea Merge branch 'fix_readme'
+3cbb6aa fixed readme title differently
+3ac015d fixed readme title
+558151a Merge branch 'change_class'
+b7ae93b added from ruby
+3467b0a changed the class name
+17f4acf first commit
+
+ +

This way, it's pretty easy to see that we have Haskell code included in + the branch (highlighted in the output). What is even cooler is that we can + easily tell Git that we only are interested in the commits that are + reachable in one branch that are not reachable in another, in other words + which commits are unique to a branch in comparison to another. +

+ +

+ In this case if we are interested in merging in the 'erlang' branch we + want to see what commits are going to effect our snapshot when we do + that merge. The way we tell Git that is by putting a ^ in + front of the branch that we don't want to see. For instance, if we want + to see the commits that are in the 'erlang' branch that are not in the + 'master' branch, we can do erlang ^master, or vice versa. + Note that the Windows command-line treats ^ as a special + character, in which case you'll need to surround ^master + in quotes. +

+ +
+$ git log --oneline erlang ^master
+1834130 added haskell
+ab5ab4c added erlang
+$ git log --oneline master ^erlang
+594f90b reverted to old class name
+
+ +

This gives us a nice, simple branch management tool. It allows us to + easily see what commits are unique to which branches so we know what + we're missing and what we would be merging in if we were to do a merge. +

+ +

+ In a nutshell you use git log to list out the commit + history or list of changes people have made that have lead to the snapshot + at the tip of the branch. This allows you to see how the project in that + context got to the state that it is currently in. +

+ +
+
+ +
+

+ + docs   + book + + git tag + tag a point in history as important +

+ +
+ +

+ If you get to a point that is important and you want to forever remember + that specific commit snapshot, you can tag it with git tag. + The tag command will basically put a permanent bookmark at + a specific commit so you can use it to compare to other commits in the + future. This is often done when you cut a release or ship something. +

+ +

Let's say we want to release our Hello World project as version "1.0". + We can tag the last commit (HEAD) as "v1.0" by running + git tag -a v1.0. The -a means "make an annotated + tag", which allows you to add a tag message to it, which is what you almost + always want to do. Running this without the -a works too, but + it doesn't record when it was tagged, who tagged it, or let you add a tag + message. It's recommended you always create annotated tags.

+ +
+$ git tag -a v1.0 
+
+ +

When you run the git tag -a command, Git will open your editor + and have you write a tag message, just like you would write a commit + message.

+ +

Now, notice when we run git log --decorate, we can see our + tag there.

+ +
+$ git log --oneline --decorate --graph
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+*   8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d (fix_readme) fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+*   558151a Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+
+ +

If we do more commits, the tag will stay right at that commit, so we have + that specific snapshot tagged forever and can always compare future + snapshots to it.

+ +

We don't have to tag the commit that we're on, however. If we forgot to + tag a commit that we released, we can retroactively tag it by running the + same command, but with the commit SHA at the end. For example, say we had + released commit 558151a (several commits back) but forgot to + tag it at the time. We can just tag it now:

+ +
+$ git tag -a v0.9 558151a
+$ git log --oneline --decorate --graph
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+*   8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d (fix_readme) fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+*   558151a (tag: v0.9) Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+
+ +

Tags pointing to objects tracked from branch heads will be + automatically downloaded when you fetch from a remote + repository. However, tags that aren't reachable from branch heads + will be skipped. If you want to make sure all tags are always + included, you must include the --tags option. +

+ +
+$ git fetch origin --tags
+remote: Counting objects: 1832, done.
+remote: Compressing objects: 100% (726/726), done.
+remote: Total 1519 (delta 1000), reused 1202 (delta 764)
+Receiving objects: 100% (1519/1519), 1.30 MiB | 1.21 MiB/s, done.
+Resolving deltas: 100% (1000/1000), completed with 182 local objects.
+From git://github.com:example-user/example-repo
+ * [new tag]         v1.0       -> v1.0
+ * [new tag]         v1.1       -> v1.1
+
+ +

If you just want a single tag, use + git fetch <remote> tag <tag-name>. +

+ +

By default, tags are not included when you push to + a remote repository. In order to explicitly update these you must + include the --tags option when using git push. +

+ +

+ In a nutshell you use git tag to mark a + commit or point in your repo as important. This also allows + you to refer to that commit with a more memorable reference + than a SHA. +

+ +
+
+ +

On to Sharing and Updating Projects »

+ diff --git a/fr/cookbook.html b/fr/cookbook.html new file mode 100644 index 0000000..7818f55 --- /dev/null +++ b/fr/cookbook.html @@ -0,0 +1,12 @@ +--- +layout: reference +--- +
+

Git Cookbook

+ +
diff --git a/fr/creating/index.html b/fr/creating/index.html new file mode 100644 index 0000000..449859a --- /dev/null +++ b/fr/creating/index.html @@ -0,0 +1,142 @@ +--- +layout: reference +--- + +
+

Getting and Creating Projects

+
+

+ In order to do anything in Git, you have to have a Git repository. This + is where Git stores the data for the snapshots you are saving. +

+ +

+ There are two main ways to get a Git repository. One way is to simply + initialize a new one from an existing directory, such as a new project or + a project new to source control. The second way is to clone one from a + public Git repository, as you would do if you wanted a copy or wanted to + work with someone on a project. We will cover both of these here. +

+ +
+
+ +
+

+ + docs   + book + + git init + initializes a directory as a Git repository +

+ +
+

To create a repository from an existing directory of files, you can + simply run git init in that directory. For example, + let's say we have a directory with a few files in it, like this: +

+ +
+$ cd konnichiwa
+$ ls
+README   hello.rb
+
+ +

This is a project where we are writing examples of the "Hello World" + program in every language. So far, we just have Ruby, but hey, it's + a start. To start version controlling this with Git, we can simply + run git init. +

+ +
+$ git init
+Initialized empty Git repository in /opt/konnichiwa/.git/
+
+ +

Now you can see that there is a .git subdirectory in your + project. This is your Git repository where all the data of your + project snapshots are stored. +

+ +
+$ ls -a
+.        ..       .git     README   hello.rb
+
+ +

Congratulations, you now have a skeleton Git repository and can start + snapshotting your project. +

+ +

+ In a nutshell, you use git init to make an + existing directory of content into a new Git repository. You can do this + in any directory at any time, completely locally.

+ +
+
+ +
+

+ + docs   + book + + git clone + copy a git repository so you can add to it +

+
+

+ If you need to collaborate with someone on a project, or if you want to + get a copy of a project so you can look at or use the code, you will + clone it. You simply run the git clone [url] command with + the URL of the project you want to copy. +

+ +
+$ git clone git://github.com/schacon/simplegit.git
+Initialized empty Git repository in /private/tmp/simplegit/.git/
+remote: Counting objects: 100, done.
+remote: Compressing objects: 100% (86/86), done.
+remote: Total 100 (delta 35), reused 0 (delta 0)
+Receiving objects: 100% (100/100), 9.51 KiB, done.
+Resolving deltas: 100% (35/35), done.
+$ cd simplegit/
+$ ls
+README   Rakefile lib
+
+ +

+ This will copy the entire history of that project so you have it locally + and it will give you a working directory of the main branch of that project + so you can look at the code or start editing it. If you change into the + new directory, you can see the .git subdirectory - that is + where all the project data is. +

+ +
+$ ls -a
+.        ..       .git     README   Rakefile lib
+$ cd .git
+$ ls
+HEAD        description info        packed-refs
+branches    hooks       logs        refs
+config      index       objects
+
+ +

+ By default, Git will create a directory that is the same name as the + project in the URL you give it - basically whatever is after the last slash + of the URL. If you want something different, you can just put it at the + end of the command, after the URL. +

+ +

+ In a nutshell, you use git clone to get a + local copy of a Git repository so you can look at it or start modifying + it.

+ +
+
+ +

On to Basic Snapshotting »

diff --git a/fr/images/snapshots.png b/fr/images/snapshots.png new file mode 100644 index 0000000000000000000000000000000000000000..fe87f63ea144124fce16c89d19efe8db6c1bbdbf GIT binary patch literal 23231 zcmZs?b95!!^FExMiEZ0||owHs0Lt{oLPQ?^>sO^{U>x zc6aTwtLk}bcbL4aI6Mpv3Oc( z0wJQ~r5K$Q(bMmUr~vUs>-9yK_vMwpeu#>mZ)j=~`SB5Q{)!4>RT^ya-IJV`o={5( zF* zHtSn7*BT=y9(o?L?TYuuOgBhqwwTr1TfSF62ofm>$Z1HBXs&x$)Gv|?Tgnlie(4kdWHGw3rbfA{rbgwPFE(T@>paJI8tXX>B3wv1A^=1$fD@Du31SBb zK?P9Bg?98qW`g|Q3)%{TxCQGE#0mvm6Jeiy!zO~<3m}n)k@cI~;%x6wYzXovW z1;GN4>Z5f6=C=5r02sevzyw`G;h2T-kO;{Dl7cX?IEC=of*7&*djK~>hR5~CG)L*j5J$Q*UX<}+LLyH2@H087GIT`Ql+GwQC<1Y{WV-PvBmR5R zD?ez+7UJ3^jSAgZ(qu?~#bpg|?*;5h+2gvUzQy?$K*_UFAtc&LQ51#G%DPECOUV^u z7W^&Q6wCqYN$AOK$_ey?uwF5nF>x}BFyon)8XXzA_Cqn>Fk7%#|BN)EGqyCwGtM+3 zVF_c!W_@NZVpU;rV(Bt|85|$$Oj?fO3TsPjOM2$Im7}3l$vP4Gk)Nzsqx7e=g07Qp zg)W=!RlQu@UA%ioA_4q|!cAxH` zcgQ;*+@f#Rw$iqX4psK=cP0+3cD#Ov>?RyK?5|F_gk53_1nUL+@c3|l zl7AcmLVY`ZGkOL6DEy!W^K;8{YxJ}AJGLs3Dq_3k3#Xy;yz|HnkPSSxz54F^7|o2+ zA?Q<8Wjchl(DK4KLklC=!eqi&B2FU2!c-#=A`Au+2i^vw!|ucB!=%GI!U$0=kv>U? z$+oHNw=Lr=->ZNt-BG?*QBu)T!CXL_@0+(+Fr5!t=$e-+ zjj^cx#c76S#yeeTrfFts{$M?5#lDu_-6Rb=JG-z_;G}e#(%kG^?i}*Kh>xGe$DP#< zRFmWQ(ISpm@iRZA>~D?SV#}gHzJO(~Y3+LMxPG7f^z>%!knN z`lfED>ibamoFBPA3MRs<;;gdIZ><`wwpTUJk$7-B6g$j4z+a7D`5`eN8ABov1n{Hq zVe$01C3(oX?ztN{UpYBAKUb{Vx*T6CBhsaV$3kf**oT@{qfQP^otN=C!UYRh`{KKH(V{Vw3@A~PeWAn_5Jjc-gZ#xh6h$1TQ9$7Cn7 zN0}$u635~@cwA0mkMmyo&q9Z;B+3oiByve>v z#i`OM&50J1grT$h$kA>qezK_8{rUwJUIrc#R~6TVy}PS(_r^9sV{U?$MvdY7T>4lw zi{3;#gpPFQLlb$cN&Q08y+Vel)|Auv>ED(8)n7K#)|qEpXH=b%KCBg}$7^$Kp0pQ> zf2(V&moI!T$_S>iuU8pba@Oj4ZfpOxKkDYVZLW7vxLn@h-ao=&!8xwa^|+jNZ@g;- zyaebV!Vx$kVk4}(ncdW0#yuB!^e^@c$D9)iU@!BtJPhoP%qxACG)(nndwCJOdb&AI zVVTl7WO{dAfgeUBpf-lBq`)xNbj^A@dCc0|yN)_poZL_T-P|Di(Lcw-hO3sPEB|`^YkCvo5d1Z2?WM$KP{S$jP!3PKCQwHqY1o+1Rz{kO_ zr>%EWd&`F5s^$Oh_u0aLbd0~>l?JOn&4-5s(%a$yBCidSivSAjd$YOkaZB7>hUm>L zoQ9|i6m)~aVFJ1ZTQEh{gF#OtRRaDR7&D!Rverji^`HM zvtjB1LoGZb!s9vGPL6?*@)D5q>J8@e?(5~};;-Qh5y%$u0hJPQ70z3KDm$+kX>X~% zcKj43l2@3zu0;J&mh%8{cKYMznvDk$SmZasX>|~i=w&upJY=~*-E7|yf&I0T?}tRlY=kP z!uJmFrzzAw@YJ3%f@)@~XEX;ii&oKUXj{hCw=RL)8ylWWZikEK)g9}P?icIb9wj9$ z1vTf^zdoD%hCGrU8z4yuI1#b=mA%Qnk6&ZGx>_3_jU<&&W}67eVclc1Vjbe-c+GIf zeX_hIo$n=6CzsjO5O%h)dAU;DR88>Yxg<3BH8@-fPrEB$XAX+L{kf1c&w=mO@454y zcroRdOSRFM)-coF)0NTod|1DDy(I({I7oT;DE!oDrmI`4H*8~RNN*^v|9)Fxyl(I1 zD>a7I$-drN?T@4nr zOz^n*ysj!jGt)yyCX03vuj>X`cMQPKzb2^5j8PQEJ3g@_7>_lRSNJp{}R z5!6yV?rP&jOV6$ofr$gZBrg-%l<1TmFU(hXvW60?>o>Q1CnNU)LRjTYbjGd6jz_v& z%=WIvI@{hB00%JVsbv*lO1Kj zx^U@!>6~~n2I@w(qv_?W)z&cI+I!Dk(=JRzsdd!wS-Z`>G+7nlw+Wu;w~s82xJ8si z^kgiOx_OM@XX%ddmvmUauR@+(YOMVwocGLSBYTxUL;hqsHQL#2ii?pG%X#4Kxa;&} z`$^}rGdCacj~-{IXL zF>DX`Ebf4WFxvYqk-5=7JWpc@$_v8Q5C)0H9;E~P6)7b&Wk3$4{J1adg^XYp=9zsT z`CTWNVMt4+Ydoe*iEeW_^o#^=C9_)ldQIG|`U>HC0(uJ^Jg^z+bf!||Oyqo!ZqSLm zkgO~|La~1~ip8xy&wlYH9A+(?b8wKJRZ1@DRasMcsvKWsvjjQsxP3ugS};Q`q_m;% zRrNB>yXH50zk}GH$hjZRY3`|M8MKz;SAcU8#6rD4aUMrma;c{F@ZXxtwiRqjrXqV-Gps&{*wn7V-r5d+&3bO{jK@FToN0~^y?h?bacn?y zqJu=wfo|~ve60{cmWioaKEU^T!j8DWK_Hz#=pz**OKVkrVqPM~2OwT@Yi2#~?U6b1-T zAgLqge;kmA$GuXsjp~kqbz!_yCvw3XV;L(ORO*wkk~2*(t+Kkv50*a96Vh$aJ*u;- zGuA@aC)Fw~-*QsnwPm7BdNN>CD_VPB%<&rX9=a8|;XbiFy*%?hr+~qL6@gzuxxv1p zFqBvobs?2iS&Y_>8wxIivY|}F{rje3UvQuQy7ZBeHJ_KfV@v3-B<;m5#jO8lk z*e6JZS)^+wx`&F@n)a&7(L-9H;o+l43S3rR8DHex*aD(6X~Jb#E+UpGc=lpZOcx4W!Xxikx0^Y;fx$3*j+ zU@>~4e~Rtn-x=&V+;<*4R_6SukmJZ9fl%k-X^X!idJAR7a{8>G%!JGSI4$w|@nMpH1=_tLFBbLt|)*4|b${4;JMjuL;AfJ+&$V*m4+C=0f zI3$-W{!pf!*VzRq>1#9`O9m84>|4=Dm9JT-H;LZ6;Gm|*v>=$R&sr~Xm1tGE00kzA z)|kerhBznoT945iC=bSxJ5{+Cb-y1s|7>1w&S=zgHg=A8Xx_{|QM}|npX}-HFX(ev z(ORKgd2AQ>-pgG}W#(9-FJX2RWt$utI{cd|=qO&@Qrq%PCSQ8C%lJI;h0oI?rZ8?6 z7BSS+(bU~EAhTR}DCF=a0#*k0Z@6ZJl62*$*?t8jp=xH?ir30Hw>h-VhjaQpP^ zobF7&kZrUAs9kajr(%9n%!8PDM-1y^+RE>h4wh|a^=JKfBbkPoq}q^eO>Jtf+^%!a zku%-?&VK5G8ov>Rn)>qC+*aZxT8@yJ1?=FV#lp--Fv{@E8L`KMm~(6p6%T9i%i*#CLU8h+IzoZ z!^Q6vS09jkK@l^NMBgI6?Stdbbp|>%jPu)-wbU6tF5Y?ff)?2GZNTMQCp`T$DdNj3 zI(GXqWXK9o`(r!$q15u5bjYjv>RUk5xBSR+`N-%XOH!jd4kpO(ZzM*R_#bg46yVtE z1*wsvF)!k{@7GFobE|mgg5T~+-|Uquvq;0usV*X;8#siRNy9hEz_~a-jT*KNZJuKA zg1`AkO?a>Nj{jyh#jR7HMr6v1g^Gyc%B|B!*9R5y69^UM>3*BBlz~vs-!uvSJTn1; zT#2#Ul``N2`eLJnXD4(_yeB5`_Ui{+So$}hwnDTpK@dx^l#h|T+f^ab03 zVv9g42;U*$i=Zx)eKWd(xW{|?8IAkV&j2}qA0shu3nSEo`?-D?gTZN~3HkZ@?2`cs zMUdI?{qZM++2@|A9FcnwD1uJO%^Uo@Nq95dM+*Ir0I{jCF%ohb7CIgl8fk8b^N$y4 z*wmocQ7KreQQF}EpKq~|H*QQC{(@ipJ+!TahQk+ukMhp}`ZH(ti{2*!krWYB{vz=GxNtm=Vd~9O^aQuPQyG&nz3!41d$mDpo%j=(>i<7oS zcUs*d-}dNebQ;-&k#UGoUrl#fDp*x2(DojkV7Lq=!a~L$Yu?07(}A4@5`ZSL7Voif zI6@)6MHcMw2$^x7`#9gsl|GI3n5sw*tmgv54ia(t!e|tEBjpM)3{y^`gb|B!)T>!r z=xGT#6#IRz9dAyLd0XjgLoye_^>W7bv+e*H)#pKp-kDC`71vqW$>ARS!Ad!bGxgn{rvURbr zJ8{qktEo zE1jV?U?*>XZl66hBg5#=;Y{2Yn+e*7Qj-)Y zwOc|rYHdS>Z};V0u7M@^2NV}|7%gi8d@&R)D0wNb1FKAaNmn6UkMc4&Dn(3SQc|O) ze*sq*KeDZDt?=#%quOsnU0IT;T1ASzY891cS1Mo&9EHHfuEo>q%hdGyUJ5Sq<= z1xU)ZP!)l7F=M$Ukp~uvP7OLbUG;ie2~ui+b#=4wK;KkkLqxaM#9`a1|Mh?HT=4Mp zaBTqO1{?H_acrFB#_19Z^VE@0gT_=@I^qOP<8Weq2mOVs6SY3NCT0Y0u|)3SJR5Os zi1T7m#4p@{5jC%%i^Bx^vm~5*wxf`*eqp(nRt_n41z`NCa9MhIT>bT6zR+fm7PIno zR{L?;2=ORe#%ghp@9?dL(j@NIstAAWm~-(mtsMEiP}WEA;Br9VL66Y-X5tU|WWNzq$d1eUm`oVWR)v z81(;)q3Y#e{{O~+szu2a{Ehsd%3{&49&_b34D|mE3lFLaV515TGcMfu=&CeCxwfXz ze*;szTo<>1=*VaKNIyWqkOXE2i9;jCku$O+ZCo0Y=ZdH#1{oD>4k7)$yl(MRa}5h0 z3rhtWfGJjQJNy+)ZKvz5MeEFhP6hM3I|{&3KgU0dkYzu*sYj8|KVc2Aa*CTqZoj}x zge=MV1YbAFxGoiOvm>FtMM##iLqymA_jsxE|*J=}Jdn zhnw)`Li<wp*p>X_F_#&{$x>?TymtZ+7*xa@!j*$>LksDhH$d z3e{Oo2V|2DecTTnfD>Q?*k69;t>i!KV?q`iU20Onq;tycQjocGO_NOS6V8p`7}4$m z-|_j1zGyvqn*Er~_syu-1t|L5WN!(3{M6-QL$^^u7k=4}{-mE8D~7FT^wBpXjA_S~ zn4WHgg|LHiJ}l;JO5RAg3Yv6xBU_N1o#HOHCCKX>om1nKMXTk%diMO}Y^o&rmcJr& z@EaXVb&t;n{p1WkfRV#I!8Rbpg*X2=9U@(SGOEo?Apva-?%a7_*vhVa9%DfqM^kIM zBipw!RUQr*##hb7)ALTt)5Q_O^Rj|qYnI0gA^*UWiW;O_TA)9@L#y^?56<;+J)FAf zfP|t0Cm1Xyq*Y{PX2N!|oj)G1#qNc3aDfGK_WmtgwF~Kpv3wlf&*RW&4U0n(6l#f? zFo6QFdYI|&p7^K9LBP|?kst7l%FVu+lZtUz$(HX4Q6yV=!#BW%;19N@KqD7Q*|FOQ z=MdPa5RvI}NjzZM`o+}~zYE~Nfk+Mx#4eOAiCk6Rec@ln!e_o1hOv}c3vD}vAaYzh z#Cr1PthXF(pkKfyv}^?RhF)#HP!)#nD>Q?z>H z8&gO&&&K>pzHo=pq+}f*%pbYWf<(Q>ih_vR*lgBbuf3j5_$vCNH1F(yTij;krHdy9 zLx9CH)Pd8L;F98+QyS22woh@V&PJ7Y&6KeZau+uY47h-hYX1nkR{8+_aQQ-5494dB z&D{FE*wMFS&}WO?lY<-KJd`54X)CCz^?ew7!lOruqayiexq=!c{^MKaNu;h<1_^mm zbI4xQO)8IC(9e+a+78)OOj@~;=a#Z)K@W_rtW>=%wNFI42z6iX`0;c!JOh9UDbNO& zheG7H)eC0ovx&3`LDYKf3^}Z@r_FEw;9NzJ{w+t3v+zlt?nb)GE^imRA*7d`A!&X>@Q1x%+1Wt%J3Gq~ zOEJ9lplY^tm>QdNe@X$lFG5=^K3n8fUJXvp!ra0)6BCQ< za85GKMG>vfw{`+k%-_8YDO94%)zdK_DQs&f+U@Mg3X1>4IK(ETQQ*^W{48u$10U%u zP>i6McgW?EcYttmpMa>6NTzAirfb??lR@i!~BY;%^%SL^W5 z6Aaem3+faBa%Gi@tXRVt`T`2+dR6a-s@n>4n(6oCDFv`0%H@h1lrMyftr`7fQFILe zMdU=-TkL{!#Zurvw^np+t2g*8Ww&)2L9JTahwPemZxz1DQ3_H%;>5q6A08f{&0KDx ztY6OhXFq7OYY}~y;8|CskK>Day)Ee;7E6=Iu(2Z zUE@X6NvrFfmS%eYn&uLxv={8GA}Z#y$NoK7sY|-_Nr1KcJ^%hJ!gtNXZ#qPtwDaTx zzlw-szvW#HW&W7wqasIE=oymG$z|jq4?_QAcTB@~*3>6JIW?n+%Goi^quAC0?jYe@ zD~k0g`YFekT8u_hGMrJAyoF~107o9i;Mk|q?kx1sDH<9eI(hRt4vlXN+PQoN*Ir%u z+vcpDsj}XjNC+)qzxT-+_|HuGa^WC)MQ{>`=>K)%bofrdK|)ej)IvDqoE;wO+P=)y zn)la{Lqsks(k3~Jte{h5EgI^N5Dp9ygp&8ig6-=Oc_9%tCgNtWt8@!0=Cpzn9;X8p zpyUy+gyZ8^tL;1Sx}_v>?$bhs#xSxb#|;XNbsWAP!L(XbK}53fdV|YFEUlEt%&*j zCK*?RMA&wYyK%iDSJ0XwBDR@ZbMhI2=uhq`28}Ot@gj1YalKKrg28@I*>fARna`WM zjetpseI@biFG{mXRssVXUONOH@CJ@C=XySXV#ZdoE=%-P3`wy*yT;1U3;! zabo6uX1b9xBJL-Yi@6kb#kVDLGDRDElJ(s|C&B{v$$?;nj@)LuYfJydh@9<4a6Vjw z+^KWk4#QnZ>El!1H2UW9>UavMC0;<6a*iR}^9}8|n}#R;6}3NQX}s$raY3oewz&r; zEDvJ>T&e0ywP=5bu!5*IFsmh3($I&x`>_AKyap1%@MZ7i$-3UP;Dta*wLAKplvX~o znb9ozJYf%O(=Pi2%&-oZb@d{7u`Ag-!fp3d!meV7|H;vvjQ^AaJEM@^`YMYLzJ`7J zqC4LCiV&5G8FcD8$ADqrFX-*?lAK#=h7X}9Hzm-7Q3>A&wMVpQM$f?RkmyJE`Oyk4 z&pK{1_Vtpctd)WJEs_j0iKse$epwe4qjOb_^YFa$7Sx?CE2v(xO40p;;1+^UD<-dZ z?qpPoOs*{eLxq{n9Q^Fd5=nPK$=t4TIgubQFkyLgk()-{YI6K^sC&gy_}ZplOt+FIH7A-Lj>b<$PVeYJ;m9s_OG^b96lgvV^{aU@X>_urYG) z#qw$_AJp2{(x`77Qt5Mh?Qxsz9Hz4#n40kXso^OpGnzn%HiJ6)$wPEK;FK*JAdR6~ zTk@+Sm#8~OwuG3?0a9yemFl$^M(VM%*`!EbF0BZ?@(ze$4O>*>m)l^XI~pq zCHi}Rr&*o}v#u$(SsrSrkJZiFWBmB{h4S688PbOCPonOly(#w^t`Wmux0O?U&lz~2 z$J~tV^Qw~%@kx#|W!am$w2ES!Onx^M^6{sgWagt<)%iDbk6$bPJE&;hp4Y!%{wuo& zx}oTk=kl7{>;5N#3k9JCg;3U@qxoN+?RP`gD+P3$-Rt}>(!P2OV0Nt zeUp4|3P;?S|HBMKU->+iyh&Z@e|kp~d<(($O!tRJS(PSF2T_p{fOb^)esAYQv`YJ> z`HsuB7XN7T{f#950H&VaG?T1OVUz{T2q7N2{hODT#Pth&P}$ht*`nGxe%D9LqQ-tr z0?Jm4s+)wcm~XaCZ{W{5!v~RU-Xqve4_7Zk(xyEf4xFKUu+?d|ntN3G8%1n-xg%~hgV5T!I8Dgj34Q0d9Iz1_ z98GP0)n=o$;QxTun+Kz$mb=?pIV*KMN-TYXp8Vy=WHRZ&4f{O}BYa{neU+Frjn_-o zDP{tEBh{3Or9B9rl2>0v-L)%_p_~iryPq^>wFL~&MhH4QKy73jDr5%=sUl~=d@`#I zq)q!zPlr1uBYbG@acB?Qtm3P06(Hjyf5^F#D)zsf-Sfck!WwEh| z!sbx1va!P7*70pBxr_E8o7uQhbv0X<=>x`%O*b=iN20n1MzEL799_<-3APvvR63%} zn}%d4a25LYGRJ{X(+}q%uHIc)d-G14%IZkDCO>fTO<+F@$~Dy0lpy zu%=*u%(*w`(R%1@{_Z2)qb+G_@aeuJDt>F;l^}`LC^l}DXduMd#gst$UsVcK>1i287*(&c*1ztZb#YKYMZcT7`@|wJ@mSxd*$T&N=NMP< z6^qLCTBZZ)o97FLf|Fj9xyTcP2=rr2V$VlLM?ZR2Pbc@WArr4$WyRz`)5gcW94m-| zWUfK$?u;pdrGVFrlHJs_lwOnPgbZeMU^()D`N4$yl(fH&*4yP06QfMcauye7VdfNa zBRDF*LjS&=+~ABU8kksn+zJkP4L-oG6)4FjoqS)L5HnC2(GaUD$*iBxu(Y;}%r>(A zW!LDw3DI*JCBIJ;ntCf}YGdNyu#n~xc&)@`JfeZ*Ck5(+Pd`Dkw3MEKz5c#G6ytN= zTy7xHT<((96IE8ff3R%2tZ{(xxr&seF5d>D0)UaSq+69}I2SWXljR8c8&xEujX)uf z@kMGh&)S8Q(pS=tU3|4eUCHk0Kmi%sBjme+mQ?7VN-BUQ zrds6`XiC$6=}e<9&*sa#NRtxwKcWH%4V7At(i`kY-U{Rln?XhTqDB5;KokJQU-X2< z@{c>kLqpd8^Kn3LK=BKaaewcd8ldK1k?#mHlM1;n{I?$$iid#z*Q^q3kFxLdzqgPH z{PM39iZj|W|GmL8^gm*6v zrXapiouOA7seVw%G91Ek8cpTqC+HvYbUsGlzErkM=l}tELBct?by$kzofN^I`@7v< zu*htX_1lE9*x%*;2R5*Vn~Y+JelS!p)+l~7+MVY$MS7~;fQXFkQO{M^Bxo#FznoHA zLo6bnR@rkhichhx)KE-j%Y!Dv6~YXXnXWTz#a|K*F(VQsw|sk{Q5g}mlvbybP_gDJ z9vX`Ww7qS;goPk4#~llZ#+BqfCK~t+m5CUTj~`0FbWWs;HQ3Nc<}XPNTHcbWUX_lX zz9F{4K$G>=h8(b|U@#b3<6lLJ)> z#>~pPpTk0WT0uCOK$S?ZXwlWzX(^KX7{r#wZS?`gV!&5yqVCA&#YB+Qe3aTO8ufSc zz0ac|m&rt$%&}20FwpjkAV6ofcb}M8WLS8e!q?31LCI^iN(FW2)3hETuUbkW$;d+I z!pP;pVB~m(w&b7}D=%xSQpCpeA~rHyfEucwJ$k-=nJX0q)Buq*8`@`@btjt|eQhrh zL}fqxS|0g3HRjtCm`n`F`Wb_K*`U@mclco{0Vo4A>NL`l7;_$6MGkyA{t$tJO9ZY5 zm(!>?N2hH%)sBZI#nIUo`agw$fv2CL$LJZ-<6t*X(+xx#yr^aolH>5PYWC?=Auu&v z)u@zIrb)OD6Ep+;pKa2!gJKMTtn&vC*C8nlCBT#sJ{^Q_jw z_!e8( zH{_3mOIpz&X!rK9(mh`g9n9e7jrLuqyZQcd$?zZud^tTg2CBS8G=b`Se(2|qFuj~S1q!jQb-EtO>VUcuNaq0DsR_hfVQ!)vG(IB`Z& z68XzZPuL=T##WKk?d81+G z$cq_MHN-3tL=gm#$O9^%M_5+BaN5a+2Y7gJF4gFw;p?odH5jv&w8b9Z$os#VfS8s? zh)XGbCrP}fy870b+-HQl)0&hm8RZNIAR6Hz_349Yc-)v1#aW1cqXW%=9QdOkw5Uz! zLGMJc4pmY+GmFV*5^ZT!vfU0@{F=dwZ0l?IvJX%NA=~VJX@u+usTFpZzSAQ6U|^W-Zt(UfLP%{ z;9`E4UHQ#0G1*GNKf{3c=Rc~S$uA$eHtgq&rz_)s+z zJM#s9dd(`5VTb-#n8-B)a5o5{XC*$e{13`dr2_X>Hn186uyrzhR}n9z!^;2uiiq}3 zV9M>HjCDY*5MSuycMXW&%A<*rI0}?b{M(MnR5gs>iZ8$gX5C^EfNHo z=-w36;@yF=*Q2HvNPVYMLzB44pL;%QsQP>8a`h*-vVVQGCj<$Knzfq_w;`9Nya>p#mjsU zQDh6XEbS)x^?}Hk9rKS0u!AJ|6vyz;SouaTH9P@~`#PA0A-BA#c&}kH_TDZp0l3g8 zv4MwesEDyxgl_b1j8nOw9jU3`t_uzBVa7Au6*FRA8QuSzp=?6XzwY?c6$w|mD+D@S z9=}UYiQZg3_~8oZU-PZ!dRR4`@q;(;JGW;{sWwiS;dF323hYvdkA(RxN$cyW;oGj9 z%@KMwK3v0g`uTPI7?uL9O01<`6Md4lS8Y&4yJiM!7&p$4Lt}ar^gsQXTkBT{dj^Vn zi*$MB6`lvz@i9crm25o^X^w4UG|#7}_xDjo@_BRYJ{wT<*Y3xP{xu{AAkE&cTt?z@ zgUg;w_XU;GOxo!c1_!&o0ncv#jaWo1#Avk-18NO9;vquT&}E7uolO!Mw-y}~Ygz#5 z+t*Ik6f5C)Q^qX8Z0f3!B*tgOwSqt5@qKl#Pbx&`-@RkV$qnzYMCiB!TLT5^o|QpN zBX9pC2_IfbB&kV$nXF1dY|I!n*6kPN%gaN;kR{OQJEFP#(8vh<1a}Ouw^!Ge9nw0; zJCb2nHa{ZIwj}Dmy#O(!iWl-Y^qvcPIbnmSuYKvwgYPWR>-;czj@F3?M?GewZ)^C< zW&50hMm&1Kn-jRg_T_=j_(O(ETivBn*iaf`&y%2cEh>c| zyZoOrz_o>d>GJKs&fCW9s2X>+Nv)Rr*H=Gi_4K2tkdmY2nQ@fri;3-W$v8g&j*0w` z-w4VDRENf>9-B}djv#W@y@!3d-z#kDnp)}W#*Ec|ThrkO&qb3^H zHM?-BRFf&E3@x=r=TY@9=Ajb0Q=>xIOamwqu4eYQj%M0nRLAedUuz!XG$8c#sz^;E zod*o0ls>JPA6U_MH!{M0*K}-O5kgD-h@0hV>k3;=Sd}^^F?=+<8QLt|UC6CqJBvJF zi$>i(iL%=*$xkUEU1U57k)8NfWJhu;6*XPQ9`&B78FYz|sX&m77M#1EVW!1)!to0% z1!Xj!pOP^RC<&dYrBz$)?|f+`#(~4gCu5X_OsrJLbEBJ$^<}Tws;E^V0>M`t*XTnNMSVJGjzGn{uBkR;?u05|sCVujh>$b1^DZh?jI8;gHbn~Z z-o6=Be(x@YtkkyVanGIwwiO7!Vm;j5V^4CE>@a%Lm3+ZOztNHnTQ(^ z-;JSItiI_`J7*uA5d#0rrOxJeNfho^4X@8~m+~B+PiB)Ri#j1OrUJvD6ZN!g#dvUp zt>%2K)%gyMq~!FEi}ebd3(<<7?BuOs$*aH1K1D*QM{r!ZXPc?_qk5yN89}Ufq(nc} zL>uJX#b+0x^>%$qb#4~JAUrn(ZGtj8%XRgO|0M>@)xAD;K*4qg*G_jV361t8EsWVJ zaKV7UE@XIb(DKD%)j`l6JrPu$#vAyNi}=_luYvv$dy7OLliSI1H;iC8!qW|;JGmR` zq)R{{0*#}M;#6cwOjj{ggo_prJgHTTMm!&ko3;(SO!pIf_ZHGb_py9Fw%Vf(whw$q z6VVY6oPCmG6fxSJxz&6&7A_}Enh9Mp&?&&=&pZ<~;=wGe%etFKYsBUw>|(C?G8k)Gej$;&+g*F zOS{brM%YW`>q3wE(0PSMJ@h*~MtoQckI|w{o=; zF)R(6lh7@4kvgYmaz}~{zrh%4B_@|RFgs&gZ3@LM?vGuDV&NKRIGCH&lj|I1u;k(O zDl)Mgob2EbIxQ?YTUf4Y=%})~0zE8byJ6me8RPh?IT4M;Vp3et*wF6){=dM}huY?f zu;kGV?ET3-RQ2vGvAD(XD26LSn8>$1O0qla$nxi#8QrGZd>auJBOVM1i1O~}7D|s@ zogVH+FOp`Nn}P0y)kbvD<0}%A8Gg_|X+UbIL~$(%-WKGLvO~HnbjYQ&*LX!9^i!e9 zUP|C8?lGnDEDmIm*BVAP$k(R~sD4N1pjd6`7q@8s5W0iWO2lT0O_<&~OmS!36#Ch# zw6+j3{UCqGUSmDont}y!fVfbMa^ml`*<=*V82QbK;r=be{OwTv z$Yh+T!Eee1PXQZBvrlRdbpN@KYT~WYnt|_3uZ9wy*0@AU%ix?Jg(vxPu%>_~H$Uix z%1I4)T~BqpU1N_&67<6&x@3pzg`GYauj}v>P(7 zbo>x%UgRtdIv37_)duuNq$jvsbqdE)SzjfctSlumV*M@pdqs@ zdu+Y?hk@MZ-<-$i5hKF*R}+-fPe2x!yq1^V=yqF=>H^4n6;B@X!ql7pR zMm(*(APvZY1GDiLPs+-4?@~O{aQtX~+{9(aV*$dP9u9&Zcz#!xf65-@LF1C~Mmv$UTaKq+i;v*}^x#A2<+KP)>{Zcz^I zZz*v>VM-2mDgu5em=N<_QKNApNUipB*lWdtd~sX)0CEZ#h>8`}Ql zCcS>$`XObT?V>zn36IQZzkW*dfiKYQ7#*YcUxmk(XF8Xu9I7Q~R*mxO#L5~-3S$9l z(gMvCh|&=GAN)uK=KX_N(BLosw@=E8@`~zf*HKcstly&0x+n}ocS|D;LwAF83WziU z(jh&B%+N6-C5_YoLrEhgNOyN$0qF)oQeY%LuJ=2Czmr?z23Ebox(n(Oj&7DhGBupoVZkq{xK1xt|60LfiS-^=7>%-ZoPD{Zi+;3g;wP5Fp70fHW89A!boLfGyme^p zG6Z9u;2$h3!Wzma_oK+Mw%G48*M%$AD@YP)bDr#sMQTyUrwbJ*#%K&yHth9H!#5UH zG>!QubqFUi|I>2#Y4W?Kac--Mw;B~K_*X;u=9TBO#y6E+wQOH(n~j6!8@jvV=ntq4 zy>M*X=LTe6*7zj6H~W<1u(c)W`xgUobwXp}J7LDP`CN-rS<8y-fLx z`Z?33Gity!>sd=6>oF9fbEVLzS}R;SLYl}J3o|$s`I>LH>i&B z`gaXSrx3}abxwd*OxZOREn`~H`%a9HL0H@gSBr5MYYp86Fy9)>wB>?z^10RyGLkdB zWIAALI;y*fo7Xe27RW83!y=n9zpGRT9D_lGC4(U&mx|NI32?=~Dj2!|`7B;n6q zs?neGIBpowyR9)qBXUI?2g>|KT(@GyrSJzTuFBuZ;?qw#&uF+V)=>8Df4?y(R+3KA z)rjzyXkx=y7Xu&vAc05Cio7{)n|2rZq8(HjKaqXgICQst?IjsV8?OosVt18oz*2J# z8ho%~O`(s#UPzO&{&C6|0hYog0s^P<7Io zD(U~^cumw_Pw<26)b$p0@)9wJ&ae_Af6D*H>j2Z2(5N(09QINH>-}C^V2l7vaYEbm z{!q)DR2(r#F?Ddicv_aUrzpx#7BBeZT&|-e_fTXQ1uokxoO8ZLVPFaV zV-D}gEDGQ(JAu+DMW-%MtQ*tz$K8xVOV2TzK;rikuQBfr@uOF3E9t6$E+SwC-8wX3i{XRp`eu!+HsD6=QF#7Fd(fq%H-@1pgQ+xD3bXS5?kiU+;VMHN&h2&qAMoS2Dm7{~ARDkPti zzo2>kG&kArkosQTtlcXEhY)>N|$T7jg3h{mo;qqlHEejpzQ6OD;@T+Z^m#OlY!P#7ex)G_J4#(!x zm0&V_YWHX(dgUKj8#tiIsqAVg?e>kMgNKZ;s@{u6w{MrBxkG|CkZ(k)SfwQIk4 zZuhi%sNVh2tXzKoGTD$y$*uT`z{QwZNKcfQ3%}pMTzT<&twqh_PFsX-Ao*v)recln ztho>-8goxb^7;3cAZjt!rRY9KSzjs&bmm?SC=yE_g23I)Kb z=AD$v&L#EoK>p+dB9N8NtCr*j z?8bNqHnp+1M6+YJP#gNJv41hlWwmc}cirCqU5G}atyCDszZkCU`=_xCTU_dB@5Oyo ztk<5`X1e`r+IRBT_=ZUhc3hpMuYaG9CV1Nb*p<65s{j##>!JLOjk)onTUoZhrh>n} ze}}(tH;2_pblLxl(%t4Tu@F1vAd2F$=8ecoUIT>IC#L~WkBQk`_$VcmSkS~6>mzb` zOmK8VtPGDC2(50P4n^MSSHA1EoYgcOc-8yRouB{k%^cH~bDh1zZ4X+!4fURex$T=Y zk-EdpKLn>BH#{8#__Ti--M#rRLUm|&7*tjb6*NdU4qbjvCs;PxI)da-swEP4RfXn9 z)Fw2x8I%c?gAI~@UuCtS*}koUj@`VvtBb8H=wFcL7^XTTH4WpKjVR(>x<0Cq2FCfY zJ|6I*g0Qbwq8Q7#?=QNXok*mxd^8e`7x|~y?^u8x!6!oIM_UmvyF09OhkcWT)J|ig zE?x6|GbZ5Ets9zMu|)cj2Gm0q!+X5=CZ{Ho>N2xV`t1_2G-?Fvp!d@U&JN!V z<*xY~275&Z1F^G18U5n?n;7rb!QN_1#-0U$zQ&0H)@RMds7}Q5Ze8EO#Bh#9BC=N)1|m z0e7*hj=s?8h3A`}Cv@84rAYFox#%xP2>37$FN8Xa03HgYB^7K@v1e5oQ&=XcuVFVp zg;4*4-aOLf6yk#|gL}Vf0-o^A0eZ}9>!pOTCx;UR(IwrgkgB@)e*J90EQ!>XPd`vQ z4Y6=xNprh zpa5z6A+-F_UKCb9h($}|SnTQV?ugXTtLo%f^K9^wBbgu4d=mC(rAt5y>BQ{q+wW2a zZO&j@{}*l;@~j4Dqg?kKmP;iY-)%WZS=Y#m2d5ziqEDv+QInvkX(glU*r$g{A7Gq_MIK!uL=*xAy+`4^s>6KuxbCG z4%RnHv_D0Uqg{oz;J4Q}lunY}mVeBc6Eo0dO%x;doZuiWpV<}{8d3lBTIUvsQ%gx< z*69P6`)ammSTUlNOCI*61Zg#dmEy^)AiD6_2gVhE&1j~8U7iml0j3=GUGYmfThz-go3xL@J62>DDUV8ETQw)i#&EaBexqvvhX~md`AQSwtvg{3DD#OQ_sy zOLqm>&!C#+(3%dJE@Bew<0mH>>`mHK_ZVyxoo-NYJJ1I5p2_g71!HTCHptkPswRZ_ zAYhKP-(F9K$=tF(v_P~p$<$PhsY9SlT)l*gi#nyt4T4;dOT@4tyVXY5hCle2uEDD! zw9~e?)@9n$_2WE}E38PprGb*0Fp7Fj@vLSM1vE9ITH>B2PE;(IYR}7k=j+P*nb!;> z-zv`CDU3U*wZ^B7MJy48L|HDlXGSpRSzbANUI-?PIr_*7HB2;N6Ra5AI zoS7W-HPDczx2Eh=HZ=!TDBKA0}zctc+YdZ>OC(NSQ}GuiGeq8kcFQn?OMmA^t`1!1NDo5Flaw%|Lq z_$t4No$cT%y_5@wf=M7Qo+lX_5%}9J|5E6TL{}GqXnczF=uW12TLDx^)mtgTE!4g+ zU#wXb&n6xTs*gBZ`gz!@o|wSB z(d6EwXaRT8h*bj&y#LcZ;qtc2YzHix?QzGBbXUXz+e7FO=^itL$? z!?8>9TCBD)4Hut8sQH%wY`F)H;G|tLCN)zDoxM?IBO^l}+MCTFJ5OEt?)k|#|M{v2 za`egy-<~X8j+x4gfCB|_D(T;9TiIR@$xUsA+uHh(4O-mO8k{I{^|kho1ax?E5!Cm; zwl2DmH^}eWS;vQRd>=e|r#W|&3?xdVG>@czV=1-jZ*2Z%N(Ko0oVAL~QCIx#4%)u* z#K8n745&D(j*z44vSD;NV)W?PZw21ik1=rF8K*L*DnD~6F08aHcZC*KW|_s;$pxm- z*{`%FPU;y61m~NQy{D7J1Ff9(pk1T4opM>B{_QKM%6GMJnKczPfg#JQvVT~dH_O;< zos33y0=(|6aRbYjn70QRmvqUjf`s+6Q1D8l^YdU#7yOhw=Jk{;%L#*j)*=~S?Wnt4 zFA(S8RI+MH3Vvq?6T{=1q`?Xgzg~p4Q$h&vyA~$JHg2x$o%U4{#5go_AY_7+I*1r= z`-YPy+*la~1Vn=)zwS4W<+Ci5vG#t(KngQ@iXpv))+*?AcVK*-`JnCAiJ+#MZHLy` ziZCdZtrpmuSA;$#v-8Pb;uF!dEdUp)m{2^cI}P%#w_D2fWRUSk4`{_j0(rFh(JvE2 z&G}Ss0t!DtK)~i1!BmhTwOV_+o}QYYW5e&lrpx;U8Z|`~sgepPXE~UTgLME`2^29iDt9hQ^ZkmZ`C3XhO7xnJVtvyFueD zJ_kH42pyVHG7I;7tHaO7Q}q&MBF`8Y;d&~N`q$1eSDz%s4iGxsZAMs=I#Dx`qprFJ z*^Hx>p!Fm5_^H!VTt6(Kt%Nz~q@IuW+Xno-xK01n*c`pRhHe0~=jGNvqa!n9vuIIOZ$SFik!v*?@6 zH(#Bg3z2z>oip19kd)Yv75(&3VMveLW!8l<0cSDgekF5gLn3}%cGD>jSg7?>)z3lK zaPWo~4X4yYw28vb9g2N)C@5*e^8Udr$W3QkPMCRVh+lFfOE_N#<4pkNvd9plK1s6c60Vp)Ysc zHl}MVMF>jfC~+*FXq@wv4yScJ+D0+4OZ*KhPW0EWUz0#Y0L#I0Q9sOguu;B3`Ad1n z1X6|CI3@Gi(U>I1nNCq8?JyVvO*q{!b9vmnCd&FA>}VRA8XKWGUy&CI_HrPQdKwGd zHi@jVp}}Wp+)Zyx)nP z3LO4kRv3T*M5V#&TBZzEXXXW?w2QrN62#hKeA+b32IVObUNK%l86uHh(PeU|wBf!r zlV1P=A3u%#Mf^J#V0L*9m-B>Cx`cxp1@cCP=Q|!VLJ!b)`^DS@{4zIlIg&igqipRW zgkPOq?s%4zI0g=&tpn9%_2<6zU3ab*?%#R>#2F{Yot1u*OGCAxKp_E`P;65Oq}jA| zNU=U6V}69%DK6j29FzT(4tj14RVT#vihd*jeluT1yPlEl!l57h!a~P!+clRO^^6*k zX_~dU^mQEQv$eHxRKm&&LFbGOwtH^1dm=Xww%n}`2#Ws@+i2wsoctJVTG&V&5bwCB zFNoU9bQ(#D;6=_?WZw{|(?)goiBrcF!5BFY^n1#GCNT|-2>nHLG?nBXB@iN5p#P_j z1qcA|PtNyiY8OPfQ3uTG&H4U)#pS7S`ueLhnQTV_4tx3EHh=!h^0Tt-Xv5iHaUMTv zG;P_sLb+2_9RC6}cmNyhm!G@*d{-R{&)J{rdu$bNkVw$7Irtc0P`gJ(*PGzHLfc^b zuXFE&&6)V89>R7Qh#xFXT5Y*gj7s_~XwSoSG3mON$~0ck+ox! zUvo*^`OB%aF#=9b3M)*OGgYR4W*S;1Vh1jP*yS4;L_WYbt1|E^en(e=B@l2_Z@<58 zge?;>WfStbN@JVkxD=@akG;?iXo|RNg|4}v-VBwP=Nm^?>KAN2>3`3IKu7P3G|eSI zQ=2BU%}``=(NRK&-rfNf+~M0`QsTF$iMmf%1O-xOs5aws(xdU8yQi%8?7GB%wIJ7! z_g|_stoRg^6zyNKN}M=4E99}ZTI~aT6Ke2CM5&$bLc`utkMguMRCJW96|KVm2bwQ2 A5&!@I literal 0 HcmV?d00001 diff --git a/fr/index.html b/fr/index.html new file mode 100644 index 0000000..a33d1d0 --- /dev/null +++ b/fr/index.html @@ -0,0 +1,112 @@ +--- +layout: reference +--- +
+

Introduction to the Git Reference

+
+

+ This is the Git reference site. It is meant to be a quick + reference for learning and remembering the most important and + commonly used Git commands. The commands are organized into + sections of the type of operation you may be trying to do, and + will present the common options and commands needed to accomplish + these common tasks. +

+

+ Each section will link to the next section, so it can be used + as a tutorial. Every page will also link to more in-depth + Git documentation such as the official manual pages and relevant + sections in the Pro Git book, + so you can learn more about any of + the commands. First, we'll start with thinking about source code + management like Git does. +

+
+
+ +
+

How to Think Like Git

+
+

+ The first important thing to understand about Git is + that it thinks about version control very differently than + Subversion or Perforce or whatever SCM you may be used to. It + is often easier to learn Git by trying to forget your assumptions + about how version control works and try to think about it in the + Git way. +

+ +

+ Let's start from scratch. Assume you are designing a new source + code management system. How did you do basic version control before + you used a tool for it? Chances are that you simply copied your + project directory to save what it looked like at that point. +

+ + 
 $ cp -R project project.bak
+ +

+ That way, you can easily revert files that get messed up later, or + see what you have changed by comparing what the project looks like + now to what it looked like when you copied it. +

+ +

+ If you are really paranoid, you may do this often, maybe putting the + date in the name of the backup: +

+ + 
 $ cp -R project project.2010-06-01.bak
+ +

+ In that case, you may have a bunch of snapshots of your project that + you can compare and inspect from. You can even use this model to + fairly effectively share changes with someone. If you zip up your + project at a known state and put it on your website, other developers + can download that, change it and send you a patch pretty easily. +

+ + 
+ $ wget http://example.com/project.2010-06-01.zip
+ $ unzip project.2010-06-01.zip
+ $ cp -R project.2010-06-01 project-my-copy
+ $ cd project-my-copy
+ $ (change something)
+ $ diff project-my-copy project.2010-06-01 > change.patch
+ $ (email change.patch)
+ +

+ Now the original developer can apply that patch to their copy of the + project and they have your changes. This is how many open source + projects have been collaborated on for several years. +

+ +

+ This actually works fairly well, so let's say we want to write a tool + to make this basic process faster and easier. Instead of writing a tool + that versions each file individually, like Subversion, we would probably + write one that makes it easier to store snapshots of our project without + having to copy the whole directory each time. +

+ +

+ This is essentially what Git is. You tell Git you want to save a snapshot + of your project with the git commit command and it basically + records a manifest of what all of the files in your project look like at + that point. Then most of the commands work with those manifests to see + how they differ or pull content out of them, etc. +

+ +
+ +

+ If you think about Git + as a tool for storing and comparing and merging snapshots of your project, + it may be easier to understand what is going on and how to do things + properly. +

+ +
+
+ +

On to Getting and Creating Projects »

diff --git a/fr/inspect/index.html b/fr/inspect/index.html new file mode 100644 index 0000000..32945eb --- /dev/null +++ b/fr/inspect/index.html @@ -0,0 +1,475 @@ +--- +layout: reference +--- + +
+

+ + book + + Inspection and Comparison +

+
+

+ So now you have a bunch of branches that you are using for short lived + topics, long lived features and what not. How do you keep track of them? + Git has a couple of tools to help you figure out where work was done, what + the difference between two branches are and more. +

+ +

+ In a nutshell you can use git log to find specific + commits in your project history - by author, date, content or + history. You can use git diff to compare two different points + in your history - generally to see how two branches differ or what has + changed from one version of your software to another. +

+
+
+ +
+

+ + docs   + book + + git log + filter your commit history +

+ +
+

We've already seen how to use git log to compare branches, + by looking at the commits on one branch that are not reachable from another. + (If you don't remember, it looks like this: git log branchA ^branchB). + However, you can also use git log to look for specific commits. + Here we'll be looking at some of the more commonly used git log + options, but there are many. Take a look at the official docs for the whole + list. +

+ +

+ git log --author + look for only commits from a specific author +

+ +

+ To filter your commit history to only the ones done by a specific author, + you can use the --author option. For example, let's say we're + looking for the commits in the Git source code done by Linus. We would + type something like git log --author=Linus. The search is + case sensitive and will also search the email address. The following + example will use the -[number] option, which will limit the + results to the last [number] commits. +

+ +
+$ git log --author=Linus --oneline -5
+81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
+3bb7256 make "index-pack" a built-in
+377d027 make "git pack-redundant" a built-in
+b532581 make "git unpack-file" a built-in
+112dd51 make "mktag" a built-in
+
+ +

+ git log --since --before + filter commits by date committed +

+ +

+ If you want to specify a date range that you're interested in filtering your + commits down to, you can use a number of options such as --since + and --before, or you can also use --until and + --after. For example, to see all the commits in + the Git project before three weeks ago but after April 18th, you could run this + (We're also going to use --no-merges to remove merge commits): +

+ +
+$ git log --oneline --before={3.weeks.ago} --after={2010-04-18} --no-merges
+5469e2d Git 1.7.1-rc2
+d43427d Documentation/remote-helpers: Fix typos and improve language
+272a36b Fixup: Second argument may be any arbitrary string
+b6c8d2d Documentation/remote-helpers: Add invocation section
+5ce4f4e Documentation/urls: Rewrite to accomodate transport::address
+00b84e9 Documentation/remote-helpers: Rewrite description
+03aa87e Documentation: Describe other situations where -z affects git diff
+77bc694 rebase-interactive: silence warning when no commits rewritten
+636db2c t3301: add tests to use --format="%N"
+
+ +

+ git log --grep + filter commits by commit message +

+ +

+ You may also want to look for commits with a certain phrase in the commit + message. Use --grep for that. Let's say there + was a commit that dealt with using the P4EDITOR environment variable and + you wanted to remember what that change looked like - you could find the commit + with --grep. +

+ +
+$ git log --grep=P4EDITOR --no-merges
+commit 82cea9ffb1c4677155e3e2996d76542502611370
+Author: Shawn Bohrer
+Date:   Wed Mar 12 19:03:24 2008 -0500
+
+    git-p4: Use P4EDITOR environment variable when set
+
+    Perforce allows you to set the P4EDITOR environment variable to your
+    preferred editor for use in perforce.  Since we are displaying a
+    perforce changelog to the user we should use it when it is defined.
+
+    Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
+    Signed-off-by: Simon Hausmann <simon@lst.de>
+
+ +

+ Git will logically OR all --grep and --author + arguments. If you want to use --grep and --author + to see commits that were authored by someone AND have a specific message + content, you have to add the --all-match option. In these + examples we're going to use the --format option, so we can see + who the author of each commit was. +

+ +

If we look for the commit messages with 'p4 depo' in them, we get these + three commits:

+ +
+$ git log --grep="p4 depo" --format="%h %an %s"
+ee4fd1a Junio C Hamano Merge branch 'master' of git://repo.or.cz/git/fastimport
+da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
+1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
+
+ +

If we add a --author=Hausmann argument, instead of further + filtering it down to the one commit by Simon, it instead will show all + commits by Simon OR commits with "p4 depo" in the message:

+ +
+$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
+cdc7e38 Simon Hausmann Make it possible to abort the submission of a change to Pe
+f5f7e4a Simon Hausmann Clean up the git-p4 documentation
+30b5940 Simon Hausmann git-p4: Fix import of changesets with file deletions
+4c750c0 Simon Hausmann git-p4: git-p4 submit cleanups.
+0e36f2d Simon Hausmann git-p4: Removed git-p4 submit --direct.
+edae1e2 Simon Hausmann git-p4: Clean up git-p4 submit's log message handling.
+4b61b5c Simon Hausmann git-p4: Remove --log-substitutions feature.
+36ee4ee Simon Hausmann git-p4: Ensure the working directory and the index are cle
+e96e400 Simon Hausmann git-p4: Fix submit user-interface.
+38f9f5e Simon Hausmann git-p4: Fix direct import from perforce after fetching cha
+2094714 Simon Hausmann git-p4: When skipping a patch as part of "git-p4 submit" m
+1ca3d71 Simon Hausmann git-p4: Added support for automatically importing newly ap
+...
+
+ +

However, adding --all-match will get the results you're + looking for:

+ +
+$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match
+1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
+
+ +

+ git log -S + filter by introduced diff +

+ +

+ What if you write really horrible commit messages? Or, what if you are + looking for when a function was introduced, or where variables started + to be used? You can also tell Git to look through the diff of each + commit for a string. For example, if we wanted to find which commits + modified anything that looked like the function name + 'userformat_find_requirements', we would run this: (note there is no '=' + between the '-S' and what you are searching for) +

+ +
+$ git log -Suserformat_find_requirements
+commit 5b16360330822527eac1fa84131d185ff784c9fb
+Author: Johannes Gilger
+Date:   Tue Apr 13 22:31:12 2010 +0200
+
+    pretty: Initialize notes if %N is used
+
+    When using git log --pretty='%N' without an explicit --show-notes, git
+    would segfault. This patches fixes this behaviour by loading the needed
+    notes datastructures if --pretty is used and the format contains %N.
+    When --pretty='%N' is used together with --no-notes, %N won't be
+    expanded.
+
+    This is an extension to a proposed patch by Jeff King.
+
+    Signed-off-by: Johannes Gilger
+    Signed-off-by: Junio C Hamano
+
+ +

+ git log -p + show patch introduced at each commit +

+ +

+ Each commit is a snapshot of the project, but since each commit records the + snapshot it was based off of, Git can always calculate the difference and + show it to you as a patch. That means for any commit you can get the patch + that commit introduced to the project. You can either do this by running + git show [SHA] with a specific commit SHA, or you can run + git log -p, which tells Git to put the patch after each commit. + It is a great way to summarize what has happened on a branch or between + commits. +

+ +
+$ git log -p --no-merges -2
+commit 594f90bdee4faf063ad07a4a6f503fdead3ef606
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 15:46:55 2010 +0200
+
+    reverted to old class name
+
+diff --git a/ruby.rb b/ruby.rb
+index bb86f00..192151c 100644
+--- a/ruby.rb
++++ b/ruby.rb
+@@ -1,7 +1,7 @@
+-class HiWorld
++class HelloWorld
+   def self.hello
+     puts "Hello World from Ruby"
+   end
+ end
+
+-HiWorld.hello
++HelloWorld.hello
+
+commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:53 2010 +0200
+
+    fixed readme title differently
+
+diff --git a/README b/README
+index d053cc8..9103e27 100644
+--- a/README
++++ b/README
+@@ -1,4 +1,4 @@
+-Hello World Examples
++Many Hello World Examples
+ ======================
+
+ This project has examples of hello world in
+
+ +

This is a really nice way of summarizing changes or reviewing a series + of commits before merging them or releasing something.

+ +

+ git log --stat + show diffstat of changes introduced at each commit +

+ +

If the -p option is too verbose for you, you can summarize + the changes with --stat instead. Here is the same log output + with --stat instead of -p

+ +
+$ git log --stat --no-merges -2
+commit 594f90bdee4faf063ad07a4a6f503fdead3ef606
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 15:46:55 2010 +0200
+
+    reverted to old class name
+
+ ruby.rb |    4 ++--
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+
+commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:53 2010 +0200
+
+    fixed readme title differently
+
+ README |    2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+ +

Same basic information, but a little more compact - it still lets you + see relative changes and which files were modified.

+ +
+
+ +
+

+ + docs   + book + + git diff + +

+ +
+ +

Finally, to see the absolute changes between any two commit snapshots, + you can use the git diff command. This is largely used in two + main situations - seeing how two branches differ from one another and + seeing what has changed since a release or some other older point in + history. Let's look at both of these situations.

+ +

To see what has changed since the last release, you can simply run + git diff [version] (or whatever you tagged the release). + For example, if we want to see what has changed in our project since + the v0.9 release, we can run git diff v0.9. +

+ +
+$ git diff v0.9
+diff --git a/README b/README
+index d053cc8..d4173d5 100644
+--- a/README
++++ b/README
+@@ -1,4 +1,4 @@
+-Hello World Examples
++Many Hello World Lang Examples
+ ======================
+
+ This project has examples of hello world in
+diff --git a/ruby.rb b/ruby.rb
+index bb86f00..192151c 100644
+--- a/ruby.rb
++++ b/ruby.rb
+@@ -1,7 +1,7 @@
+-class HiWorld
++class HelloWorld
+   def self.hello
+     puts "Hello World from Ruby"
+   end
+ end
+
+-HiWorld.hello
++HelloWorld.hello
+
+ +

Just like git log, you can use the --stat + option with it.

+ +
+$ git diff v0.9 --stat
+ README  |    2 +-
+ ruby.rb |    4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+ +

To compare two divergent branches, however, you can run something like + git diff branchA branchB but the problem is that it will do + exactly what you are asking - it will basically give you a patch file that + would turn the snapshot at the tip of branchA into the snapshot at the tip + of branchB. This means if the two branches have diverged - gone in different + directions - it will remove all the work that was introduced into branchA + and then add everything that was introduced into branchB. This is probably + not what you want - you want the changes added to branchB that are not in + branchA, so you really want the difference between where the two branches + diverged and the tip of branchB. So, if our history looks like this:

+ +
+$ git log --graph --oneline --decorate --all
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+| * 1834130 (erlang) added haskell
+| * ab5ab4c added erlang
+|/
+*   8d585ea Merge branch 'fix_readme'
+...
+
+ +

And we want to see what is on the "erlang" branch compared to the "master" + branch, running git diff master erlang will give us the wrong + thing.

+ +
+$ git diff --stat master erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ ruby.rb       |    4 ++--
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+
+ +

You see that it adds the erlang and haskell files, which is what we did + in that branch, but then the output also reverts the changes to the ruby file + that we did in the master branch. What we really want to see is just the + changes that happened in the "erlang" branch (adding the two files). We can + get the desired result by doing the diff from the common commit they diverged + from:

+ +
+$ git diff --stat 8d585ea erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+
+ +

That's what we're looking for, but we don't want to have to figure out + what commit the two branches diverged from every time. Luckily, Git has a + shortcut for this. If you run git diff master...erlang (with + three dots in between the branch names), Git will automatically figure out + what the common commit (otherwise known as the "merge base") of the two + commit is and do the diff off of that.

+ +
+$ git diff --stat master erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ ruby.rb       |    4 ++--
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+$ git diff --stat master...erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+
+ +

Nearly every time you want to compare two branches, you'll want to use + the triple-dot syntax, because it will almost always give you what you want. +

+ +

As a bit of an aside, you can also have Git manually calculate what the + merge-base (first common ancestor commit) of any two commits would be with + the git merge-base command:

+ +
+$ git merge-base master erlang
+8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
+
+ +

You can do the equivalent of git diff master...erlang + by running this:

+ +
+$ git diff --stat $(git merge-base master erlang) erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+
+ +

You may prefer using the easier syntax though.

+ + +

+ In a nutshell you can use git diff to see how a project + has changed since a known point in the past or to see what unique work is + in one branch since it diverged from another. Always use + git diff branchA...branchB to inspect branchB relative to + branchA to make things easier. +

+ +
+
+ +

And that's it! For more information, try reading the +Pro Git book.

diff --git a/fr/remotes/index.html b/fr/remotes/index.html new file mode 100644 index 0000000..94df417 --- /dev/null +++ b/fr/remotes/index.html @@ -0,0 +1,440 @@ +--- +layout: reference +--- + +
+

+ + book + + Sharing and Updating Projects +

+
+

+ Git doesn't have a central server like Subversion. All of the commands + so far have been done locally, just updating a local database. + To collaborate with other developers in Git, you have to put all that + data on a server that the other developers have access to. The way Git + does this is to synchronize your data with another repository. There + is no real difference between a server and a client - a Git repository + is a Git repository and you can synchronize between any two easily. +

+ +

Once you have a Git repository, either one that you set up on your + own server, or one hosted someplace like GitHub, you can tell Git to + either push any data that you have that is not in the remote repository + up, or you can ask Git to fetch differences down from the other repo. +

+ +

You can do this any time you are online, it does not have to correspond + with a commit or anything else. Generally you will do a + number of commits locally, then fetch data from the online shared repository + you cloned the project from to get up to date, merge any new work into the + stuff you did, then push your changes back up.

+ +

+ In a nutshell you can update your project with git fetch + and share your changes with git push. You can manage your + remote repositories with git remote. +

+
+
+ +
+

+ + docs   + book + + git remote + list, add and delete remote repository aliases +

+ +
+ +

Unlike centralized version control systems that have a client that is + very different from a server, Git repositories are all basically equal and + you simply synchronize between them. This makes it easy to have more than + one remote repository - you can have some that you have read-only access to + and others that you can write to as well.

+ +

So that you don't have to use the full URL of a remote repository every + time you want to synchronize with it, Git stores an alias or nickname for + each remote repository URL you are interested in. You use the + git remote command to manage this list of remote repos that + you care about.

+ +

+ git remote + list your remote aliases +

+ +

Without any arguments, Git will simply show you the remote repository + aliases that it has stored. By default, if you cloned the project (as + opposed to creating a new one locally), Git will automatically add the + URL of the repository that you cloned from under the name 'origin'. If + you run the command with the -v option, you can see the + actual URL for each alias.

+ +
+$ git remote
+origin
+$ git remote -v
+origin	git@github.com:github/git-reference.git (fetch)
+origin	git@github.com:github/git-reference.git (push)
+
+ +

You see the URL there twice because Git allows you to have different + push and fetch URLs for each remote in case you want to use different + protocols for reads and writes.

+ +

+ git remote add + add a new remote repository of your project +

+ +

If you want to share a locally created repository, or you want to take + contributions from someone else's repository - if you want to interact in + any way with a new repository, it's generally easiest to add it as a remote. + You do that by running git remote add [alias] [url]. That + adds [url] under a local remote named [alias].

+ +

For example, if we want to share our Hello World program with the world, + we can create a new repository on a server (Using GitHub as an example), + which should give you a URL, in this case "git@github.com:schacon/hw.git". + To add that to our project so we can push to it and fetch updates from it + we would do this:

+ +
+$ git remote
+$ git remote add github git@github.com:schacon/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+
+ +

Like the branch naming, remote alias names are arbitrary - just as 'master' + has no special meaning but is widely used because git init + sets it up by default, 'origin' is often used as a remote name because + git clone sets it up by default as the cloned-from URL. In + this case we'll name the remote 'github', but you could name it just + about anything. +

+ +

+ git remote rm + removing an existing remote alias +

+ +

Git addeth and Git taketh away. If you need to remove a remote - you are + not using it anymore, the project is gone, etc - you can remove it with + git remote rm [alias].

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+$ git remote add origin git://github.com/pjhyett/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/pjhyett/hw.git (fetch)
+origin	git://github.com/pjhyett/hw.git (push)
+$ git remote rm origin
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+
+ +

+ git remote rename [old-alias] [new-alias] + rename remote aliases +

+ +

If you want to rename remote aliases without having to delete them and add them again + you can do that by running git remote rename [old-alias] [new-alias]. This will + allow you to modify the current name of the remote.

+ +
+$ git remote add github git@github.com:schacon/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+$ git remote rename github origin
+$ git remote -v
+origin	git@github.com:schacon/hw.git (fetch)
+origin	git@github.com:schacon/hw.git (push)
+
+ +

+ In a nutshell with git remote you can list our + remote repositories and whatever URL + that repository is using. You can use git remote add to + add new remotes, git remote rm to delete existing ones or git remote rename [old-alias] [new-alias] to rename them. +

+ +

+ git remote set-url + update an existing remote URL +

+ +

Should you ever need to update a remote's URL, you can do so with + the git remote set-url command. +

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/pjhyett/hw.git (fetch)
+origin	git://github.com/pjhyett/hw.git (push)
+$ git remote set-url origin git://github.com/github/git-reference.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+
+ +

In addition to this, you can set a different push URL when you + include the --push flag. This allows you to fetch from + one repo while pushing to another and yet both use the same remote alias. +

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+$ git remote set-url --push origin git://github.com/pjhyett/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/pjhyett/hw.git (push)
+
+ +

Internally, the git remote set-url command calls + git config remote, but has the added benefit of reporting + back any errors. git config remote on the other hand, will + silently fail if you mistype an argument or option and not actually set + anything. +

+ +

For example, we'll update the github remote but + instead reference it as guhflub in both invocations. +

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+$ git config remote.guhflub git://github.com/mojombo/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+$ git remote set-url guhflub git://github.com/mojombo/hw.git
+fatal: No such remote 'guhflub'
+
+ +

+ In a nutshell, you can update the locations of your remotes + with git remote set-url. You can also set different push + and fetch URLs under the same remote alias. +

+ +
+
+ +
+

+ + docs   + book + + git fetch + download new branches and data from a remote repository +

+ +
+ +

+ + docs   + book + + git pull + fetch from a remote repo and try to merge into the current branch +

+ +
+ +

Git has two commands to update itself from a remote repository. + git fetch will synchronize you with another repo, pulling down any data + that you do not have locally and giving you bookmarks to where each branch on + that remote was when you synchronized. These are called "remote branches" and are + identical to local branches except that Git will not allow you to check them out - + however, you can merge from them, diff them to other branches, run history logs on + them, etc. You do all of that stuff locally after you synchronize. +

+ +

The second command that will fetch down new data from a remote server is + git pull. This command will basically run a git fetch + immediately followed by a git merge of the branch on that remote + that is tracked by whatever branch you are currently in. Running the + fetch and merge commands separately involves less magic + and less problems, but if you like the idea of pull, you can + read about it in more detail in the + official docs. +

+ +

Assuming you have a remote all set up and you want to pull in updates, you + would first run git fetch [alias] to tell Git to fetch down all the + data it has that you do not, then you would run git merge [alias]/[branch] + to merge into your current branch anything new you see on the server + (like if someone else has pushed in the meantime). So, if you were working on a + Hello World project with several other people and wanted to bring in any changes + that had been pushed since we last connected, we would do something like this:

+ +
+$ git fetch github
+remote: Counting objects: 4006, done.
+remote: Compressing objects: 100% (1322/1322), done.
+remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
+Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
+Resolving deltas: 100% (1526/1526), completed with 387 local objects.
+From github.com:schacon/hw
+   8e29b09..c7c5a10  master     -> github/master
+   0709fdc..d4ccf73  c-langs    -> github/c-langs
+   6684f82..ae06d2b  java       -> github/java
+ * [new branch]      ada        -> github/ada
+ * [new branch]      lisp       -> github/lisp
+
+ +

Here we can see that since we last synchronized with this remote, five branches + have been added or updated. The 'ada' and 'lisp' branches are new, where the + 'master', 'c-langs' and 'java' branches have been updated. In our example case, + other developers are pushing proposed updates to remote branches for review before + they're merged into 'master'. +

+ +

You can see the mapping that Git makes. The 'master' branch on the remote + repository becomes a branch named 'github/master' locally. That way you can + merge the 'master' branch on that remote into the local 'master' branch by running + git merge github/master. Or, you can see what new commits are on that + branch by running git log github/master ^master. If your remote + is named 'origin' it would be origin/master instead. Almost any + command you would run using local branches you can use remote branches with too. +

+ +

If you have more than one remote repository, you can either fetch from specific + ones by running git fetch [alias] or you can tell Git to synchronize + with all of your remotes by running git fetch --all. +

+ +

+ In a nutshell you run git fetch [alias] to synchronize your + repository with a remote repository, fetching all the data it has that you do + not into branch references locally for merging and whatnot. +

+ +
+ +
+ +
+

+ + docs   + book + + git push + push your new branches and data to a remote repository +

+ +
+

To share the cool commits you've done with others, you need to push your + changes to the remote repository. To do this, you run + git push [alias] [branch] which will attempt to make your [branch] + the new [branch] on the [alias] remote. Let's try it by initially pushing + our 'master' branch to the new 'github' remote we created earlier.

+ +
+$ git push github master
+Counting objects: 25, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (25/25), done.
+Writing objects: 100% (25/25), 2.43 KiB, done.
+Total 25 (delta 4), reused 0 (delta 0)
+To git@github.com:schacon/hw.git
+ * [new branch]      master -> master
+
+ +

Pretty easy. Now if someone clones that repository they will get exactly + what we have committed and all of its history.

+ +

What if you have a topic branch like the 'erlang' branch created earlier + and want to share just that? You can just push that branch instead.

+ +
+$ git push github erlang
+Counting objects: 7, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (6/6), 652 bytes, done.
+Total 6 (delta 1), reused 0 (delta 0)
+To git@github.com:schacon/hw.git
+ * [new branch]      erlang -> erlang
+
+ +

Now when people clone or fetch from that repository, they'll get an 'erlang' + branch they can look at and merge from. You can push any branch to any + remote repository that you have write access to in this way. If your branch + is already on the server, it will try to update it, if it is not, Git will + add it.

+ +

The last major issue you run into with pushing to remote branches is the + case of someone pushing in the meantime. If you and another developer clone + at the same time, you both do commits, then she pushes and then you try to + push, Git will by default not allow you to overwrite her changes. Instead, + it basically runs git log on the branch you're trying to push and + makes sure it can see the current tip of the server's branch in your push's + history. If it can't see what is on the server in your history, it concludes + that you are out of date and will reject your push. You will rightly have to + fetch, merge then push again - which makes sure you take her changes into + account.

+ +

This is what happens when you try to push a branch to a remote branch + that has been updated in the meantime:

+ +
+$ git push github master
+To git@github.com:schacon/hw.git
+ ! [rejected]        master -> master (non-fast-forward)
+error: failed to push some refs to 'git@github.com:schacon/hw.git'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again.  See the 'Note about
+fast-forwards' section of 'git push --help' for details.
+
+ +

You can fix this by running git fetch github; git merge github/master + and then pushing again. +

+ +

+ In a nutshell you run git push [alias] [branch] to update a + remote repository with the changes you've made locally. It will take what your + [branch] looks like and push it to be [branch] on the remote, if possible. If + someone else has pushed since you last fetched and merged, the Git server will + deny your push until you are up to date. +

+ +
+
+ +

On to Inspection and Comparison »

From 967b1e1c29662ac3c17a15ace5186308081f608e Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Wed, 30 Dec 2015 17:14:56 +0100 Subject: [PATCH 02/22] Update FR layout --- _layouts/fr_reference.html | 72 +++++++++++++++++++------------------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html index 9cb4cdf..7cff60d 100755 --- a/_layouts/fr_reference.html +++ b/_layouts/fr_reference.html @@ -2,7 +2,7 @@ - Git Reference + Référence Git @@ -18,16 +18,16 @@
- Git Reference + Référence Git

  @@ -35,63 +35,63 @@
-

Getting and Creating Projects

+

Récupérer et Créer des Projets

-

Basic Snapshotting

+

Instantanés de base

-

Branching and Merging

+

Branche et Fusion

-

Sharing and Updating Projects

+

Partager et Mettre à Jour des Projets

-

Inspection and Comparison

+

Inspection et Comparison

From 23e56ccf816e451d50d42eb7c23788e1dcb230a0 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Fri, 8 Jan 2016 22:54:16 +0100 Subject: [PATCH 03/22] FR: Update layout --- _layouts/fr_reference.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html index 7cff60d..1f929a3 100755 --- a/_layouts/fr_reference.html +++ b/_layouts/fr_reference.html @@ -76,7 +76,7 @@

Partager et Mettre à Jour des Projets

-

Inspection et Comparison

+

Inspection et Comparaison

  • log
  • diff
    • From f8dfd766dc824c53bbde932b77ccb198d5eba647 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Fri, 8 Jan 2016 22:55:00 +0100 Subject: [PATCH 04/22] FR: index --- fr/images/snapshots.png | Bin 23231 -> 0 bytes fr/index.html | 117 +++++++++++++++++++++------------------- 2 files changed, 62 insertions(+), 55 deletions(-) delete mode 100644 fr/images/snapshots.png diff --git a/fr/images/snapshots.png b/fr/images/snapshots.png deleted file mode 100644 index fe87f63ea144124fce16c89d19efe8db6c1bbdbf..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 23231 zcmZs?b95!!^FExMiEZ0||owHs0Lt{oLPQ?^>sO^{U>x zc6aTwtLk}bcbL4aI6Mpv3Oc( z0wJQ~r5K$Q(bMmUr~vUs>-9yK_vMwpeu#>mZ)j=~`SB5Q{)!4>RT^ya-IJV`o={5( zF* zHtSn7*BT=y9(o?L?TYuuOgBhqwwTr1TfSF62ofm>$Z1HBXs&x$)Gv|?Tgnlie(4kdWHGw3rbfA{rbgwPFE(T@>paJI8tXX>B3wv1A^=1$fD@Du31SBb zK?P9Bg?98qW`g|Q3)%{TxCQGE#0mvm6Jeiy!zO~<3m}n)k@cI~;%x6wYzXovW z1;GN4>Z5f6=C=5r02sevzyw`G;h2T-kO;{Dl7cX?IEC=of*7&*djK~>hR5~CG)L*j5J$Q*UX<}+LLyH2@H087GIT`Ql+GwQC<1Y{WV-PvBmR5R zD?ez+7UJ3^jSAgZ(qu?~#bpg|?*;5h+2gvUzQy?$K*_UFAtc&LQ51#G%DPECOUV^u z7W^&Q6wCqYN$AOK$_ey?uwF5nF>x}BFyon)8XXzA_Cqn>Fk7%#|BN)EGqyCwGtM+3 zVF_c!W_@NZVpU;rV(Bt|85|$$Oj?fO3TsPjOM2$Im7}3l$vP4Gk)Nzsqx7e=g07Qp zg)W=!RlQu@UA%ioA_4q|!cAxH` zcgQ;*+@f#Rw$iqX4psK=cP0+3cD#Ov>?RyK?5|F_gk53_1nUL+@c3|l zl7AcmLVY`ZGkOL6DEy!W^K;8{YxJ}AJGLs3Dq_3k3#Xy;yz|HnkPSSxz54F^7|o2+ zA?Q<8Wjchl(DK4KLklC=!eqi&B2FU2!c-#=A`Au+2i^vw!|ucB!=%GI!U$0=kv>U? z$+oHNw=Lr=->ZNt-BG?*QBu)T!CXL_@0+(+Fr5!t=$e-+ zjj^cx#c76S#yeeTrfFts{$M?5#lDu_-6Rb=JG-z_;G}e#(%kG^?i}*Kh>xGe$DP#< zRFmWQ(ISpm@iRZA>~D?SV#}gHzJO(~Y3+LMxPG7f^z>%!knN z`lfED>ibamoFBPA3MRs<;;gdIZ><`wwpTUJk$7-B6g$j4z+a7D`5`eN8ABov1n{Hq zVe$01C3(oX?ztN{UpYBAKUb{Vx*T6CBhsaV$3kf**oT@{qfQP^otN=C!UYRh`{KKH(V{Vw3@A~PeWAn_5Jjc-gZ#xh6h$1TQ9$7Cn7 zN0}$u635~@cwA0mkMmyo&q9Z;B+3oiByve>v z#i`OM&50J1grT$h$kA>qezK_8{rUwJUIrc#R~6TVy}PS(_r^9sV{U?$MvdY7T>4lw zi{3;#gpPFQLlb$cN&Q08y+Vel)|Auv>ED(8)n7K#)|qEpXH=b%KCBg}$7^$Kp0pQ> zf2(V&moI!T$_S>iuU8pba@Oj4ZfpOxKkDYVZLW7vxLn@h-ao=&!8xwa^|+jNZ@g;- zyaebV!Vx$kVk4}(ncdW0#yuB!^e^@c$D9)iU@!BtJPhoP%qxACG)(nndwCJOdb&AI zVVTl7WO{dAfgeUBpf-lBq`)xNbj^A@dCc0|yN)_poZL_T-P|Di(Lcw-hO3sPEB|`^YkCvo5d1Z2?WM$KP{S$jP!3PKCQwHqY1o+1Rz{kO_ zr>%EWd&`F5s^$Oh_u0aLbd0~>l?JOn&4-5s(%a$yBCidSivSAjd$YOkaZB7>hUm>L zoQ9|i6m)~aVFJ1ZTQEh{gF#OtRRaDR7&D!Rverji^`HM zvtjB1LoGZb!s9vGPL6?*@)D5q>J8@e?(5~};;-Qh5y%$u0hJPQ70z3KDm$+kX>X~% zcKj43l2@3zu0;J&mh%8{cKYMznvDk$SmZasX>|~i=w&upJY=~*-E7|yf&I0T?}tRlY=kP z!uJmFrzzAw@YJ3%f@)@~XEX;ii&oKUXj{hCw=RL)8ylWWZikEK)g9}P?icIb9wj9$ z1vTf^zdoD%hCGrU8z4yuI1#b=mA%Qnk6&ZGx>_3_jU<&&W}67eVclc1Vjbe-c+GIf zeX_hIo$n=6CzsjO5O%h)dAU;DR88>Yxg<3BH8@-fPrEB$XAX+L{kf1c&w=mO@454y zcroRdOSRFM)-coF)0NTod|1DDy(I({I7oT;DE!oDrmI`4H*8~RNN*^v|9)Fxyl(I1 zD>a7I$-drN?T@4nr zOz^n*ysj!jGt)yyCX03vuj>X`cMQPKzb2^5j8PQEJ3g@_7>_lRSNJp{}R z5!6yV?rP&jOV6$ofr$gZBrg-%l<1TmFU(hXvW60?>o>Q1CnNU)LRjTYbjGd6jz_v& z%=WIvI@{hB00%JVsbv*lO1Kj zx^U@!>6~~n2I@w(qv_?W)z&cI+I!Dk(=JRzsdd!wS-Z`>G+7nlw+Wu;w~s82xJ8si z^kgiOx_OM@XX%ddmvmUauR@+(YOMVwocGLSBYTxUL;hqsHQL#2ii?pG%X#4Kxa;&} z`$^}rGdCacj~-{IXL zF>DX`Ebf4WFxvYqk-5=7JWpc@$_v8Q5C)0H9;E~P6)7b&Wk3$4{J1adg^XYp=9zsT z`CTWNVMt4+Ydoe*iEeW_^o#^=C9_)ldQIG|`U>HC0(uJ^Jg^z+bf!||Oyqo!ZqSLm zkgO~|La~1~ip8xy&wlYH9A+(?b8wKJRZ1@DRasMcsvKWsvjjQsxP3ugS};Q`q_m;% zRrNB>yXH50zk}GH$hjZRY3`|M8MKz;SAcU8#6rD4aUMrma;c{F@ZXxtwiRqjrXqV-Gps&{*wn7V-r5d+&3bO{jK@FToN0~^y?h?bacn?y zqJu=wfo|~ve60{cmWioaKEU^T!j8DWK_Hz#=pz**OKVkrVqPM~2OwT@Yi2#~?U6b1-T zAgLqge;kmA$GuXsjp~kqbz!_yCvw3XV;L(ORO*wkk~2*(t+Kkv50*a96Vh$aJ*u;- zGuA@aC)Fw~-*QsnwPm7BdNN>CD_VPB%<&rX9=a8|;XbiFy*%?hr+~qL6@gzuxxv1p zFqBvobs?2iS&Y_>8wxIivY|}F{rje3UvQuQy7ZBeHJ_KfV@v3-B<;m5#jO8lk z*e6JZS)^+wx`&F@n)a&7(L-9H;o+l43S3rR8DHex*aD(6X~Jb#E+UpGc=lpZOcx4W!Xxikx0^Y;fx$3*j+ zU@>~4e~Rtn-x=&V+;<*4R_6SukmJZ9fl%k-X^X!idJAR7a{8>G%!JGSI4$w|@nMpH1=_tLFBbLt|)*4|b${4;JMjuL;AfJ+&$V*m4+C=0f zI3$-W{!pf!*VzRq>1#9`O9m84>|4=Dm9JT-H;LZ6;Gm|*v>=$R&sr~Xm1tGE00kzA z)|kerhBznoT945iC=bSxJ5{+Cb-y1s|7>1w&S=zgHg=A8Xx_{|QM}|npX}-HFX(ev z(ORKgd2AQ>-pgG}W#(9-FJX2RWt$utI{cd|=qO&@Qrq%PCSQ8C%lJI;h0oI?rZ8?6 z7BSS+(bU~EAhTR}DCF=a0#*k0Z@6ZJl62*$*?t8jp=xH?ir30Hw>h-VhjaQpP^ zobF7&kZrUAs9kajr(%9n%!8PDM-1y^+RE>h4wh|a^=JKfBbkPoq}q^eO>Jtf+^%!a zku%-?&VK5G8ov>Rn)>qC+*aZxT8@yJ1?=FV#lp--Fv{@E8L`KMm~(6p6%T9i%i*#CLU8h+IzoZ z!^Q6vS09jkK@l^NMBgI6?Stdbbp|>%jPu)-wbU6tF5Y?ff)?2GZNTMQCp`T$DdNj3 zI(GXqWXK9o`(r!$q15u5bjYjv>RUk5xBSR+`N-%XOH!jd4kpO(ZzM*R_#bg46yVtE z1*wsvF)!k{@7GFobE|mgg5T~+-|Uquvq;0usV*X;8#siRNy9hEz_~a-jT*KNZJuKA zg1`AkO?a>Nj{jyh#jR7HMr6v1g^Gyc%B|B!*9R5y69^UM>3*BBlz~vs-!uvSJTn1; zT#2#Ul``N2`eLJnXD4(_yeB5`_Ui{+So$}hwnDTpK@dx^l#h|T+f^ab03 zVv9g42;U*$i=Zx)eKWd(xW{|?8IAkV&j2}qA0shu3nSEo`?-D?gTZN~3HkZ@?2`cs zMUdI?{qZM++2@|A9FcnwD1uJO%^Uo@Nq95dM+*Ir0I{jCF%ohb7CIgl8fk8b^N$y4 z*wmocQ7KreQQF}EpKq~|H*QQC{(@ipJ+!TahQk+ukMhp}`ZH(ti{2*!krWYB{vz=GxNtm=Vd~9O^aQuPQyG&nz3!41d$mDpo%j=(>i<7oS zcUs*d-}dNebQ;-&k#UGoUrl#fDp*x2(DojkV7Lq=!a~L$Yu?07(}A4@5`ZSL7Voif zI6@)6MHcMw2$^x7`#9gsl|GI3n5sw*tmgv54ia(t!e|tEBjpM)3{y^`gb|B!)T>!r z=xGT#6#IRz9dAyLd0XjgLoye_^>W7bv+e*H)#pKp-kDC`71vqW$>ARS!Ad!bGxgn{rvURbr zJ8{qktEo zE1jV?U?*>XZl66hBg5#=;Y{2Yn+e*7Qj-)Y zwOc|rYHdS>Z};V0u7M@^2NV}|7%gi8d@&R)D0wNb1FKAaNmn6UkMc4&Dn(3SQc|O) ze*sq*KeDZDt?=#%quOsnU0IT;T1ASzY891cS1Mo&9EHHfuEo>q%hdGyUJ5Sq<= z1xU)ZP!)l7F=M$Ukp~uvP7OLbUG;ie2~ui+b#=4wK;KkkLqxaM#9`a1|Mh?HT=4Mp zaBTqO1{?H_acrFB#_19Z^VE@0gT_=@I^qOP<8Weq2mOVs6SY3NCT0Y0u|)3SJR5Os zi1T7m#4p@{5jC%%i^Bx^vm~5*wxf`*eqp(nRt_n41z`NCa9MhIT>bT6zR+fm7PIno zR{L?;2=ORe#%ghp@9?dL(j@NIstAAWm~-(mtsMEiP}WEA;Br9VL66Y-X5tU|WWNzq$d1eUm`oVWR)v z81(;)q3Y#e{{O~+szu2a{Ehsd%3{&49&_b34D|mE3lFLaV515TGcMfu=&CeCxwfXz ze*;szTo<>1=*VaKNIyWqkOXE2i9;jCku$O+ZCo0Y=ZdH#1{oD>4k7)$yl(MRa}5h0 z3rhtWfGJjQJNy+)ZKvz5MeEFhP6hM3I|{&3KgU0dkYzu*sYj8|KVc2Aa*CTqZoj}x zge=MV1YbAFxGoiOvm>FtMM##iLqymA_jsxE|*J=}Jdn zhnw)`Li<wp*p>X_F_#&{$x>?TymtZ+7*xa@!j*$>LksDhH$d z3e{Oo2V|2DecTTnfD>Q?*k69;t>i!KV?q`iU20Onq;tycQjocGO_NOS6V8p`7}4$m z-|_j1zGyvqn*Er~_syu-1t|L5WN!(3{M6-QL$^^u7k=4}{-mE8D~7FT^wBpXjA_S~ zn4WHgg|LHiJ}l;JO5RAg3Yv6xBU_N1o#HOHCCKX>om1nKMXTk%diMO}Y^o&rmcJr& z@EaXVb&t;n{p1WkfRV#I!8Rbpg*X2=9U@(SGOEo?Apva-?%a7_*vhVa9%DfqM^kIM zBipw!RUQr*##hb7)ALTt)5Q_O^Rj|qYnI0gA^*UWiW;O_TA)9@L#y^?56<;+J)FAf zfP|t0Cm1Xyq*Y{PX2N!|oj)G1#qNc3aDfGK_WmtgwF~Kpv3wlf&*RW&4U0n(6l#f? zFo6QFdYI|&p7^K9LBP|?kst7l%FVu+lZtUz$(HX4Q6yV=!#BW%;19N@KqD7Q*|FOQ z=MdPa5RvI}NjzZM`o+}~zYE~Nfk+Mx#4eOAiCk6Rec@ln!e_o1hOv}c3vD}vAaYzh z#Cr1PthXF(pkKfyv}^?RhF)#HP!)#nD>Q?z>H z8&gO&&&K>pzHo=pq+}f*%pbYWf<(Q>ih_vR*lgBbuf3j5_$vCNH1F(yTij;krHdy9 zLx9CH)Pd8L;F98+QyS22woh@V&PJ7Y&6KeZau+uY47h-hYX1nkR{8+_aQQ-5494dB z&D{FE*wMFS&}WO?lY<-KJd`54X)CCz^?ew7!lOruqayiexq=!c{^MKaNu;h<1_^mm zbI4xQO)8IC(9e+a+78)OOj@~;=a#Z)K@W_rtW>=%wNFI42z6iX`0;c!JOh9UDbNO& zheG7H)eC0ovx&3`LDYKf3^}Z@r_FEw;9NzJ{w+t3v+zlt?nb)GE^imRA*7d`A!&X>@Q1x%+1Wt%J3Gq~ zOEJ9lplY^tm>QdNe@X$lFG5=^K3n8fUJXvp!ra0)6BCQ< za85GKMG>vfw{`+k%-_8YDO94%)zdK_DQs&f+U@Mg3X1>4IK(ETQQ*^W{48u$10U%u zP>i6McgW?EcYttmpMa>6NTzAirfb??lR@i!~BY;%^%SL^W5 z6Aaem3+faBa%Gi@tXRVt`T`2+dR6a-s@n>4n(6oCDFv`0%H@h1lrMyftr`7fQFILe zMdU=-TkL{!#Zurvw^np+t2g*8Ww&)2L9JTahwPemZxz1DQ3_H%;>5q6A08f{&0KDx ztY6OhXFq7OYY}~y;8|CskK>Day)Ee;7E6=Iu(2Z zUE@X6NvrFfmS%eYn&uLxv={8GA}Z#y$NoK7sY|-_Nr1KcJ^%hJ!gtNXZ#qPtwDaTx zzlw-szvW#HW&W7wqasIE=oymG$z|jq4?_QAcTB@~*3>6JIW?n+%Goi^quAC0?jYe@ zD~k0g`YFekT8u_hGMrJAyoF~107o9i;Mk|q?kx1sDH<9eI(hRt4vlXN+PQoN*Ir%u z+vcpDsj}XjNC+)qzxT-+_|HuGa^WC)MQ{>`=>K)%bofrdK|)ej)IvDqoE;wO+P=)y zn)la{Lqsks(k3~Jte{h5EgI^N5Dp9ygp&8ig6-=Oc_9%tCgNtWt8@!0=Cpzn9;X8p zpyUy+gyZ8^tL;1Sx}_v>?$bhs#xSxb#|;XNbsWAP!L(XbK}53fdV|YFEUlEt%&*j zCK*?RMA&wYyK%iDSJ0XwBDR@ZbMhI2=uhq`28}Ot@gj1YalKKrg28@I*>fARna`WM zjetpseI@biFG{mXRssVXUONOH@CJ@C=XySXV#ZdoE=%-P3`wy*yT;1U3;! zabo6uX1b9xBJL-Yi@6kb#kVDLGDRDElJ(s|C&B{v$$?;nj@)LuYfJydh@9<4a6Vjw z+^KWk4#QnZ>El!1H2UW9>UavMC0;<6a*iR}^9}8|n}#R;6}3NQX}s$raY3oewz&r; zEDvJ>T&e0ywP=5bu!5*IFsmh3($I&x`>_AKyap1%@MZ7i$-3UP;Dta*wLAKplvX~o znb9ozJYf%O(=Pi2%&-oZb@d{7u`Ag-!fp3d!meV7|H;vvjQ^AaJEM@^`YMYLzJ`7J zqC4LCiV&5G8FcD8$ADqrFX-*?lAK#=h7X}9Hzm-7Q3>A&wMVpQM$f?RkmyJE`Oyk4 z&pK{1_Vtpctd)WJEs_j0iKse$epwe4qjOb_^YFa$7Sx?CE2v(xO40p;;1+^UD<-dZ z?qpPoOs*{eLxq{n9Q^Fd5=nPK$=t4TIgubQFkyLgk()-{YI6K^sC&gy_}ZplOt+FIH7A-Lj>b<$PVeYJ;m9s_OG^b96lgvV^{aU@X>_urYG) z#qw$_AJp2{(x`77Qt5Mh?Qxsz9Hz4#n40kXso^OpGnzn%HiJ6)$wPEK;FK*JAdR6~ zTk@+Sm#8~OwuG3?0a9yemFl$^M(VM%*`!EbF0BZ?@(ze$4O>*>m)l^XI~pq zCHi}Rr&*o}v#u$(SsrSrkJZiFWBmB{h4S688PbOCPonOly(#w^t`Wmux0O?U&lz~2 z$J~tV^Qw~%@kx#|W!am$w2ES!Onx^M^6{sgWagt<)%iDbk6$bPJE&;hp4Y!%{wuo& zx}oTk=kl7{>;5N#3k9JCg;3U@qxoN+?RP`gD+P3$-Rt}>(!P2OV0Nt zeUp4|3P;?S|HBMKU->+iyh&Z@e|kp~d<(($O!tRJS(PSF2T_p{fOb^)esAYQv`YJ> z`HsuB7XN7T{f#950H&VaG?T1OVUz{T2q7N2{hODT#Pth&P}$ht*`nGxe%D9LqQ-tr z0?Jm4s+)wcm~XaCZ{W{5!v~RU-Xqve4_7Zk(xyEf4xFKUu+?d|ntN3G8%1n-xg%~hgV5T!I8Dgj34Q0d9Iz1_ z98GP0)n=o$;QxTun+Kz$mb=?pIV*KMN-TYXp8Vy=WHRZ&4f{O}BYa{neU+Frjn_-o zDP{tEBh{3Or9B9rl2>0v-L)%_p_~iryPq^>wFL~&MhH4QKy73jDr5%=sUl~=d@`#I zq)q!zPlr1uBYbG@acB?Qtm3P06(Hjyf5^F#D)zsf-Sfck!WwEh| z!sbx1va!P7*70pBxr_E8o7uQhbv0X<=>x`%O*b=iN20n1MzEL799_<-3APvvR63%} zn}%d4a25LYGRJ{X(+}q%uHIc)d-G14%IZkDCO>fTO<+F@$~Dy0lpy zu%=*u%(*w`(R%1@{_Z2)qb+G_@aeuJDt>F;l^}`LC^l}DXduMd#gst$UsVcK>1i287*(&c*1ztZb#YKYMZcT7`@|wJ@mSxd*$T&N=NMP< z6^qLCTBZZ)o97FLf|Fj9xyTcP2=rr2V$VlLM?ZR2Pbc@WArr4$WyRz`)5gcW94m-| zWUfK$?u;pdrGVFrlHJs_lwOnPgbZeMU^()D`N4$yl(fH&*4yP06QfMcauye7VdfNa zBRDF*LjS&=+~ABU8kksn+zJkP4L-oG6)4FjoqS)L5HnC2(GaUD$*iBxu(Y;}%r>(A zW!LDw3DI*JCBIJ;ntCf}YGdNyu#n~xc&)@`JfeZ*Ck5(+Pd`Dkw3MEKz5c#G6ytN= zTy7xHT<((96IE8ff3R%2tZ{(xxr&seF5d>D0)UaSq+69}I2SWXljR8c8&xEujX)uf z@kMGh&)S8Q(pS=tU3|4eUCHk0Kmi%sBjme+mQ?7VN-BUQ zrds6`XiC$6=}e<9&*sa#NRtxwKcWH%4V7At(i`kY-U{Rln?XhTqDB5;KokJQU-X2< z@{c>kLqpd8^Kn3LK=BKaaewcd8ldK1k?#mHlM1;n{I?$$iid#z*Q^q3kFxLdzqgPH z{PM39iZj|W|GmL8^gm*6v zrXapiouOA7seVw%G91Ek8cpTqC+HvYbUsGlzErkM=l}tELBct?by$kzofN^I`@7v< zu*htX_1lE9*x%*;2R5*Vn~Y+JelS!p)+l~7+MVY$MS7~;fQXFkQO{M^Bxo#FznoHA zLo6bnR@rkhichhx)KE-j%Y!Dv6~YXXnXWTz#a|K*F(VQsw|sk{Q5g}mlvbybP_gDJ z9vX`Ww7qS;goPk4#~llZ#+BqfCK~t+m5CUTj~`0FbWWs;HQ3Nc<}XPNTHcbWUX_lX zz9F{4K$G>=h8(b|U@#b3<6lLJ)> z#>~pPpTk0WT0uCOK$S?ZXwlWzX(^KX7{r#wZS?`gV!&5yqVCA&#YB+Qe3aTO8ufSc zz0ac|m&rt$%&}20FwpjkAV6ofcb}M8WLS8e!q?31LCI^iN(FW2)3hETuUbkW$;d+I z!pP;pVB~m(w&b7}D=%xSQpCpeA~rHyfEucwJ$k-=nJX0q)Buq*8`@`@btjt|eQhrh zL}fqxS|0g3HRjtCm`n`F`Wb_K*`U@mclco{0Vo4A>NL`l7;_$6MGkyA{t$tJO9ZY5 zm(!>?N2hH%)sBZI#nIUo`agw$fv2CL$LJZ-<6t*X(+xx#yr^aolH>5PYWC?=Auu&v z)u@zIrb)OD6Ep+;pKa2!gJKMTtn&vC*C8nlCBT#sJ{^Q_jw z_!e8( zH{_3mOIpz&X!rK9(mh`g9n9e7jrLuqyZQcd$?zZud^tTg2CBS8G=b`Se(2|qFuj~S1q!jQb-EtO>VUcuNaq0DsR_hfVQ!)vG(IB`Z& z68XzZPuL=T##WKk?d81+G z$cq_MHN-3tL=gm#$O9^%M_5+BaN5a+2Y7gJF4gFw;p?odH5jv&w8b9Z$os#VfS8s? zh)XGbCrP}fy870b+-HQl)0&hm8RZNIAR6Hz_349Yc-)v1#aW1cqXW%=9QdOkw5Uz! zLGMJc4pmY+GmFV*5^ZT!vfU0@{F=dwZ0l?IvJX%NA=~VJX@u+usTFpZzSAQ6U|^W-Zt(UfLP%{ z;9`E4UHQ#0G1*GNKf{3c=Rc~S$uA$eHtgq&rz_)s+z zJM#s9dd(`5VTb-#n8-B)a5o5{XC*$e{13`dr2_X>Hn186uyrzhR}n9z!^;2uiiq}3 zV9M>HjCDY*5MSuycMXW&%A<*rI0}?b{M(MnR5gs>iZ8$gX5C^EfNHo z=-w36;@yF=*Q2HvNPVYMLzB44pL;%QsQP>8a`h*-vVVQGCj<$Knzfq_w;`9Nya>p#mjsU zQDh6XEbS)x^?}Hk9rKS0u!AJ|6vyz;SouaTH9P@~`#PA0A-BA#c&}kH_TDZp0l3g8 zv4MwesEDyxgl_b1j8nOw9jU3`t_uzBVa7Au6*FRA8QuSzp=?6XzwY?c6$w|mD+D@S z9=}UYiQZg3_~8oZU-PZ!dRR4`@q;(;JGW;{sWwiS;dF323hYvdkA(RxN$cyW;oGj9 z%@KMwK3v0g`uTPI7?uL9O01<`6Md4lS8Y&4yJiM!7&p$4Lt}ar^gsQXTkBT{dj^Vn zi*$MB6`lvz@i9crm25o^X^w4UG|#7}_xDjo@_BRYJ{wT<*Y3xP{xu{AAkE&cTt?z@ zgUg;w_XU;GOxo!c1_!&o0ncv#jaWo1#Avk-18NO9;vquT&}E7uolO!Mw-y}~Ygz#5 z+t*Ik6f5C)Q^qX8Z0f3!B*tgOwSqt5@qKl#Pbx&`-@RkV$qnzYMCiB!TLT5^o|QpN zBX9pC2_IfbB&kV$nXF1dY|I!n*6kPN%gaN;kR{OQJEFP#(8vh<1a}Ouw^!Ge9nw0; zJCb2nHa{ZIwj}Dmy#O(!iWl-Y^qvcPIbnmSuYKvwgYPWR>-;czj@F3?M?GewZ)^C< zW&50hMm&1Kn-jRg_T_=j_(O(ETivBn*iaf`&y%2cEh>c| zyZoOrz_o>d>GJKs&fCW9s2X>+Nv)Rr*H=Gi_4K2tkdmY2nQ@fri;3-W$v8g&j*0w` z-w4VDRENf>9-B}djv#W@y@!3d-z#kDnp)}W#*Ec|ThrkO&qb3^H zHM?-BRFf&E3@x=r=TY@9=Ajb0Q=>xIOamwqu4eYQj%M0nRLAedUuz!XG$8c#sz^;E zod*o0ls>JPA6U_MH!{M0*K}-O5kgD-h@0hV>k3;=Sd}^^F?=+<8QLt|UC6CqJBvJF zi$>i(iL%=*$xkUEU1U57k)8NfWJhu;6*XPQ9`&B78FYz|sX&m77M#1EVW!1)!to0% z1!Xj!pOP^RC<&dYrBz$)?|f+`#(~4gCu5X_OsrJLbEBJ$^<}Tws;E^V0>M`t*XTnNMSVJGjzGn{uBkR;?u05|sCVujh>$b1^DZh?jI8;gHbn~Z z-o6=Be(x@YtkkyVanGIwwiO7!Vm;j5V^4CE>@a%Lm3+ZOztNHnTQ(^ z-;JSItiI_`J7*uA5d#0rrOxJeNfho^4X@8~m+~B+PiB)Ri#j1OrUJvD6ZN!g#dvUp zt>%2K)%gyMq~!FEi}ebd3(<<7?BuOs$*aH1K1D*QM{r!ZXPc?_qk5yN89}Ufq(nc} zL>uJX#b+0x^>%$qb#4~JAUrn(ZGtj8%XRgO|0M>@)xAD;K*4qg*G_jV361t8EsWVJ zaKV7UE@XIb(DKD%)j`l6JrPu$#vAyNi}=_luYvv$dy7OLliSI1H;iC8!qW|;JGmR` zq)R{{0*#}M;#6cwOjj{ggo_prJgHTTMm!&ko3;(SO!pIf_ZHGb_py9Fw%Vf(whw$q z6VVY6oPCmG6fxSJxz&6&7A_}Enh9Mp&?&&=&pZ<~;=wGe%etFKYsBUw>|(C?G8k)Gej$;&+g*F zOS{brM%YW`>q3wE(0PSMJ@h*~MtoQckI|w{o=; zF)R(6lh7@4kvgYmaz}~{zrh%4B_@|RFgs&gZ3@LM?vGuDV&NKRIGCH&lj|I1u;k(O zDl)Mgob2EbIxQ?YTUf4Y=%})~0zE8byJ6me8RPh?IT4M;Vp3et*wF6){=dM}huY?f zu;kGV?ET3-RQ2vGvAD(XD26LSn8>$1O0qla$nxi#8QrGZd>auJBOVM1i1O~}7D|s@ zogVH+FOp`Nn}P0y)kbvD<0}%A8Gg_|X+UbIL~$(%-WKGLvO~HnbjYQ&*LX!9^i!e9 zUP|C8?lGnDEDmIm*BVAP$k(R~sD4N1pjd6`7q@8s5W0iWO2lT0O_<&~OmS!36#Ch# zw6+j3{UCqGUSmDont}y!fVfbMa^ml`*<=*V82QbK;r=be{OwTv z$Yh+T!Eee1PXQZBvrlRdbpN@KYT~WYnt|_3uZ9wy*0@AU%ix?Jg(vxPu%>_~H$Uix z%1I4)T~BqpU1N_&67<6&x@3pzg`GYauj}v>P(7 zbo>x%UgRtdIv37_)duuNq$jvsbqdE)SzjfctSlumV*M@pdqs@ zdu+Y?hk@MZ-<-$i5hKF*R}+-fPe2x!yq1^V=yqF=>H^4n6;B@X!ql7pR zMm(*(APvZY1GDiLPs+-4?@~O{aQtX~+{9(aV*$dP9u9&Zcz#!xf65-@LF1C~Mmv$UTaKq+i;v*}^x#A2<+KP)>{Zcz^I zZz*v>VM-2mDgu5em=N<_QKNApNUipB*lWdtd~sX)0CEZ#h>8`}Ql zCcS>$`XObT?V>zn36IQZzkW*dfiKYQ7#*YcUxmk(XF8Xu9I7Q~R*mxO#L5~-3S$9l z(gMvCh|&=GAN)uK=KX_N(BLosw@=E8@`~zf*HKcstly&0x+n}ocS|D;LwAF83WziU z(jh&B%+N6-C5_YoLrEhgNOyN$0qF)oQeY%LuJ=2Czmr?z23Ebox(n(Oj&7DhGBupoVZkq{xK1xt|60LfiS-^=7>%-ZoPD{Zi+;3g;wP5Fp70fHW89A!boLfGyme^p zG6Z9u;2$h3!Wzma_oK+Mw%G48*M%$AD@YP)bDr#sMQTyUrwbJ*#%K&yHth9H!#5UH zG>!QubqFUi|I>2#Y4W?Kac--Mw;B~K_*X;u=9TBO#y6E+wQOH(n~j6!8@jvV=ntq4 zy>M*X=LTe6*7zj6H~W<1u(c)W`xgUobwXp}J7LDP`CN-rS<8y-fLx z`Z?33Gity!>sd=6>oF9fbEVLzS}R;SLYl}J3o|$s`I>LH>i&B z`gaXSrx3}abxwd*OxZOREn`~H`%a9HL0H@gSBr5MYYp86Fy9)>wB>?z^10RyGLkdB zWIAALI;y*fo7Xe27RW83!y=n9zpGRT9D_lGC4(U&mx|NI32?=~Dj2!|`7B;n6q zs?neGIBpowyR9)qBXUI?2g>|KT(@GyrSJzTuFBuZ;?qw#&uF+V)=>8Df4?y(R+3KA z)rjzyXkx=y7Xu&vAc05Cio7{)n|2rZq8(HjKaqXgICQst?IjsV8?OosVt18oz*2J# z8ho%~O`(s#UPzO&{&C6|0hYog0s^P<7Io zD(U~^cumw_Pw<26)b$p0@)9wJ&ae_Af6D*H>j2Z2(5N(09QINH>-}C^V2l7vaYEbm z{!q)DR2(r#F?Ddicv_aUrzpx#7BBeZT&|-e_fTXQ1uokxoO8ZLVPFaV zV-D}gEDGQ(JAu+DMW-%MtQ*tz$K8xVOV2TzK;rikuQBfr@uOF3E9t6$E+SwC-8wX3i{XRp`eu!+HsD6=QF#7Fd(fq%H-@1pgQ+xD3bXS5?kiU+;VMHN&h2&qAMoS2Dm7{~ARDkPti zzo2>kG&kArkosQTtlcXEhY)>N|$T7jg3h{mo;qqlHEejpzQ6OD;@T+Z^m#OlY!P#7ex)G_J4#(!x zm0&V_YWHX(dgUKj8#tiIsqAVg?e>kMgNKZ;s@{u6w{MrBxkG|CkZ(k)SfwQIk4 zZuhi%sNVh2tXzKoGTD$y$*uT`z{QwZNKcfQ3%}pMTzT<&twqh_PFsX-Ao*v)recln ztho>-8goxb^7;3cAZjt!rRY9KSzjs&bmm?SC=yE_g23I)Kb z=AD$v&L#EoK>p+dB9N8NtCr*j z?8bNqHnp+1M6+YJP#gNJv41hlWwmc}cirCqU5G}atyCDszZkCU`=_xCTU_dB@5Oyo ztk<5`X1e`r+IRBT_=ZUhc3hpMuYaG9CV1Nb*p<65s{j##>!JLOjk)onTUoZhrh>n} ze}}(tH;2_pblLxl(%t4Tu@F1vAd2F$=8ecoUIT>IC#L~WkBQk`_$VcmSkS~6>mzb` zOmK8VtPGDC2(50P4n^MSSHA1EoYgcOc-8yRouB{k%^cH~bDh1zZ4X+!4fURex$T=Y zk-EdpKLn>BH#{8#__Ti--M#rRLUm|&7*tjb6*NdU4qbjvCs;PxI)da-swEP4RfXn9 z)Fw2x8I%c?gAI~@UuCtS*}koUj@`VvtBb8H=wFcL7^XTTH4WpKjVR(>x<0Cq2FCfY zJ|6I*g0Qbwq8Q7#?=QNXok*mxd^8e`7x|~y?^u8x!6!oIM_UmvyF09OhkcWT)J|ig zE?x6|GbZ5Ets9zMu|)cj2Gm0q!+X5=CZ{Ho>N2xV`t1_2G-?Fvp!d@U&JN!V z<*xY~275&Z1F^G18U5n?n;7rb!QN_1#-0U$zQ&0H)@RMds7}Q5Ze8EO#Bh#9BC=N)1|m z0e7*hj=s?8h3A`}Cv@84rAYFox#%xP2>37$FN8Xa03HgYB^7K@v1e5oQ&=XcuVFVp zg;4*4-aOLf6yk#|gL}Vf0-o^A0eZ}9>!pOTCx;UR(IwrgkgB@)e*J90EQ!>XPd`vQ z4Y6=xNprh zpa5z6A+-F_UKCb9h($}|SnTQV?ugXTtLo%f^K9^wBbgu4d=mC(rAt5y>BQ{q+wW2a zZO&j@{}*l;@~j4Dqg?kKmP;iY-)%WZS=Y#m2d5ziqEDv+QInvkX(glU*r$g{A7Gq_MIK!uL=*xAy+`4^s>6KuxbCG z4%RnHv_D0Uqg{oz;J4Q}lunY}mVeBc6Eo0dO%x;doZuiWpV<}{8d3lBTIUvsQ%gx< z*69P6`)ammSTUlNOCI*61Zg#dmEy^)AiD6_2gVhE&1j~8U7iml0j3=GUGYmfThz-go3xL@J62>DDUV8ETQw)i#&EaBexqvvhX~md`AQSwtvg{3DD#OQ_sy zOLqm>&!C#+(3%dJE@Bew<0mH>>`mHK_ZVyxoo-NYJJ1I5p2_g71!HTCHptkPswRZ_ zAYhKP-(F9K$=tF(v_P~p$<$PhsY9SlT)l*gi#nyt4T4;dOT@4tyVXY5hCle2uEDD! zw9~e?)@9n$_2WE}E38PprGb*0Fp7Fj@vLSM1vE9ITH>B2PE;(IYR}7k=j+P*nb!;> z-zv`CDU3U*wZ^B7MJy48L|HDlXGSpRSzbANUI-?PIr_*7HB2;N6Ra5AI zoS7W-HPDczx2Eh=HZ=!TDBKA0}zctc+YdZ>OC(NSQ}GuiGeq8kcFQn?OMmA^t`1!1NDo5Flaw%|Lq z_$t4No$cT%y_5@wf=M7Qo+lX_5%}9J|5E6TL{}GqXnczF=uW12TLDx^)mtgTE!4g+ zU#wXb&n6xTs*gBZ`gz!@o|wSB z(d6EwXaRT8h*bj&y#LcZ;qtc2YzHix?QzGBbXUXz+e7FO=^itL$? z!?8>9TCBD)4Hut8sQH%wY`F)H;G|tLCN)zDoxM?IBO^l}+MCTFJ5OEt?)k|#|M{v2 za`egy-<~X8j+x4gfCB|_D(T;9TiIR@$xUsA+uHh(4O-mO8k{I{^|kho1ax?E5!Cm; zwl2DmH^}eWS;vQRd>=e|r#W|&3?xdVG>@czV=1-jZ*2Z%N(Ko0oVAL~QCIx#4%)u* z#K8n745&D(j*z44vSD;NV)W?PZw21ik1=rF8K*L*DnD~6F08aHcZC*KW|_s;$pxm- z*{`%FPU;y61m~NQy{D7J1Ff9(pk1T4opM>B{_QKM%6GMJnKczPfg#JQvVT~dH_O;< zos33y0=(|6aRbYjn70QRmvqUjf`s+6Q1D8l^YdU#7yOhw=Jk{;%L#*j)*=~S?Wnt4 zFA(S8RI+MH3Vvq?6T{=1q`?Xgzg~p4Q$h&vyA~$JHg2x$o%U4{#5go_AY_7+I*1r= z`-YPy+*la~1Vn=)zwS4W<+Ci5vG#t(KngQ@iXpv))+*?AcVK*-`JnCAiJ+#MZHLy` ziZCdZtrpmuSA;$#v-8Pb;uF!dEdUp)m{2^cI}P%#w_D2fWRUSk4`{_j0(rFh(JvE2 z&G}Ss0t!DtK)~i1!BmhTwOV_+o}QYYW5e&lrpx;U8Z|`~sgepPXE~UTgLME`2^29iDt9hQ^ZkmZ`C3XhO7xnJVtvyFueD zJ_kH42pyVHG7I;7tHaO7Q}q&MBF`8Y;d&~N`q$1eSDz%s4iGxsZAMs=I#Dx`qprFJ z*^Hx>p!Fm5_^H!VTt6(Kt%Nz~q@IuW+Xno-xK01n*c`pRhHe0~=jGNvqa!n9vuIIOZ$SFik!v*?@6 zH(#Bg3z2z>oip19kd)Yv75(&3VMveLW!8l<0cSDgekF5gLn3}%cGD>jSg7?>)z3lK zaPWo~4X4yYw28vb9g2N)C@5*e^8Udr$W3QkPMCRVh+lFfOE_N#<4pkNvd9plK1s6c60Vp)Ysc zHl}MVMF>jfC~+*FXq@wv4yScJ+D0+4OZ*KhPW0EWUz0#Y0L#I0Q9sOguu;B3`Ad1n z1X6|CI3@Gi(U>I1nNCq8?JyVvO*q{!b9vmnCd&FA>}VRA8XKWGUy&CI_HrPQdKwGd zHi@jVp}}Wp+)Zyx)nP z3LO4kRv3T*M5V#&TBZzEXXXW?w2QrN62#hKeA+b32IVObUNK%l86uHh(PeU|wBf!r zlV1P=A3u%#Mf^J#V0L*9m-B>Cx`cxp1@cCP=Q|!VLJ!b)`^DS@{4zIlIg&igqipRW zgkPOq?s%4zI0g=&tpn9%_2<6zU3ab*?%#R>#2F{Yot1u*OGCAxKp_E`P;65Oq}jA| zNU=U6V}69%DK6j29FzT(4tj14RVT#vihd*jeluT1yPlEl!l57h!a~P!+clRO^^6*k zX_~dU^mQEQv$eHxRKm&&LFbGOwtH^1dm=Xww%n}`2#Ws@+i2wsoctJVTG&V&5bwCB zFNoU9bQ(#D;6=_?WZw{|(?)goiBrcF!5BFY^n1#GCNT|-2>nHLG?nBXB@iN5p#P_j z1qcA|PtNyiY8OPfQ3uTG&H4U)#pS7S`ueLhnQTV_4tx3EHh=!h^0Tt-Xv5iHaUMTv zG;P_sLb+2_9RC6}cmNyhm!G@*d{-R{&)J{rdu$bNkVw$7Irtc0P`gJ(*PGzHLfc^b zuXFE&&6)V89>R7Qh#xFXT5Y*gj7s_~XwSoSG3mON$~0ck+ox! zUvo*^`OB%aF#=9b3M)*OGgYR4W*S;1Vh1jP*yS4;L_WYbt1|E^en(e=B@l2_Z@<58 zge?;>WfStbN@JVkxD=@akG;?iXo|RNg|4}v-VBwP=Nm^?>KAN2>3`3IKu7P3G|eSI zQ=2BU%}``=(NRK&-rfNf+~M0`QsTF$iMmf%1O-xOs5aws(xdU8yQi%8?7GB%wIJ7! z_g|_stoRg^6zyNKN}M=4E99}ZTI~aT6Ke2CM5&$bLc`utkMguMRCJW96|KVm2bwQ2 A5&!@I diff --git a/fr/index.html b/fr/index.html index a33d1d0..f84aae1 100644 --- a/fr/index.html +++ b/fr/index.html @@ -1,69 +1,74 @@ --- -layout: reference +layout: fr_reference ---
    -

    Introduction to the Git Reference

    +

    Introduction à Référence Git

    - This is the Git reference site. It is meant to be a quick - reference for learning and remembering the most important and - commonly used Git commands. The commands are organized into - sections of the type of operation you may be trying to do, and - will present the common options and commands needed to accomplish - these common tasks. + Ceci est le site Référence Git. Il a pour but de servir + de référence rapide pour apprendre et retenir les commandes + les plus importantes et les plus utilisées de Git. Les commandes + sont organisées en sections selon le type d'opérations que vous + seriez tenté de faire, et vous présenteront les options et commandes + habituelles pour réaliser ces tâches usuelles.

    - Each section will link to the next section, so it can be used - as a tutorial. Every page will also link to more in-depth - Git documentation such as the official manual pages and relevant - sections in the Pro Git book, - so you can learn more about any of - the commands. First, we'll start with thinking about source code - management like Git does. + Chaque section pointe vers la section suivante, vous pourrez suivre + à la manière d'un tutoriel. Chaque page pointera également vers + une documentation Git plus approfondie comme les pages de manuel + officielles ou aux sections appropriées du + Livre Pro Git, + de cette manière vous pourrez en apprendre plus sur les commandes. + Nous commencerons par découvrir comment penser gestion de code source + à la manière de Git.

    -

    How to Think Like Git

    +

    Comment penser à la Git

    - The first important thing to understand about Git is - that it thinks about version control very differently than - Subversion or Perforce or whatever SCM you may be used to. It - is often easier to learn Git by trying to forget your assumptions - about how version control works and try to think about it in the - Git way. + La première chose à comprendre sur Git est qu'il + gère les révisions d'une manière totalement différente + de Subversion ou Perforce ou tout autre gestionnaire de code source + auquel vous pourriez être habitué. Il est souvent plus simple + d'apprendre Git en essayant d'oublier toute assertion sur + le fonctionnement de la gestion de révisions et d'essayer d'y penser + à la Git.

    - Let's start from scratch. Assume you are designing a new source - code management system. How did you do basic version control before - you used a tool for it? Chances are that you simply copied your - project directory to save what it looked like at that point. + Partons de zéro. Imaginons que vous conceviez un nouveau système de gestion + de code source. Comment géreriez-vous simplement des révisions avant d'utiliser + un outil dédié? Il y a de fortes chances pour que vous ayez fait de simples + copies du répertoire de votre projet pour sauvegarder son état à ce moment-là. 

     $ cp -R project project.bak

    - That way, you can easily revert files that get messed up later, or - see what you have changed by comparing what the project looks like - now to what it looked like when you copied it. + De cette manière, vous pouvez facilement rétablir des fichiers qui + deviendraient inutilisables plus tard, ou pour voir ce que vous avez changé en + comparant ce à quoi le projet ressemble maintenant avec ce à quoi il + ressemblait lorsque vous l'avez copié.

    - If you are really paranoid, you may do this often, maybe putting the - date in the name of the backup: + Si vous êtes réellement paranoïaque, vous le ferez peut-être souvent, + et vous inclurez la date dans le nom de la sauvegarde: 

     $ cp -R project project.2010-06-01.bak

    - In that case, you may have a bunch of snapshots of your project that - you can compare and inspect from. You can even use this model to - fairly effectively share changes with someone. If you zip up your - project at a known state and put it on your website, other developers - can download that, change it and send you a patch pretty easily. + Dans ce cas, vous aurez un tas d'instantanés de votre projet à + disposition comme source de comparaison et d'inspection. Vous pouvez + également utiliser cette méthode pour partager de manière plutôt + efficace des modifications avec un tiers. Si vous compressez votre + projet à un certain état et le mettez sur votre site web, d'autres développeurs + peuvent le télécharger, le modifier et vous envoyer un correctif + assez facilement. 

    @@ -76,37 +81,39 @@ 
    How to Think Like Git
    
  $ (email change.patch)

    - Now the original developer can apply that patch to their copy of the - project and they have your changes. This is how many open source - projects have been collaborated on for several years. + Le développeur original peut alors appliquer le correctif à sa copie + du projet et avoir vos modifications. C'est de cette manière + que de nombreux projets libres ont collaboré pendant plusieurs + années.

    - This actually works fairly well, so let's say we want to write a tool - to make this basic process faster and easier. Instead of writing a tool - that versions each file individually, like Subversion, we would probably - write one that makes it easier to store snapshots of our project without - having to copy the whole directory each time. + Ceci fonctionne en fait plutôt bien, alors disons que nous désirons + écrire un outil pour effectuer ce processus basique plus rapidement + et plus facilement. Au lieu d'écrire un outil qui crée des révisions + de chaque fichier individuellement, comme Subversion, nous en écririons + probablement un qui permettrait de manière plus simple de conserver + des instantanés de notre projet sans avoir à copier la totalité du + dossier à chaque fois.

    - This is essentially what Git is. You tell Git you want to save a snapshot - of your project with the git commit command and it basically - records a manifest of what all of the files in your project look like at - that point. Then most of the commands work with those manifests to see - how they differ or pull content out of them, etc. + C'est fondamentalement ce que fait Git. Vous dites à Git de sauvegarder + un instantané de votre projet avec la commande git commit + et il va simplement enregistrer l'état de tous vos fichiers de votre projet + à ce moment. Ensuite la plupart des commandes travaille avec ces enregistrements + d'état pour voir comment ils différent ou y récupérer du contenu, etc.

    -
    +

    - If you think about Git - as a tool for storing and comparing and merging snapshots of your project, - it may be easier to understand what is going on and how to do things - properly. + Si vous pensez à Git comme un outil pour conserver et comparer et fusionner des instantanés + de votre projet, il sera plus facile de comprendre ce qui se passe et comment + faire différents choses correctement.

    -

    On to Getting and Creating Projects »

    +

    Aller à Récupérer et Créer des Projets »

    From 8d6fde9a48098fa6678f530027032c710d80988b Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Fri, 8 Jan 2016 23:07:12 +0100 Subject: [PATCH 05/22] FR: add README --- fr/README.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 fr/README.md diff --git a/fr/README.md b/fr/README.md new file mode 100644 index 0000000..eff1680 --- /dev/null +++ b/fr/README.md @@ -0,0 +1,18 @@ +# Référence Git, Effort de traduction française # + +Ce dépot concerne l'effort de traduction en français du site en ligne +Référence Git. + +## Contribuer + +Si vous désirez contribuer, faites simplement un fork du dépôt, +poussez vos modifications dans une branche et envoyez une requête de tirage. + +Corrections typographiques, améliorations grammaticales et de lisibilité, toute +participation est la bienvenue. + +## Références pour la traduction + +Les traductions choisies pour les termes spécifiques à Git se basent sur +[les références](https://github.com/progit/progit2-fr#références-pour-la-traduction) +de l'effort de traduction en français de la deuxième édition du livre Progit. From 92b67fd77d224882632a4b12e41a95124cf6f820 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Sat, 9 Jan 2016 12:19:29 +0100 Subject: [PATCH 06/22] FR: Getting and Creating Projects --- fr/creating/index.html | 107 +++++++++++++++++++++-------------------- 1 file changed, 55 insertions(+), 52 deletions(-) diff --git a/fr/creating/index.html b/fr/creating/index.html index 449859a..a981780 100644 --- a/fr/creating/index.html +++ b/fr/creating/index.html @@ -1,21 +1,23 @@ --- -layout: reference +layout: fr_reference ---
    -

    Getting and Creating Projects

    +

    Récupérer et Créer des Projets

    - In order to do anything in Git, you have to have a Git repository. This - is where Git stores the data for the snapshots you are saving. + Pour pouvoir faire quoi que ce soit avec Git, vous devez + avoir un dépôt Git. C'est là que Git stocke les données des + instantanés que vous créez.

    - There are two main ways to get a Git repository. One way is to simply - initialize a new one from an existing directory, such as a new project or - a project new to source control. The second way is to clone one from a - public Git repository, as you would do if you wanted a copy or wanted to - work with someone on a project. We will cover both of these here. + Il y a deux moyens d'avoir un dépôt Git. Le premier est de simplement + en initialiser un depuis un dossier existant, comme un nouveau projet + ou un projet débutant sa gestion de révisions. Le second est de cloner + un dépôt public Git, comme vous le feriez si vous vouliez une copie + ou si vous vouliez collaborer avec quelqu'un sur un projet. Nous allons + aborder chacun de ces cas.

    @@ -25,16 +27,17 @@

    Getting and Creating Projects

    docs   - book + book git init - initializes a directory as a Git repository + initialiser un répertoire comme dépôt Git

    -

    To create a repository from an existing directory of files, you can - simply run git init in that directory. For example, - let's say we have a directory with a few files in it, like this: +

    Pour créer un dépôt à partir d'un répertoire de fichiers existant, + vous pouvez simplement faire git init dans ce répertoire. + Par exemple, disons que nous avons un répertoire comprenant quelques fichiers, + ressemblant à: 

    @@ -43,20 +46,20 @@ 
    
 README   hello.rb
    -

    This is a project where we are writing examples of the "Hello World" - program in every language. So far, we just have Ruby, but hey, it's - a start. To start version controlling this with Git, we can simply - run git init. +

    C'est un projet dans lequel nous écrivons des exemples de programmes + "Hello World" dans chaque langage. Pour l'instant, nous avons simplement Ruby, + mais ce n'est qu'un début. Pour commencer à en gérer les versions avec Git, + nous pouvons simplement lancer git init. 

     $ git init
-Initialized empty Git repository in /opt/konnichiwa/.git/
+Dépôt Git vide initialisé dans /opt/konnichiwa/.git/
    -

    Now you can see that there is a .git subdirectory in your - project. This is your Git repository where all the data of your - project snapshots are stored. +

    Maintenant vous pouvez voir qu'il y a un sous-dossier .git dans + votre projet. Ceci est votre dossier Git dans lequel toutes les données des + instantanés de votre projet sont conservées. 

    @@ -64,14 +67,14 @@ 
    
 .        ..       .git     README   hello.rb
    -

    Congratulations, you now have a skeleton Git repository and can start - snapshotting your project. +

    Félicitations, vous avez maintenant une squelette de dépôt Git et vous pouvez + maintenant commencer à prendre des instantanés de votre projet.

    - In a nutshell, you use git init to make an - existing directory of content into a new Git repository. You can do this - in any directory at any time, completely locally.

    + Pour résumer, vous utilisez git init pour initialiser + le contenu d'un dossier existant en un nouveau dépôt Git. Vous pouvez le faire + dans n'importe quel dossier à tout moment, localement.

    @@ -80,38 +83,38 @@

    docs   - book + book git clone - copy a git repository so you can add to it + copier un dépôt git pour pouvoir le modifier

    - If you need to collaborate with someone on a project, or if you want to - get a copy of a project so you can look at or use the code, you will - clone it. You simply run the git clone [url] command with - the URL of the project you want to copy. + Si vous avez besoin de collaborer avec quelqu'un sur un projet, ou si + vous voulez obtenir une copie d'un projet pour lire ou utiliser son code, + vous le clonerez. Vous lancez simplement la commande git clone [url] + avec l'URL du projet que vous voulez copier. 

     $ git clone git://github.com/schacon/simplegit.git
-Initialized empty Git repository in /private/tmp/simplegit/.git/
-remote: Counting objects: 100, done.
-remote: Compressing objects: 100% (86/86), done.
-remote: Total 100 (delta 35), reused 0 (delta 0)
-Receiving objects: 100% (100/100), 9.51 KiB, done.
-Resolving deltas: 100% (35/35), done.
+Clonage dans 'simplegit'...
+remote: Counting objects: 13, done.
+remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
+Réception d'objets: 100% (13/13), 1.63 KiB | 0 bytes/s, fait.
+Résolution des deltas: 100% (2/2), fait.
+Vérification de la connectivité... fait.
 $ cd simplegit/
 $ ls
 README   Rakefile lib

    - This will copy the entire history of that project so you have it locally - and it will give you a working directory of the main branch of that project - so you can look at the code or start editing it. If you change into the - new directory, you can see the .git subdirectory - that is - where all the project data is. + Cela va copier l'historique complet de ce projet pour que vous l'ayez + à disposition localement et vous aurez un dossier de travail de la branche + principale de ce projet pour vous permettre de lire le code et commencer à + le modifier. Si vous rentrez dans ce nouveau dossier, vous pouvez voir + le sous-dossier .git où toutes les données du projet se trouvent. 

    @@ -125,18 +128,18 @@

    - By default, Git will create a directory that is the same name as the - project in the URL you give it - basically whatever is after the last slash - of the URL. If you want something different, you can just put it at the - end of the command, after the URL. + Par défaut, Git crée un dossier avec le même nom que le projet de l'URL + donnée - typiquement tout ce qui se trouve après le dernier slash de l'URL. + Si vous voulez quelque chose de différent, vous pouvez l'indiquer à la fin + de la commande, après l'URL.

    - In a nutshell, you use git clone to get a - local copy of a Git repository so you can look at it or start modifying - it.

    + Pour résumer, vous utilisez git clone pour + obtenir une copie locale d'un dépôt Git pour pouvoir l'étudier ou le modifier. +

-

On to Basic Snapshotting »

+

Aller à Instantanés de Base »

From 9ba7754cb5aef4fecf77b0edb586ad789f80568a Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Mon, 11 Jan 2016 16:31:33 +0100 Subject: [PATCH 07/22] FR: Inspection and Comparison --- fr/inspect/index.html | 351 ++++++++++++++++++++++-------------------- 1 file changed, 182 insertions(+), 169 deletions(-) diff --git a/fr/inspect/index.html b/fr/inspect/index.html index 32945eb..3647a0b 100644 --- a/fr/inspect/index.html +++ b/fr/inspect/index.html @@ -1,28 +1,30 @@ --- -layout: reference +layout: fr_reference ---

- book + livre - Inspection and Comparison + Inspection et Comparaison

- So now you have a bunch of branches that you are using for short lived - topics, long lived features and what not. How do you keep track of them? - Git has a couple of tools to help you figure out where work was done, what - the difference between two branches are and more. + Vous avez désormais plusieurs branches dont vous vous servez pour des + besoins éphémères, des fonctionnalités durables et autres. Comment + vous y retrouver parmi celles-ci? Git a différents outils pour vous + aider à savoir où un travail donné a eu lieu, quelles sont les différences + entre deux branches et bien d'autres choses.

- In a nutshell you can use git log to find specific - commits in your project history - by author, date, content or - history. You can use git diff to compare two different points - in your history - generally to see how two branches differ or what has - changed from one version of your software to another. + Pour résumer, vous utilisez git log pour retrouver des + validations spécifiques dans l'historique de votre projet - par auteur, date, + contenu et historique. Vous pouvez utiliser git diff pour comparer + deux points différents dans votre historique - habituellement pour voir de quelle + manière deux branches diffèrent ou ce qui a changé entre une version de votre + logiciel et une autre.

@@ -31,35 +33,36 @@

docs   - book + livre git log - filter your commit history + limiter la longueur de l'historique

-

We've already seen how to use git log to compare branches, - by looking at the commits on one branch that are not reachable from another. - (If you don't remember, it looks like this: git log branchA ^branchB). - However, you can also use git log to look for specific commits. - Here we'll be looking at some of the more commonly used git log - options, but there are many. Take a look at the official docs for the whole - list. +

Nous avons déjà vu comment utiliser git log pour comparer + des branches, en visualisant les validations d'une branche. (Si vous ne vous + en souvenez pas, cela ressemble à: git log brancheA ^brancheB). + Cependant, vous pouvez utiliser git log pour rechercher une + validation spécifique. Ici nous allons nous intéresser à certaines options + communément utilisées par git log, mais il en existe de très + nombreuses. Reportez-vous à la documentation officielle pour la liste complète.

git log --author - look for only commits from a specific author + rechercher uniquement les validations d'un auteur en particulier

- To filter your commit history to only the ones done by a specific author, - you can use the --author option. For example, let's say we're - looking for the commits in the Git source code done by Linus. We would - type something like git log --author=Linus. The search is - case sensitive and will also search the email address. The following - example will use the -[number] option, which will limit the - results to the last [number] commits. + Pour filtrer votre historique des validations suivant seulement celles effectuées + par un auteur en particulier, vous pouvez utiliser l'option --author. + Par exemple, disons que nous recherchons les validations du code source de Git + qui ont été effectuées par Linus. Nous exécuterions quelque chose comme + git log --author=Linus. La recherche est sensible à la casse + et recherchera aussi l'adresse email. L'exemple suivant utilise l'option + -[nombre], qui limite les résultats aux [nombre] dernières + validations. 

@@ -73,16 +76,17 @@ 

 
     

       git log --since --before
-      filter commits by date committed
+      filtrer les validations suivant la date de validation
     

 
     

-    If you want to specify a date range that you're interested in filtering your
-    commits down to, you can use a number of options such as --since
-    and --before, or you can also use --until and
-    --after.  For example, to see all the commits in
-    the Git project before three weeks ago but after April 18th, you could run this
-    (We're also going to use --no-merges to remove merge commits):
+      Si vous voulez spécifier un intervalle de temps pour filtrer vos validations,
+      vous pouvez utiliser plusieurs options comme  --since
+      et --before, ou vou spouvez aussi utiliser --until
+      et --after. Par exemple, pour voir toutes les validations du projet
+      Git d'il y a trois semaines mais après le 18 Avril, vous pourriez exécuter ceci
+      (Nous allons aussi utiliser --no-merges pour ignorer les validations
+      de fusion):
     

 
 
@@ -100,15 +104,15 @@ 

 
     

       git log --grep
-      filter commits by commit message
+      filtrer les validations suivant les messages de validation
     

 
     

-      You may also want to look for commits with a certain phrase in the commit
-      message.  Use --grep for that.  Let's say there
-      was a commit that dealt with using the P4EDITOR environment variable and
-      you wanted to remember what that change looked like - you could find the commit
-      with --grep.
+      Vous désireriez peut-être également rechercher les validations avec une certaine
+      phrase dans le message de validation. Utilisez --grep pour cela.
+      Disons qu'il y a une validation qui portait sur la variable d'environnement P4EDITOR
+      et que vous vouliez vous remémorer à quoi ressemblaient les modificiations - vous
+      pourriez retrouver cette validation avec --grep.
     

 
 
@@ -128,16 +132,16 @@ 

 

 
     

-    Git will logically OR all --grep and --author
-    arguments.  If you want to use --grep and --author
-    to see commits that were authored by someone AND have a specific message
-    content, you have to add the --all-match option. In these
-    examples we're going to use the --format option, so we can see
-    who the author of each commit was.
+      Git va faire un OU logique de tous les arguments --grep et
+      --author. Si vous voulez utiliser --grep et
+      --author pour voir toutes les validations qui ont été créées
+      par quelqu'un et ont un contenu de message spécifique, vous devez utiliser
+      l'option --all-match. Dans les exemples nous allons utiliser
+      l'option --format, afin de voir qui est l'auteur de chaque validation.
     

 
-    
If we look for the commit messages with 'p4 depo' in them, we get these
-    three commits:

+    
Si nous recherchons les validations dont le message contient 'p4 depo',
+      nous obtenons ces trois validations:

 
 
 $ git log --grep="p4 depo" --format="%h %an %s"
@@ -146,9 +150,9 @@ 

 1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
 

 
-    
If we add a --author=Hausmann argument, instead of further
-    filtering it down to the one commit by Simon, it instead will show all
-    commits by Simon OR commits with "p4 depo" in the message:

+      
Si nous ajoutons l'argument --author=Hausmann,
+        au lieu de filtrer les validations de Simon, il va plutôt nous montrer
+        toutes les validations par Simon ou dont le message contient "p4 depo".

 
 
 $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
@@ -167,28 +171,29 @@ 

 ...
 

 
-    
However, adding --all-match will get the results you're
-    looking for:

+        
Néanmoins, ajouter --all-match va vous retourner les résultats
+          que vous attendez:

 
 
 $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match
 1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
 

 
-    

-      git log -S
-      filter by introduced diff
-    

-
-    

-      What if you write really horrible commit messages?  Or, what if you are
-      looking for when a function was introduced, or where variables started
-      to be used?  You can also tell Git to look through the diff of each
-      commit for a string.  For example, if we wanted to find which commits
-      modified anything that looked like the function name
-      'userformat_find_requirements', we would run this: (note there is no '='
-      between the '-S' and what you are searching for)
-    

+          

+            git log -S
+            filtrer suivant les changements introduits
+          

+
+          

+            Que faire si vos messages de validations sont vraiment mauvais? Ou si
+            vous recherchez quand une fonction a été rajoutée, ou quand des
+            variables ont commencé à être utilisées? Vous pouvez aussi dire à Git
+            de rechercher parmi les modifications de chaque validation pour une certaine
+            chaîne de caractères. Par exemple, si nous voulions trouver quelles
+            validations ont modifié tout ce qui ressemble au nom de function
+            'userformat_find_requirements', nous exécuterions ceci (notez qu'il
+            n'y a pas de '=' entre le '-S' et ce que vous recherchez):
+          

 
 
 $ git log -Suserformat_find_requirements
@@ -210,21 +215,22 @@ 

     Signed-off-by: Junio C Hamano
 

 
-    

-      git log -p
-      show patch introduced at each commit
-    

-
-    

-    Each commit is a snapshot of the project, but since each commit records the
-    snapshot it was based off of, Git can always calculate the difference and
-    show it to you as a patch.  That means for any commit you can get the patch
-    that commit introduced to the project.  You can either do this by running
-    git show [SHA] with a specific commit SHA, or you can run
-    git log -p, which tells Git to put the patch after each commit.
-    It is a great way to summarize what has happened on a branch or between
-    commits.
-    

+          

+            git log -p
+            afficher le correctif introduit par chaque validation
+          

+
+          

+            Chaque validation est un instantané de votre projet, mais étant donné que
+            chaque validation sait sur quel instantané elle est basée, Git peut toujours
+            calculer la différence et vous l'afficher sous forme de correctif. Cela
+            signifie que pour chaque validation vous pouvez obtenir le correctif que
+            cette validation a introduit dans le projet. Vous pouvez le faire soit
+            en exécutant git show [SHA] avec un SHA spécifique de validation,
+            ou vous pouvez utiliser git log -p, qui dit à Git de mettre le
+            correctif après chaque validation. C'est un très bon moyen de résumer ce
+            qui est arrivé sur une branche ou entre validations.
+          

 
 
 $ git log -p --no-merges -2
@@ -267,17 +273,17 @@ 

  This project has examples of hello world in
 

 
-    
This is a really nice way of summarizing changes or reviewing a series
-    of commits before merging them or releasing something.

+          
C'est un très bon moyen de résumer les changements ou passer en revue
+            une série de validations avant de les fusionner ou de publier quoi que ce soit.

 
-    

-      git log --stat
-      show diffstat of changes introduced at each commit
-    

+          

+            git log --stat
+            afficher un résumé des modifications introduites par chaque validation
+          

 
-    
If the -p option is too verbose for you, you can summarize
-    the changes with --stat instead. Here is the same log output
-    with --stat instead of -p

+          
Si vous trouvez l'option -p trop verbeuse, vous pouvez résumer
+            les changements avec --stat à la place. Voici la même sortie du
+            journal avec --stat à la place de -p.

 
 
 $ git log --stat --no-merges -2
@@ -300,35 +306,37 @@ 

  1 files changed, 1 insertions(+), 1 deletions(-)
 

 
-    
Same basic information, but a little more compact - it still lets you
-    see relative changes and which files were modified.

-
-
-
- -
-

- - docs   - book - - git diff - -

- -
- -

Finally, to see the absolute changes between any two commit snapshots, - you can use the git diff command. This is largely used in two - main situations - seeing how two branches differ from one another and - seeing what has changed since a release or some other older point in - history. Let's look at both of these situations.

- -

To see what has changed since the last release, you can simply run - git diff [version] (or whatever you tagged the release). - For example, if we want to see what has changed in our project since - the v0.9 release, we can run git diff v0.9. -

+

Basiquement les mêmes informations, mais plus succintement - vous pouvez + toujours les diférences et quelles fichiers ont été modifiés.

+ +
+
+ +
+

+ + docs   + livre + + git diff + +

+ +
+ +

Enfin, pour voir les changements absolus entre deux instantanés de validations, + vous pouvez utiliser la commande git diff. Ceci est très utilisé + principalement dans deux cas - voir en quoi deux branches diffèrent + l'une de l'autre et voir ce qui a changé depuis la publication d'une version + ou tout autre ancien moment donné passé dans l'historique. + Voyons chacune de ces situations.

+ +

Pour voir ce qui a changé depuis la dernière publication, vous pouvez + simplement exécuter git diff [version] (ou tout autre étiquette + attribuée à la publication). Par exemple, si vous voulez voir ce qui a changé + dans votre projet depuis la version v0.9, nous pouvons exécuter + git diff v0.9. + 

 $ git diff v0.9
@@ -358,8 +366,8 @@ 

 +HelloWorld.hello
-

Just like git log, you can use the --stat - option with it.

+

Tout comme git log, vous pouvez utiliser l'option + --stat avec.

 $ git diff v0.9 --stat
@@ -368,16 +376,18 @@ 

  2 files changed, 3 insertions(+), 3 deletions(-)
-

To compare two divergent branches, however, you can run something like - git diff branchA branchB but the problem is that it will do - exactly what you are asking - it will basically give you a patch file that - would turn the snapshot at the tip of branchA into the snapshot at the tip - of branchB. This means if the two branches have diverged - gone in different - directions - it will remove all the work that was introduced into branchA - and then add everything that was introduced into branchB. This is probably - not what you want - you want the changes added to branchB that are not in - branchA, so you really want the difference between where the two branches - diverged and the tip of branchB. So, if our history looks like this:

+

Pour comparer deux branches divergentes, néanmoins, vous pouvez exécucter + quelque chose de similaire à git diff branchA branchB mais + le problème est que cela va faire exactement ce que vous lui demandez + - cela va concrétement vous fournir le correctif qui transformerai l'instantané + à l'extrémité de la branche brancheA en l'instantané de l'extrémité de la + branche brancheB. Cela signifie que si deux branches ont divergé - elles + ont pris des directions différentes - cela va occulter toutes les modifications + introduites dans brancheA puis ajouter tout ce qui a été introduit dans brancheB. + Ce n'est probablement pas ce que vous voulez - vous voulez les changements ajoutés + à brancheB qui ne sont pas dans brancheA, vous voulez donc vraiment les différences + entre là où les deux branches ont divergé et l'extrémité de brancheB. Donc, + si notre historique ressemble à ça:

 $ git log --graph --oneline --decorate --all
@@ -389,9 +399,9 @@ 

 ...
-

And we want to see what is on the "erlang" branch compared to the "master" - branch, running git diff master erlang will give us the wrong - thing.

+

Et si nous voulions voir ce qui se trouve sur la branche "erlang" + par rapport à la branche "master", exécuter git diff master erlang + ne nous afficherait pas la bonne chose.

 $ git diff --stat master erlang
@@ -401,12 +411,13 @@ 

  3 files changed, 11 insertions(+), 2 deletions(-)
-

You see that it adds the erlang and haskell files, which is what we did - in that branch, but then the output also reverts the changes to the ruby file - that we did in the master branch. What we really want to see is just the - changes that happened in the "erlang" branch (adding the two files). We can - get the desired result by doing the diff from the common commit they diverged - from:

+

Vous voyez que cela a ajouté les fichiers erlang et haskell, qui est ce + que nous avons fait dans cette branche, mais la sortie revient aussi sur les + changements du fichier ruby que nous avons effetués dans la branche master. + Ce que nous voulons vraiment voir sont juste les changements qui ont été faits + dans la branche "erlang" (l'ajout des deux fichiers). Nous pouvons obtenir le + résultat attendu en faisant la différence entre la validation commune de laquelle + elles ont divergé:

 $ git diff --stat 8d585ea erlang
@@ -415,12 +426,13 @@ 

  2 files changed, 9 insertions(+), 0 deletions(-)
-

That's what we're looking for, but we don't want to have to figure out - what commit the two branches diverged from every time. Luckily, Git has a - shortcut for this. If you run git diff master...erlang (with - three dots in between the branch names), Git will automatically figure out - what the common commit (otherwise known as the "merge base") of the two - commit is and do the diff off of that.

+

C'est ce que nous recherchons, mais nous ne désirons pas à avoir à nous + souvenir de quelle validation les deux branches ont divergé à chaque fois. + Heureusement, Git a un raccourci pour ça. Si vous exécutez + git diff master...erlang (avec trois points entre les noms de + branches), Git va automatiquement savoir quelle est la validation commune + (aussi connue sous le nom de "base de fusion") entre les deux validations et + afficher les modifications en se basant sur celle-ci.

 $ git diff --stat master erlang
@@ -434,21 +446,22 @@ 

  2 files changed, 9 insertions(+), 0 deletions(-)
-

Nearly every time you want to compare two branches, you'll want to use - the triple-dot syntax, because it will almost always give you what you want. -

+

Quasiment à chaque fois que vous voudrez comparer deux branches, vous voudrez + utiliser la syntaxe du triple-point, parce-qu'elle vous donnera sûrement toujours + ce que vous désirez. +

-

As a bit of an aside, you can also have Git manually calculate what the - merge-base (first common ancestor commit) of any two commits would be with - the git merge-base command:

+

En guise de bonus, vous pouvez aussi faire calculer manuellement par Git quelle + serait la base de fusion (la première validation ancêtre commune) entre deux validations + avec la commande git merge-base:

 $ git merge-base master erlang
 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
-

You can do the equivalent of git diff master...erlang - by running this:

+

Vous pouvez faire l'équivalent de git diff master...erlang + en exécutant:

 $ git diff --stat $(git merge-base master erlang) erlang
@@ -457,19 +470,19 @@ 

  2 files changed, 9 insertions(+), 0 deletions(-)
-

You may prefer using the easier syntax though.

+

Vous préférerez peut-être utiliser la forme simple de la syntaxe néanmoins.

-

- In a nutshell you can use git diff to see how a project - has changed since a known point in the past or to see what unique work is - in one branch since it diverged from another. Always use - git diff branchA...branchB to inspect branchB relative to - branchA to make things easier. -

+

+ Pour résumer vous pouvez utiliser git diff pour voir + comment un projet a changé depuis un moment donné ou pour voir quel travail + est contenu dans une branche depuis qu'elle a divergé d'une autre. Utilisez + toujours git diff brancheA...brancheB pour inspecter brancheB + par rapport à brancheA pour vous simplifier la vie. +

-
-
+
+ -

And that's it! For more information, try reading the -Pro Git book.

+

Et c'est la fin! Pour plus d'informations, essayez de lire le + Livre Pro Git.

From a827d649fcbfea41cbfbb9ee9818b9d3ac89050c Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 14 Jan 2016 21:56:01 +0100 Subject: [PATCH 08/22] FR: About --- fr/about.html | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fr/about.html b/fr/about.html index 02b0199..5f29750 100644 --- a/fr/about.html +++ b/fr/about.html @@ -1,9 +1,8 @@ --- -layout: reference +layout: fr_reference ---
-

Who Did This?

-
-

The Git Reference site was put together by the GitHub - team.

+

Qui est à l'origine de ce site?

+
+

Le site Référence Git a été réalisé par l'équipe Github.

From e7cab3679485e3cd23cefb5413331d8242017cb7 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 14 Jan 2016 21:56:20 +0100 Subject: [PATCH 09/22] FR: Cookbook --- fr/cookbook.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fr/cookbook.html b/fr/cookbook.html index 7818f55..1e3c289 100644 --- a/fr/cookbook.html +++ b/fr/cookbook.html @@ -1,12 +1,12 @@ --- -layout: reference +layout: fr_reference ---

Git Cookbook

    -
  • Revert a file
    • -
  • Recover a lost branch
    • -
  • Contribute to a project on GitHub
    • -
  • Undo a merge
    • +
  • Rétablir un fichier
    • +
  • Récupérer une branche perdue
    • +
  • Contribuer à un projet sur GitHub
    • +
  • Annuler une fusion
From 0b366e4e58c84b1f96e5d4fccaa676e501c78dbe Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 14 Jan 2016 21:59:38 +0100 Subject: [PATCH 10/22] FR: Remotes --- fr/remotes/index.html | 517 ++++++++++++++++++++++-------------------- 1 file changed, 268 insertions(+), 249 deletions(-) diff --git a/fr/remotes/index.html b/fr/remotes/index.html index 94df417..8cf72ab 100644 --- a/fr/remotes/index.html +++ b/fr/remotes/index.html @@ -1,41 +1,43 @@ --- -layout: reference +layout: fr_reference ---

- book + livre - Sharing and Updating Projects + Partager et actualiser des projets

- Git doesn't have a central server like Subversion. All of the commands - so far have been done locally, just updating a local database. - To collaborate with other developers in Git, you have to put all that - data on a server that the other developers have access to. The way Git - does this is to synchronize your data with another repository. There - is no real difference between a server and a client - a Git repository - is a Git repository and you can synchronize between any two easily. + Git n'a pas de serveur central comme Subversion. Toutes les commandes + jusqu'à présent ont été exécutées localement, actualisant seulement la base + de données locale. Pour collaborer avec d'autres développeurs sous Git, + vous devez mettre toutes ces données sur un serveur auquel les autres + ont accès. Git rend cela possible en synchronisant vos données avec un + autre dépôt. Il n'y a pas de réelle différence entre un serveur et un client + - un dépôt Git est un dépôt Git et vous pouvez les synchroniser indifféremment + entre eux facilement.

-

Once you have a Git repository, either one that you set up on your - own server, or one hosted someplace like GitHub, you can tell Git to - either push any data that you have that is not in the remote repository - up, or you can ask Git to fetch differences down from the other repo. +

Dès que vous avez un dépôt Git, que ce soit un que vous hébergez sur votre + propre serveur, ou un dépôt hébergé chez un tiers comme GitHub, vous pouvez + dire à Git soit de pousser toutes données que vous avez qui ne sont pas + présentes sur le serveur distant, soit demander à Git de récupérer en local + les différences depuis l'autre dépôt.

-

You can do this any time you are online, it does not have to correspond - with a commit or anything else. Generally you will do a - number of commits locally, then fetch data from the online shared repository - you cloned the project from to get up to date, merge any new work into the - stuff you did, then push your changes back up.

+

Vous pouvez le faire quand vous êtes en ligne, cela n'a pas à être fait + en même temps qu'un commit ou tout autre commande. Généralement + vous ferez un certains nombres de validations localement, puis vous récupérerez + les données depuis le dépôt partagé distant à partir duquel vous avez cloné + le projet pour être à jour, puis vous pousserez vos modifications en ligne.

- In a nutshell you can update your project with git fetch - and share your changes with git push. You can manage your - remote repositories with git remote. + Pour résumer, vous pouvez actualiser votre projet avec git fetch + et partager vos modifications avec git push. Vous pouvez gérer vos + dépôts distants avec git remote.

@@ -44,37 +46,37 @@

docs   - book + livre git remote - list, add and delete remote repository aliases + lister, ajouter et supprimer les alias de dépôts distants

-

Unlike centralized version control systems that have a client that is - very different from a server, Git repositories are all basically equal and - you simply synchronize between them. This makes it easy to have more than - one remote repository - you can have some that you have read-only access to - and others that you can write to as well.

+

Contrairement aux systèmes de gestion de versions centralisés qui ont un client + qui est très différent du serveur, les dépôts Git sont tout simplement équivalents + et vous les synchronisez simplement entre eux. Cela simplifie la possibilité + d'avoir plus d'un dépôt distant - vous pouvez en avoir certains en lecture seule + ainsi que d'autres accessibles en écriture.

-

So that you don't have to use the full URL of a remote repository every - time you want to synchronize with it, Git stores an alias or nickname for - each remote repository URL you are interested in. You use the - git remote command to manage this list of remote repos that - you care about.

+

Afin de ne pas avoir à donner l'URL complète d'un dépôt distant à chaque + fois que vous désirez vous synchroniser avec, Git stocke un alias ou diminutif + pour chaque URL de dépôt distant qui vous intéresse. Vous utilisez la commande + git remote pour gérer cette liste de dépôts distants qui vous + intéresse.

git remote - list your remote aliases + lister vos alias distants

-

Without any arguments, Git will simply show you the remote repository - aliases that it has stored. By default, if you cloned the project (as - opposed to creating a new one locally), Git will automatically add the - URL of the repository that you cloned from under the name 'origin'. If - you run the command with the -v option, you can see the - actual URL for each alias.

+

Sans argument, Git va simplement vous afficher les alias de dépôt distants + qu'ils stockent. Par défaut, si vous avez cloné le projet (par opposition + à en créer un nouveau localement), Git va automatiquement ajouter l'URL + de ce dépôt source que vous avez cloné sous le nom 'origin'. SI vous exécutez + la commande avec l'option -v, vous pouvez voir + l'URL réelle de chaque alias.

 $ git remote
@@ -84,26 +86,30 @@ 

 origin	git@github.com:github/git-reference.git (push)
-

You see the URL there twice because Git allows you to have different - push and fetch URLs for each remote in case you want to use different - protocols for reads and writes.

- -

- git remote add - add a new remote repository of your project -

- -

If you want to share a locally created repository, or you want to take - contributions from someone else's repository - if you want to interact in - any way with a new repository, it's generally easiest to add it as a remote. - You do that by running git remote add [alias] [url]. That - adds [url] under a local remote named [alias].

- -

For example, if we want to share our Hello World program with the world, - we can create a new repository on a server (Using GitHub as an example), - which should give you a URL, in this case "git@github.com:schacon/hw.git". - To add that to our project so we can push to it and fetch updates from it - we would do this:

+

Vous voyez l'URL ici en double car Git permet d'avoir des URLS + différentes pour pousser et récupérer pour chaque dépôt au cas où + vous vouliez utiliser des protocoles différents en lecture + et en écriture.

+ +

+ git remote add + ajouter un nouveau dépôt distant à votre projet +

+ +

Si vous voulez partager un dépôt créé localement, ou vous voulez + récupérer les contributions depuis le dépôt d'un tiers - si vous voulez + interagir de n'importe quelle manière avec un nouveau dépôt, le plus simple + est généralement de l'ajouter comme dépôt distant. Vous faites cela en + exécutant git remote add [alias] [url]. Cela ajoute + l'[url] en local en tant que dépôt distant sous le nom + [alias].

+ +

Par exemple, si nous voulons partager notre programme Hello World avec + le reste du monde, nous pouvons créer un nouveau dépôt sur un serveur + (utilisons Github comme exemple), vous devriez obtenir une URL, + dans notre cas "git@github.com:schacon/hw.git". Pour l'ajouter à notre + projet afin de pouvoir y pousser et récupérer des mises à jour depuis celui-ci + nous ferions:

 $ git remote
@@ -113,22 +119,22 @@ 

 github	git@github.com:schacon/hw.git (push)
-

Like the branch naming, remote alias names are arbitrary - just as 'master' - has no special meaning but is widely used because git init - sets it up by default, 'origin' is often used as a remote name because - git clone sets it up by default as the cloned-from URL. In - this case we'll name the remote 'github', but you could name it just - about anything. -

+

Tout comme la dénomination des branches, le nommage des alias de dépôts + distants est arbitraire - tout comme 'master' n'a aucune signification spéciale + mais est très largement utilisé car git init le configure par défaut, + 'origin' est souvent utilisé comme nom de dépôt distant car + git clone le configure par défaut comme URL source de clonage. Dans + notre cas nous allons appeler ce dépôt distant 'github', mais vous pourriez le + nommer comme bon vous semblerait. +

-

- git remote rm - removing an existing remote alias -

+

+ git remote rm + enlever un alias existant de dépôt distant +

-

Git addeth and Git taketh away. If you need to remove a remote - you are - not using it anymore, the project is gone, etc - you can remove it with - git remote rm [alias].

+

Si vous avez besoin d'enlever un dépôt distant - vous ne l'utilisez plus, le projet + n'existe plus, etc - vous pouvez l'enlever avec git remote rm [alias].

 $ git remote -v
@@ -146,14 +152,15 @@ 

 github	git@github.com:schacon/hw.git (push)
-

- git remote rename [old-alias] [new-alias] - rename remote aliases -

+

+ git remote rename [ancien-alias] [nouvel-alias] + renommer des alias de dépôt distant +

-

If you want to rename remote aliases without having to delete them and add them again - you can do that by running git remote rename [old-alias] [new-alias]. This will - allow you to modify the current name of the remote.

+

Si vous voulez renommer des alias de dépôt distant sans avoir à les supprimer puis les + ajouter à nouveau vous pouvez le faire en exécutant + git remote rename [ancien-alias] [nouvel-alias]. Cela va vous permettre + de modifier le nom en cours d'utilisation du dépôt distant.

 $ git remote add github git@github.com:schacon/hw.git
@@ -166,21 +173,22 @@ 

 origin	git@github.com:schacon/hw.git (push)
-

- In a nutshell with git remote you can list our - remote repositories and whatever URL - that repository is using. You can use git remote add to - add new remotes, git remote rm to delete existing ones or git remote rename [old-alias] [new-alias] to rename them. -

+

+ Pour résumer, avec git remote vous pouvez lister vos dépôts + distants et toute URL que ce dépôt utilise. Vous pouvez utiliser + git remote add pour ajouter de nouveaux dépôts distants, + git remote rm pour en supprimer ou + git remote rename [ancien-alias] [nouvel-alias] pour les renommer. +

-

- git remote set-url - update an existing remote URL -

+

+ git remote set-url + actualiser une URL distante existante +

-

Should you ever need to update a remote's URL, you can do so with - the git remote set-url command. -

+

Si vous aviez besoin d'actualiser l'URL d'un dépôt distant, vous + pouvez le faire avec la commande git remote set-url. + 

 $ git remote -v
@@ -196,10 +204,11 @@ 

 origin	git://github.com/github/git-reference.git (push)
-

In addition to this, you can set a different push URL when you - include the --push flag. This allows you to fetch from - one repo while pushing to another and yet both use the same remote alias. -

+

De plus, vous pouvez définir une URL différente pour pousser quand + vous ajoutez le drapeau --push. Cela vous permet de récupérer + depuis un dépôt mais de pousser vers un autre tout en leur donnant le + même alias. + 

 $ git remote -v
@@ -215,16 +224,17 @@ 

 origin	git://github.com/pjhyett/hw.git (push)
-

Internally, the git remote set-url command calls - git config remote, but has the added benefit of reporting - back any errors. git config remote on the other hand, will - silently fail if you mistype an argument or option and not actually set - anything. -

+

En interne, la commande git remote set-url exécute + git config remote, mais avec l'avantage de vous signaler + en retour toute erreur. git config remote d'un autre côté, + va échouer en silence si vous avez mal tapé un argument ou une option + pour ne rien définir au final. +

-

For example, we'll update the github remote but - instead reference it as guhflub in both invocations. -

+

Par exemple, nous allons mettre à jour le dépôt distant github + mais à la place y faire référence en tant que guhflub à chaque + invocation. + 

 $ git remote -v
@@ -242,64 +252,67 @@ 

 fatal: No such remote 'guhflub'
-

- In a nutshell, you can update the locations of your remotes - with git remote set-url. You can also set different push - and fetch URLs under the same remote alias. -

- -
- - -
-

- - docs   - book - - git fetch - download new branches and data from a remote repository -

- -
- -

- - docs   - book - - git pull - fetch from a remote repo and try to merge into the current branch -

- -
- -

Git has two commands to update itself from a remote repository. - git fetch will synchronize you with another repo, pulling down any data - that you do not have locally and giving you bookmarks to where each branch on - that remote was when you synchronized. These are called "remote branches" and are - identical to local branches except that Git will not allow you to check them out - - however, you can merge from them, diff them to other branches, run history logs on - them, etc. You do all of that stuff locally after you synchronize. -

- -

The second command that will fetch down new data from a remote server is - git pull. This command will basically run a git fetch - immediately followed by a git merge of the branch on that remote - that is tracked by whatever branch you are currently in. Running the - fetch and merge commands separately involves less magic - and less problems, but if you like the idea of pull, you can - read about it in more detail in the - official docs. -

- -

Assuming you have a remote all set up and you want to pull in updates, you - would first run git fetch [alias] to tell Git to fetch down all the - data it has that you do not, then you would run git merge [alias]/[branch] - to merge into your current branch anything new you see on the server - (like if someone else has pushed in the meantime). So, if you were working on a - Hello World project with several other people and wanted to bring in any changes - that had been pushed since we last connected, we would do something like this:

+

+ Pour résumer, vous pouvez mettre à jour les emplacements de vos + dépôts distants avec git remote set-url. Vous pouvez aussi définir des URLs + différentes pour pousser et récupérer sous le même nom d'alias de dépôt distant. +

+ +
+
+ +
+

+ + docs   + livre + + git fetch + récupérer de nouvelles branches et données depuis un dépôt distant +

+ +
+ +

+ + docs   + livre + + git pull + récupérer depuis un dépôt distant et essaye de fusionner dans la branche courante +

+ +
+ +

Git a deux commandes pour se mettre à jour depuis un dépôt distant. + git fetch va vous synchroniser avec un autre dépôt, récupérant + en local tout donnée non présente en local et vous donnant des marqueurs sur où + chaque branche sur ce dépôt distant en était au momemt de la synchronisation. + Celles-ci sont appelées "branches distantes" et sont identiques aux branches locales + mis à part que Git ne vous autorisera pas de les extraire - par contre, vous pouvez + fusionner avec, les comparer à d'autres branches, exécuter des journaux d'historique + dessus, etc. Vous faites toutes ces opérations en local une fois votre synchronisation + faite. +

+ +

La seconde commande qui va récupérer en local des données et la commande + git pull. Cette commande va concrètement exécuter git fetch + immédiatemment suivi d'un git merge de la branche de ce dépôt distant + qui est suivie par toute branche courante dans laquelle vous êtes. Exécuter les commandes + fetch et merge séparément est source de moins de magie et + et moins de problèmes, mais si vous aimez le principe de pull, + vous pouvez le retrouver de manière plus détaillée dans la + documentation officielle. +

+ +

Partant du principe que vous avez un dépôt distant fonctionnel et que vous voulez tirer + en local des mises à jour, vous exécuteriez en premier git fetch [alias] + pour dire à Git de récupérer en local toutes les données du dépôt que vous n'avez pas, + puis vous exécuteriez git merge [alias]/[branche] pour fusionner dans la + branche courante tout ce qu'il y de nouveau sur le serveur (par exemple si quelqu'un + a poussé entretemps). Au final, si vous travailliez sur un projet Hello World avec + plusieurs autres personnes et que vous vouliez récupérer toutes modifications qui + ont été poussées depuis votre dernière connexion, vous feriez quelque chose comme:

 $ git fetch github
@@ -316,53 +329,56 @@ 

  * [new branch]      lisp       -> github/lisp
-

Here we can see that since we last synchronized with this remote, five branches - have been added or updated. The 'ada' and 'lisp' branches are new, where the - 'master', 'c-langs' and 'java' branches have been updated. In our example case, - other developers are pushing proposed updates to remote branches for review before - they're merged into 'master'. -

- -

You can see the mapping that Git makes. The 'master' branch on the remote - repository becomes a branch named 'github/master' locally. That way you can - merge the 'master' branch on that remote into the local 'master' branch by running - git merge github/master. Or, you can see what new commits are on that - branch by running git log github/master ^master. If your remote - is named 'origin' it would be origin/master instead. Almost any - command you would run using local branches you can use remote branches with too. -

- -

If you have more than one remote repository, you can either fetch from specific - ones by running git fetch [alias] or you can tell Git to synchronize - with all of your remotes by running git fetch --all. -

- -

- In a nutshell you run git fetch [alias] to synchronize your - repository with a remote repository, fetching all the data it has that you do - not into branch references locally for merging and whatnot. -

- -
- -
- -
-

- - docs   - book - - git push - push your new branches and data to a remote repository -

- -
-

To share the cool commits you've done with others, you need to push your - changes to the remote repository. To do this, you run - git push [alias] [branch] which will attempt to make your [branch] - the new [branch] on the [alias] remote. Let's try it by initially pushing - our 'master' branch to the new 'github' remote we created earlier.

+

Dans cet exemple nous pouvons voir que depuis notre dernière synchronisation + avec le dépôt distant, cinq branches ont été créées ou mises à jour. Les + branches 'ada' et 'lisp' sont nouvelles, alors que les branches 'master', 'c-langs' + et 'java' ont été actualisées. Dans notre scénario exemple, les autres développeurs + poussent leurs modifications dans des branches distantes pour revue avant d'être + fusionnées dans 'master'. +

+ +

Vous pouvez observer ce que Git met en place. La branche 'master' sur le dépôt + distant devient une branche appelée 'github/master' en local. De cette manière + vous pouvez fusionner la branche 'master' de ce dépôt distant dans la branche locale + 'master' en exécutant git merge github/master. Ou vous pouvez voir + quelles sont les nouvelles validations en exécutant git log github/master ^master. + Si votre dépôt distant est nommé 'origin' il sera plutôt nommé origin/master. + Quasiment tout commande utilisable sur les branches locales est utilisable également + sur les branches distantes. +

+ +

Si vous avez plus d'un dépôt distant, vous pouvez plutôt récupérer depuis un dépôt + spécifique en exécutant git fetch [alias] ou vous pouvez dire à Git + de se synchroniser avec tous les dépôts distants en exécutant git fetch --all. +

+ +

+ Pour résumer, vous exécutez git fetch [alias] pour synchroniser + votre dépôt avec un dépôt distant, en récupérant toutes les données du dépôt + distant qui ne sont pas référencées dans une branche locale pour les fusionner + ou autre. +

+ +
+ +
+ +
+

+ + docs   + livre + + git push + pousser vos nouvelles branches et données vers un dépôt distant +

+ +
+

Pour partager vos sympathiques validations avec d'autres, vous avez besoin de pousser + vos modifications vers un dépôt distant. Pour cela, vous exécutez + git push [alias] [branche] qui va tenter de faire de votre [branche] + une nouvelle [branche] sur le dépôt distant [alias]. Essayons de le faire en commençant + par pousser notre branche 'master' vers le dépôt distant 'github' créé précédemment.

 $ git push github master
@@ -375,11 +391,12 @@ 

  * [new branch]      master -> master
-

Pretty easy. Now if someone clones that repository they will get exactly - what we have committed and all of its history.

+

Plutôt simple. Désormais si quelqu'un clone ce dépôt il va obtenir exactement + toutes ses validations et tout son historique.

-

What if you have a topic branch like the 'erlang' branch created earlier - and want to share just that? You can just push that branch instead.

+

Comment faire si vous avez une branche spécifique comme la branche 'erlang' + créée précédemment et que vous vouliez just partager celle-ci? Vous pouvez + uniquement pousser cette branche à la place.

 $ git push github erlang
@@ -392,25 +409,27 @@ 

  * [new branch]      erlang -> erlang
-

Now when people clone or fetch from that repository, they'll get an 'erlang' - branch they can look at and merge from. You can push any branch to any - remote repository that you have write access to in this way. If your branch - is already on the server, it will try to update it, if it is not, Git will - add it.

- -

The last major issue you run into with pushing to remote branches is the - case of someone pushing in the meantime. If you and another developer clone - at the same time, you both do commits, then she pushes and then you try to - push, Git will by default not allow you to overwrite her changes. Instead, - it basically runs git log on the branch you're trying to push and - makes sure it can see the current tip of the server's branch in your push's - history. If it can't see what is on the server in your history, it concludes - that you are out of date and will reject your push. You will rightly have to - fetch, merge then push again - which makes sure you take her changes into - account.

- -

This is what happens when you try to push a branch to a remote branch - that has been updated in the meantime:

+

Désormais quand quelqu'un clonera ou récupérera depuis ce dépôt, elle aura + une branche 'erlang' qu'elle pourra étudier et fusionner. Vous pouvez pousser + toute branche de cette manière vers n'importe quel dépôt distant auquel + vous avez accès en écriture. Si votre branche est déjà sur le serveur, + Git tentera de la mettre à jour, si elle n'est pas présente, Git l'ajoutera.

+ +

Le dernier problème courant que vous risquez de rencontrer en poussant vers + des branches distantes est dans le cas où quelqu'un pousse en même temps. + Si vous et une autre développeuse clone au même moment, vous créez chacun + vos validations, puis elle pousse et enfin vous essayez de pousser à votre tour, + Git va par défaut refuser que vous écrasiez ses modifications. Au lieu de ça, + Git va simplement exécuter un git log de la branche sur laquelle + vous essayez de pousser et s'assurer qu'il peut trouver l'extrémité courante + de la branche du serveur dans l'historique de ce que vous poussez. S'il ne + peut voir ce qu'il trouve sur le serveur dans votre historique, il en conclut + que vous n'êtes pas à jour et ne va pas accepter que vous poussiez. Pour bien + faire, vous devriez récupérer, fusionner puis pousser à nouveau - pour être sûr + de prendre ses modifications en compte.

+ +

Voici ce qui arrive lorsque vous essayez de pousser une branche vers une branche + distante qui a été mise à jour en même temps:

 $ git push github master
@@ -422,19 +441,19 @@ 

 fast-forwards' section of 'git push --help' for details.
-

You can fix this by running git fetch github; git merge github/master - and then pushing again. -

+

Vous pouvez corriger cela en exécutant git fetch github; git merge github/master + puis en poussant à nouveau. +

-

- In a nutshell you run git push [alias] [branch] to update a - remote repository with the changes you've made locally. It will take what your - [branch] looks like and push it to be [branch] on the remote, if possible. If - someone else has pushed since you last fetched and merged, the Git server will - deny your push until you are up to date. -

+

+ Pour résumer, vous exécutez git push [alias] [branche] pour actualiser + une branche distante avec vos modifications locales. Cela va prendre le contenu de + votre [branche] et le pousser pour en faire la [branche] sur le dépôt distant, si possible. + Si quelqu'un a poussé depuis la dernière fois que vous avez récupéré et mis à jour, + le serveur Git va refuser que vous poussiez tant que vous n'êtes pas à jour. +

-
-
+ + -

On to Inspection and Comparison »

+

Aller à Inspection et Comparaison »

From f8d6f3118e3c0fe29fcc72659bc5d3a65c8c605d Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Mon, 11 Jan 2016 16:30:28 +0100 Subject: [PATCH 11/22] FR: Basic snapshotting --- fr/basic/index.html | 1092 ++++++++++++++++++++++--------------------- 1 file changed, 557 insertions(+), 535 deletions(-) diff --git a/fr/basic/index.html b/fr/basic/index.html index b381b86..59556aa 100644 --- a/fr/basic/index.html +++ b/fr/basic/index.html @@ -1,35 +1,38 @@ --- -layout: reference +layout: fr_reference ---

- book + livre - Basic Snapshotting + Instantanés de Base

- Git is all about composing and saving snapshots of your project and then - working with and comparing those snapshots. This section will explain - the commands needed to compose and commit snapshots of your project. + L'essentiel de Git tient à créer et sauvegarder des instantanés de votre projet + pour ensuite utiliser et comparer ces instantanés. Cette section va + présenter les commandes nécessaires pour créer et sauvegarder des instantanés + de votre projet.

- An important concept here is that Git has an 'index', which acts as sort - of a staging area for your snapshot. This allows you to build up a series - of well composed snapshots from changed files in your working directory, - rather than having to commit all of the file changes at once. + Un concept important ici est que Git dispose d'un 'index', qui se comporte + comme une sorte de zone d'attente pour votre instantané. Cela vous permet + d'accumuler des séries bien ordonnées d'instantanés à partir de fichiers modifiés + de votre dossier de travail, plutôt que de valider toutes les modifications de + fichiers d'un coup.

- In a nutshell, you will use git add to start tracking new - files and also to stage changes to already tracked files, then - git status and git diff to see what has been - modified and staged and finally git commit to record your - snapshot into your history. This will be the basic workflow that you use - most of the time. + Pour résumer, vous utiliserez git add pour + commencer à suivre de nouveaux fichiers et aussi pour mettre en attente + des modifications apportées à des fichiers déjà suivis, puis + git status et git diff pour voir ce qui a été + modifié et mis en attente et finalement git commit pour + enregistrer un instantané dans votre historique. Ce sera le flux de travail + basique que vous utiliserez la plupart du temps.

@@ -39,26 +42,26 @@

docs   - book + livre git add - adds file contents to the staging area + ajouter le contenu d'un fichier dans la zone d'attente

- In Git, you have to add file contents to your staging area before you - can commit them. If the file is new, you can run git add - to initially add the file to your staging area, but even if the file - is already "tracked" - ie, it was in your last commit - you still need - to call git add to add new modifications to your staging - area. Let's see a few examples of this. + Dans Git, vous devez ajouter le contenu d'un fichier dans la zone d'attente + avant de pouvoir le valider. Si c'est un nouveau fichier, vous pouvez + exécuter git add pour l'ajouter au préalable à la zone d'attente, + mais même si le fichier est déjà "suivi" - ie, il fait partie de votre dernière + validation - vous devez toujours lancer git add pour ajouter de + nouvelles modifications à votre zone d'attente. Voyons quelques exemples.

-

Going back to our Hello World example, once we've initiated the project, - we would now start adding our files to it and we would do that with - git add. We can use git status to see what the - state of our project is. +

Revenons à notre exemple Hello World, une fois initialisé notre projet, + nous commencerions à présent à y ajouter des fichiers et le ferions avec + git add. Nous pouvons utiliser git status pour + afficher l'état de notre projet. 

@@ -67,14 +70,14 @@ 

 ?? hello.rb
- So right now we have two untracked files. We can now add them. + Nous avons désormais deux fichiers non suivis. Nous pouvons maintenant les ajouter. 
 $ git add README hello.rb
- Now if we run git status again, we'll see that they've been - added. + Maintenant si nous exécutons git status à nouveau, nous verrions + qu'ils ont été ajoutés. 
 $ git status -s
@@ -83,18 +86,19 @@

- It is also common to recursively add all files in a new project by specifying - the current working directory like this: git add .. Since Git - will recursively add all files under a directory you give it, if you give it - the current working directory, it will simply start tracking every file - there. In this case, a git add . would have done the same - thing as a git add README hello.rb, or for that matter so would - git add *, but that's only because we don't have subdirectories - which the * would not recurse into. -

- -

OK, so now if we edit one of these files and run git status - again, we will see something odd.

+ Il est aussi courant d'ajouter récursivement tous les fichiers d'un nouveau projet + en indiquant le dossier de travail courant comme suit: git add .. + Sachant que Git va ajouter récursivement tous les fichiers dans un dossier que + vous lui donnez, si vous lui donnez le répertoire de travail courant, il va + simplement faire le suivi de chaque fichier qui s'y trouve. Dans ce cas, + la commande git add . aurait donné la même chose que + git add README hello.rb, et par la même également + git add *, mais c'est seulement parce-que nous n'avons pas + de sous-dossiers, et que * ne pourrait pas les parcourir récursivement. +

+ +

OK, maintenant nous éditons un de ces fichiers et exécutons git status + à nouveau, et nous allons observer un comportement étrange.

 $ vim README
 $ git status -s
@@ -102,50 +106,51 @@ 

 A  hello.rb
-

The 'AM' status means that the file has been modified on disk since we - last added it. This means that if we commit our snapshot right now, we will - be recording the version of the file when we last ran git add, - not the version that is on our disk. Git does not assume that what the file - looks like on disk is necessarily what you want to snapshot - you have to - tell Git with the git add command. -

+

Le statut 'AM' signifie que le fichier a été modifié depuis la dernière + fois qu'il a été ajouté. Cela signifie que si nous validons notre instantané + tout de suite, nous enregistrerions la version du fichier lors de l'exécution + précédente de git add, pas la version actuelle. Git n'assume pas + que le version dans sa version actuelle est nécessairement celle que vous + voulez prendre en instantané - vous devez le préciser à Git avec la commande + git add. +

-

- In a nutshell, - you run git add on a file when you want to - include whatever changes you've made to it in your next commit snapshot. - Anything you've changed that is not added will not be included - this means - you can craft your snapshots with a bit more precision than most other SCM - systems.

+

+ Pour résumer, + vous exécutez git add sur un fichier lorsque vous voulez inclure + toute modification apportée au fichier dnas le prochain instantané à valider. + Toute modification qui ne sera pas ajoutée ne sera pas incluse à l'instantané + - cela signifie que vous pouvez créer vos instantanés de manière plus fine + que la plupart des systèmes de gestion de révisions.

-

For a very interesting example of using this flexibility to stage only - parts of modified files at a time, see the '-p' option to - git add in the Pro Git book.

+

Pour un exemple concret de la flexibilité de mise en attente une à une + de seulement certaines parties de fichiers modifiés, regardez l'option + '-p' de git add du livre Pro Git.

-
+
- - -
-

- - docs   - book - - git status - view the status of your files in the working directory and staging area -

+
-
-

As you saw in the git add section, in order to see what the - status of your staging area is compared to the code in your working - directory, you can run the git status command. Using the - -s option will give you short output. - Without that flag, the git status command will give you more - context and hints. Here is the same status output with and without the - -s. The short output looks like this: -

+
+

+ + docs   + livre + + git status + voir le statut de vos fichiers du dossier courant et de la zone d'attente +

+ +
+

Comme vous l'avez vu dans la section git add, pour voir + le statut de votre zone d'attente comparé au code de votre dossier de travail, + vous pouvez exécuter la commande git status. En utilisant + l'option -s l'affichage de la sortie sera réduit. Sans cette option + la commande git status vous donnera plus de contexte et d'indications. + Voici le même affichage de la sortie du statut avec et sans le -s. + La sortie courte ressemble à ça: + 

 $ git status -s
@@ -153,7 +158,7 @@ 

 A  hello.rb
- Where the same status with the long output looks like this: + Alors que le même statut avec la sortie longue ressemble à ça: 
 $ git status
@@ -175,25 +180,24 @@ 

 #
-

You can easily see how much more compact the short output is, but the - long output has useful tips and hints as to what commands you may want to - use next. -

- -

Git will also tell you about files that were deleted since your last - commit or files that were modified or staged since your last commit.

+

Vous pouvez rapidement vous apercevoir comme l'affichage court de la sortie + est beaucoup plus compact, mais la sortie longue a d'utiles informations et + indications dont vous pourriez avoir besoin. +

+

Git vous dira également quels fichiers ont été effacés + ou les fichiers modifiés ou mis en attente depuis votre dernière validation

 $ git status -s
 M  README
  D hello.rb
- You can see there are two columns in the short status output. The first - column is for the staging area, the second is for the working directory. - So for example, if you have the README file staged and then you modify - it again without running git add a second time, you'll see - this: + Vous pouvez voir qu'il y a deux colonnes dans la sortie courte du statut. + La première colonne est pour la zone d'attente, la seconde est pour le + dossier de travail. Par exemple, si vous avez le fichier README en zone + d'attente et qu'ensuite vous le modifiez sans exécuter git add + une seconde fois, vous verrez ceci: 
 $ git status -s
@@ -201,43 +205,44 @@ 

  D hello.rb
-

- In a nutshell, - you run git status to see if anything has been modified - and/or staged since your last commit so you can decide if you want to - commit a new snapshot and what will be recorded in it. -

- -
-
- -
-

- - docs   - book - - git diff - shows diff of what is staged and what is modified but unstaged -

- -
-

There are two main uses of the git diff command. One use we - will describe here, the other we will describe later in the - "Inspection and Comparison" - section. The way we're going to use it here is to describe the - changes that are staged or modified on disk but unstaged.

- -

- git diff - show diff of unstaged changes -

- -

Without any extra arguments, a simple git diff will display - in unified diff format (a patch) what code or content you've changed in your - project since the last commit that are not yet staged for the next commit - snapshot. -

+

+ Pour résumer, + vous exécutez git status pour voir si quoi que ce soit a été + modifié ou mis en attente depuis votre dernière validation pour que vous + puissiez décider si vous voulez valider un nouvel instantané et avec quel + contenu. +

+ +
+
+ +
+

+ + docs   + livre + + git diff + afficher les modifications indexées et non indexées +

+ +
+

Il y a deux utilisations principales de la commande git diff. + Une utilisation que nous allons décrire ici, l'autre sera décrite plus loin + dans la section "Inspection et Comparaison". + La manière dont nous allons l'utiliser ici est de décrire les changements + qui sont indexés, ou ceux modifiés sur disque mais non indexés.

+ +

+ git diff + Afficher les modifications non indexées +

+ +

Sans aucun argument, un simple git diff vous affichera au + format diff unifié (un correctif) ce que vous avez changé comme code ou contenu + de votre projet depuis la dernière vaildation qui n'est pas encore indexé ou le + prochain instantané à valider. + 

 $ vim hello.rb
@@ -259,24 +264,24 @@ 

  end
-

So where git status will show you what files have changed - and/or been staged since your last commit, git diff will - show you what those changes actually are, line by line. It's generally - a good follow-up command to git status -

- -

- git diff --cached - show diff of staged changes -

- -

The git diff --cached command will show you what contents - have been staged. That is, this will show you the changes that will - currently go into the next commit snapshot. So, if you were to stage - the change to hello.rb in the example above, - git diff by itself won't show you any output because it will - only show you what is not yet staged. -

+

Là où git status vous affichera quels fichiers ont changé + et/ou a été indexé depuis votre dernière validation, git diff + va vous montrer quels sont concrétement ces changements, ligne par ligne. + C'est généralement une bonne commande à la suite d'un git status. +

+ +

+ git diff --cached + montrer les changements indexés +

+ +

La commande git diff --cached montrera le contenu indexé. + C'est-à-dire, cela vous affichera les changements qui seront inclus + dans le prochain instantané validé. Ainsi, si vous deviez indexer + les modifications de hello.rb de l'exemple précédent, + git diff tel quel ne vous affichera rien car il ne devra + vous afficher que ce qui n'a pas encore été indexé. + 

 $ git status -s
@@ -288,8 +293,8 @@ 

 $
-

If you want to see the staged changes, you can run - git diff --cached instead.

+

Si vous voulez voir les changements indexés, vous pouvez exécuter + git diff --cached à la place.

 $ git status -s
@@ -312,18 +317,18 @@ 

  end
-

- git diff HEAD - show diff of all staged or unstaged changes -

- -

If you want to see both staged and unstaged changes together, you - can run git diff HEAD - this basically means you want to - see the difference between your working directory and the last commit, - ignoring the staging area. If we make another change to our - hello.rb file then we'll have some changes staged and some - changes unstaged. Here are what all three diff commands - will show you:

+

+ git diff HEAD + afficher toutes les modifications indexées ou non indexéess +

+ +

Si vous voulez voir aussi bien les modifications indexées que non indexées ensemble, + vous pouvez exécuter git diff HEAD - cela veut simplement + dire que vous voulez voir les différences entre votre répertoire de travail et la + dernière validation, ignorant la zone d'index. Si nous apportons une autre modification + au fichier hello.rb alors nous aurons des modifications indexées et certaines + modifications non indexées. Voici ce que chacune des trois commandes diff + vous affichera:

 $ vim hello.rb 
 $ git diff
@@ -371,16 +376,17 @@ 

  end
-

- git diff --stat - show summary of changes instead of a full diff -

+

+ git diff --stat + afficher un résumé des changements au lieu de toutes les modifications +

-

If we don't want the full diff output, but we want more than the - git status output, we can use the --stat - option, which will give us a summary of changes instead. Here is the - same example as above, but using the --stat option instead. -

+

Si nous ne voulons pas de l'affichage complet des modifications, + mais plus que la sortie de git status, on peut utiliser + l'option --stat, qui nous donnera à la place un résumé des + changements. Voici le même exemple que précédemment, mais en utilisant + l'option --stat à la place. + 

 $ git status -s
@@ -396,51 +402,53 @@ 

  1 files changed, 2 insertions(+), 1 deletions(-)
-

- You can also provide a file path at the end of any of these options - to limit the diff output to a specific file or subdirectory. -

+

+ Vous pouvez aussi donner un chemin de fichier à la fin de n'importe laquelle + de ces options pour réduire la sortie de diff à un fichier ou dossier + spécifique. +

-

- In a nutshell, - you run git diff to see details of the git status - command - how files have been modified or staged on a line by line - basis. -

+

+ Pour résumer, + vous exécutez git diff pour voir les détails de la commande + git status - dans quelle mesure les fichiers ont été modifiés + ou indexés ligne par ligne. +

-
-
+
+ -
-

- - docs   - book - - git commit - records a snapshot of the staging area -

+
+

+ + docs   + livre + + git commit + valider un instantané de la zone d'index +

-
+
-

Now that you have staged the content you want to snapshot with the - git add command, you run git commit to actually - record the snapshot. - Git records your name and email address with every commit you make, - so the first step is to tell Git what these are. -

+

Maintenant que vous avez indexé le contenu dont vous voulez faire un instantané + avec la commande git add, vous exécutez git commit + pour enregistrer l'instantané. + Git enregistre le nom et l'adresse email de chacune de vos validations, + il faut donc commencer par indiquer à Git à quoi ils correspondent. + 

-$ git config --global user.name 'Your Name'
-$ git config --global user.email you@somedomain.com
+$ git config --global user.name 'Votre Nom'
+$ git config --global user.email vous@domaine.fr
-

Let's stage and commit all the changes to our - hello.rb file. In this first example, we'll use the - -m option to provide the commit message on the command line. -

+

Indexons et validons tous les changements de notre fichier + hello.rb. Dans ce premier exemple, nous allons utiliser + l'option -m pour fournir un message de validation sur la ligne + de commande. + 

 $ git add hello.rb 
@@ -451,10 +459,11 @@ 

  1 files changed, 2 insertions(+), 1 deletions(-)
-

Now we have recorded the snapshot. If we run git status - again, we will see that we have a "clean working directory", which means - that we have not made any changes since our last commit - there is no - un-snapshotted work in our checkout.

+

Nous avons désormais enregistré un instantané. Si nous exécutons + git status à nouveau, nous allons voir que "la copie + de travail est propre", ce qui signifie que nous n'avons fait aucune + modification depuis notre dernière validation - il n'y a aucun + instantané en attente.

 $ git status
@@ -462,11 +471,12 @@ 

 nothing to commit (working directory clean)
-

If you leave off the -m option, Git will try to open a - text editor for you to write your commit message. In vim, - which it will default to if it can find nothing else in your settings, - the screen might look something like this: -

+

Si vous n'utilisez pas l'option -m option, Git va essayer + d'ouvrir un éditeur de texte pour écrire votre message de validation. + Dans vim, qui est utilisé par défaut à moins que vous + n'ayez configuré une alternative à utiliser, votre écran ressemblera + vraisemblablement à cela: + 

 
@@ -483,32 +493,32 @@ 

 ".git/COMMIT_EDITMSG" 9L, 257C
-

At this point you add your actual commit message at the top of the - document. Any lines starting with '#' will be ignored - Git will put - the output of the git status command in there for you as - a reminder of what you have modified and staged.

+

À ce stade vous ajoutez votre message de validation final au tout + début du document. Toute ligne qui commence par '#' sera ignorée - Git + va vous y ajouter la sortie de la commande git status + pour vous rappeler ce que vous avez modifié et mis en attente.

-

In general, it's very important to write a good commit message. - For open source projects, it's generally a rule to write your message - more or less in this format:

+

En règle générale, il est très important d'écrire de bons messages de validation. + Pour des projets libres, par convention vous écrirez votre message + plus ou moins dans ce format:

-Short (50 chars or less) summary of changes
+Un court (50 caractères ou moins) résumé des modifications
 
-More detailed explanatory text, if necessary.  Wrap it to about 72
-characters or so.  In some contexts, the first line is treated as the
-subject of an email and the rest of the text as the body.  The blank
-line separating the summary from the body is critical (unless you omit
-the body entirely); some git tools can get confused if you run the
-two together.
+Un texte explicatif plus détaillé, si nécessaire. Faites le tenir
+sur environ 72 caractères. Dans certains cas, la première ligne est
+traitée comme le sujet d'un email et le reste du texte comme le corps.
+Le saut de ligne entre le résumé et le corps est très important
+(à moins que vous omettiez complétement le corps); certains outils git
+peuvent mal fonctionner si vous les mettez l'un après l'autre.
 
-Further paragraphs come after blank lines.
+Les paragraphes supplémentaires viennent après d'autres sauts de ligne.
 
- - Bullet points are okay, too
+ - Les listes à puces sont possibles, aussi
 
- - Typically a hyphen or asterisk is used for the bullet, preceded by a
-   single space, with blank lines in between, but conventions vary
-   here
+ - Typiquement, un tiret ou une astérisque est utilisée comme puce,
+   précédée d'un seul espace, séparées par des sauts de ligne, mais
+   différentes conventions existent
 
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
@@ -524,32 +534,34 @@ 

 ".git/COMMIT_EDITMSG" 25L, 884C written
-

- The commit message is very important. Since much of the power of - Git is this flexibility in carefully crafting commits locally and then - sharing them later, it is very powerful to be able to write three or - four commits of logically separate changes so that your work may be more - easily peer reviewed. Since there is a separation between committing and - pushing those changes, do take the time to make it easier for the people - you are working with to see what you've done by putting each logically - separate change in a separate commit with a nice commit message so it - is easier for them to see what you are doing and why.

- -

- git commit -a - automatically stage all tracked, modified files before the commit -

- -

If you think the git add stage of the workflow is too - cumbersome, Git allows you to skip that part with the -a - option. This basically tells Git to run git add on any file - that is "tracked" - that is, any file that was in your last commit and - has been modified. This allows you to do a more Subversion style workflow - if you want, simply editing files and then running git commit -a - when you want to snapshot everything that has been changed. You still need - to run git add to start tracking new files, though, just like - Subversion. -

+

+ Le message de validation est très important. Étant donné qu'une grande + part de la puissance de Git est cette souplesse dans la création attentionnée + des validations en local pour les partager ensuite, c'est très utile de + pouvoir écrire trois ou quatre validations sur des modifications indépendantes + afin que votre travail puisse être examiné plus facilement par vos pairs. + Étant donné qu'il y a une séparation entre valider et pousser ses modifications, + prenez bien le temps de faciliter aux personnes avec lesquelles vous travaillez + la lecture de ce que vous avez fait en plaçant chaque modification indépendante + dans une validation propre avec un joli message de validation pour que ce soit + simple pour eux de voir ce que vous faites et pourquoi.

+ +

+ git commit -a + mettre automatiquement en attente toutes modifications suivies et modifiées avant la validation +

+ +

Si l'étape git add du flux de travail vous paraît lourde, + Git vous permet de sauter celle-ci avec l'option -a. + Cela va basiquement dire à Git d'exécuter git add sur + chaque fichier qui est "suivi" - c'est-à-dire, chaque fichier qui fait + partie de votre dernière validation et qui a été modifiée. Cela vous permet + d'avoir un flux de travail plus proche de celui de Subversion si vous le voulez, + éditez simplement vos fichiers puis exécutez git commit -a + pour réaliser un instantané de tout ce qui a changé. Vous aurez toujours à + exécuter git add pour commencer à suivre de nouveaux fichiers, + néanmoins, tout comme avec Subversion. + 

 $ vim hello.rb
@@ -569,67 +581,69 @@ 

  1 files changed, 2 insertions(+), 1 deletions(-)
-

Notice how if you don't stage any changes and then run - git commit, Git will simply give you the output of the - git status command, reminding you that nothing is staged. - The important part of that message has been highlighted, saying that nothing - is added to be committed. If you use -a, it will add and - commit everything at once. -

- -

This now lets you complete the entire snapshotting workflow - you - make changes to your files, then use git add to stage - files you want to change, git status and git diff - to see what you've changed, and then finally git commit - to actually record the snapshot forever.

- -

- In a nutshell, - you run git commit to record the snapshot of your staged - content. This snapshot can then be compared, shared and reverted to - if you need to. -

- -
-
- -
-

- - docs   - book - - git reset - undo changes and commits -

- -
-

git reset is probably the most confusing command written - by humans, but it can be very useful once you get the hang of it. - There are three specific invocations of it that are generally - helpful. -

- -

- git reset HEAD - unstage files from index and reset pointer to HEAD -

- -

First, you can use it to unstage something that has been - accidentally staged. Let's say that you have modified two files and want - to record them into two different commits. You should stage and commit - one, then stage and commit the other. If you accidentally stage both of - them, how do you un-stage one? You do it with - git reset HEAD -- file. Technically you don't have to - add the -- - it is used to tell Git when you have stopped - listing options and are now listing file paths, but it's probably good to - get into the habit of using it to separate options from paths even if you - don't need to. -

- -

Let's see what it looks like to unstage something. Here we have - two files that have been modified since our last commit. We will stage - both, then unstage one of them.

+

Notez que si vous ne placez en attente aucune modification et que vous exécutez + git commit, Git va simplement vous retourner la sortie de la + commande git status, pour vous rappeler que rien n'a été mis en attente. + La partie importante de ce message a été mise en valeur, et signifie que + rien n'a été ajouté pour validation. Si vous utilisez -a, + cela va tout ajouter et valider en même temps. +

+ +

Cela va vous permettre de finaliser le flux de travail complet des + instantanés - vous faites des modifications à vos fichiers, vous utilisez + ensuite git add pour mettre en attente les fichiers que vous avez + modifiés, git status et git diff pour voir + ce que vous avez modifié, et finalement git commit + pour finalement enregistrer définitivement votre instantané.

+ +

+ Pour résumer, + vous exécutez git commit pour enregistrer l'instantané + de votre contenu en attente. Cet instantané peut ensuite être comparé, + partagé et rembobiné au besoin. +

+ +
+
+ +
+

+ + docs   + livre + + git reset + annuler des changements et validations +

+ +
+

git reset est probablement la commande source de la plus + grande confusion jamais écrite, mais elle peut être extrémement utile + une fois qu'on en a saisi le principe. Il y a trois invocations spécifiques + de cette commande qui sont communément utilisées. +

+ +

+ git reset HEAD + retirer des fichiers de l'index et ré-initialiser le pointeur vers HEAD +

+ +

Pour commencer, vous pouvez l'utiliser pour enlever quelque chose de placé + accidentellement dans la zone d'attente. Imaginons que vous avez modifié + deux fichiers et que vous vouliez les enregistrer dans deux validations différentes. + Vous devriez faire une mise en attente et validation, puis mettre en attente et valider + l'autre. Si vous avez accidentellement mis les deux en attente, comme en + dé-mettre en attente une? Vous le faites avec + git reset HEAD -- fichier. Techniquement vous n'avez pas à ajouter + le -- - il est utilisé pour dire à Git où se termine la liste des options + et où commence la liste des chemins de fichiers, mais il est probablement sûr + de prendre l'habitude de l'utiliser pour séparer les options des chemins + même si vous n'en avez pas besoin. +

+ +

Voyons à quoi cela ressemble de sortir quelque chose de la zone d'attente. + Ici nous avons deux fichiers qui ont été modifiés depuis notre dernière validation. + Nous allons les mettre en attente tous les deux, puis en sortir un des deux.

 $ git status -s
@@ -647,32 +661,34 @@ 

  M hello.rb
-

Now you can run a git commit which will just record - the changes to the README file, not the now unstaged - hello.rb. -

- -

- In case you're curious, what it's actually doing here is it is resetting - the checksum of the entry for that file in the "index" to be what it was - in the last commit. Since git add checksums a file and adds - it to the "index", git reset HEAD overwrites that with what - it was before, thereby effectively unstaging it. -

- -

- If you want to be able to just run git unstage, you can easily - setup an alias in Git. Just run - git config --global alias.unstage "reset HEAD". - Once you have run that, you can then just run - git unstage [file] instead. -

- -

If you forget the command to unstage something, Git is helpful in - reminding you in the output of the normal git status - command. For example, if you run git status without - the -s when you have staged files, it will tell you - how to unstage them:

+

Maintenant vous pouvez exécuter git commit qui va juste + enregistrer les modifications du fichier README, pas celles + du fichier hello.rb. +

+ +

+ Si vous êtes curieux, ce qui est fait concrétement ici est de rembobiner + la somme de contrôle de l'entrée de ce fichier dans l'"index" à ce qu'il + était dans la dernière validation. Vu que git add crée une somme + de contrôle d'un fichier et l'ajoute à l'"index", git reset HEAD + écrase cela avec ce qui l'était précédemment, pour ainsi effectivement le sortir + de la zone d'attente. +

+ +

+ Si vous voulez être capable de simplement exécuter git unstage, + vous pouvez facilement définir un alias dans Git. Exécutez simplement + git config --global alias.unstage "reset HEAD". + Une fois exécuté, vous pouvez ensuite exécuter + git unstage [fichier] à la place. +

+ +

Si vous oubliez quelle est la commande pour sortir quelque chose + de la zone d'attente , Git vient à votre aide en vous le rappelant + dans la sortie de la commande normale git status. + Par exemple, si vous exécutez git status sans le + -s quand vous avez des fichiers en attente, il vous + dira comment les en sortir:

 $ git status
@@ -685,21 +701,21 @@ 

 #
-

When you run git reset without specifying a flag - it defaults to --mixed. The other options are - --soft and --hard.

+

Quand vous exécutez git reset sans spécifier un drapeau + il utilise par défaut --mixed. Les autres options sont + --soft et --hard.

-

- git reset --soft - moves HEAD to specified commit reference, index and staging are untouched -

+

+ git reset --soft + déplacer HEAD vers une référence spécifique de validation, l'index et la zone d'attente restant inchangés +

-

The first thing git reset does is undo the last - commit and put the files back onto the stage. If you include the - --soft flag this is where it stops. For example, - if you run git reset --soft HEAD~ (the parent of the - HEAD) the last commit will be undone and the files touched - will be back on the stage again.

+

La première chose que fait git reset est d'annuler + la dernière validation et remettre les fichiers dans la zone d'attente. + Si vous incluez le drapeau --soft il s'en arrête là. + Par exemple, si vous exécutez git reset --soft HEAD~ + (le parent de HEAD) la dernière validation sera annulée et les fichiers + modifiés seront remis dans la zone d'attente à nouveau.

 $ git status -s
@@ -715,20 +731,21 @@ 

 M  hello.rb
-

This is basically doing the same thing as - git commit --amend, allowing you to do more work - before you roll in the file changes into the same commit.

+

Cela fait basiquement la même chose que + git commit --amend, vous permettant de continuer + à travailler avant que vous n'ajoutiez les modifications de fichiers + dans la même validation.

-

- git reset --hard - unstage files AND undo any changes in the working directory since last commit -

+

+ git reset --hard + sortir de la zone d'attente ET annuler les modifications du dossier de travail depuis la dernière validation +

-

The third option is to go --hard and make your working - directory look like the index, unstage files and undo any changes made - since the last commit. - This is the most dangerous option and not working directory safe. Any - changes not in the index or have not been commited will be lost.

+

La troisième option est --hard pour rendre votre dossier de + travail identique à l'index, sortir les fichiers de la zone d'attente et + annuler toute modification faite depuis la dernière validation. + C'est l'option la plus dangereuse et non sûre pour votre dossier de + travail. Toute modification non présente dans l'index ou une validation sera perdue.

 $ git status
@@ -751,111 +768,117 @@ 

 nothing to commit (working directory clean)
-

In the above example, while we had both changes ready to commit and - ready to stage, a git reset --hard wiped them out. - The working tree and staging area are reset to the tip of the current - branch or HEAD.

- -

You can replace HEAD with a commit SHA-1 or another - parent reference to reset to that specific point.

- -

- In a nutshell, - you run git reset HEAD to undo the last commit, unstage - files that you previously ran git add on and wish to not - include in the next commit snapshot

- -
-
- -
-

- - docs   - book - - git rm - remove files from the staging area -

- -
- -

git rm will remove entries from the staging area. - This is a bit different from git reset HEAD which "unstages" - files. To "unstage" means it reverts the staging area to what was - there before we started modifying things. git rm on the - other hand just kicks the file off the stage entirely, so that it's not - included in the next commit snapshot, thereby effectively deleting it.

- -

By default, a git rm file will remove the file from the - staging area entirely and also off your disk (the working directory). To - leave the file in the working directory, you can use git rm --cached - .

- -

- git mv - git rm --cached orig; mv orig new; git add new -

- -

- Unlike most other version control systems, Git does not track file renames. - Instead, it just tracks the snapshots and then figures out what files were - likely renamed by comparing snapshots. If a file was removed from one - snapshot and another file was added to the next one and the contents are - similar, Git figures it was most likely a rename. So, although the - git mv command exists, it is superfluous - all it does is a - git rm --cached, moves the file on disk, then runs a - git add on the new file. You don't really need to use it, but - if it's easier, feel free. -

- -

- In its normal form the command is used to delete files. - But it's often easier to just remove the files off your disk and - then run git commit -a, which will also automatically remove - them from your index.

- -

- In a nutshell, - you run git rm to remove files from being tracked in Git. It - will also remove them from your working directory. -

- -
-
- -
-

- - docs   - book - - git stash - save changes made in the current index and working directory for later -

- -
- -

You're in the middle of some changes but something comes up that you - need to jump over to, like a so-urgent-right-now bugfix, but don't want - to commit or lose your current edits. git stash is there for you. -

- -

- git stash - add current changes to the stack -

- -

Stashing takes the current state of the working directory and index, - puts it on a stack for later, and gives you back a clean working directory. - It will then leave you at the state of the last commit. -

- -

If you have untracked files, git stash will not include - them. You can either stage those files with git add (you don't - have to commit) before stashing, or, if you have a recent Git version - (1.7.7 or above), you can use git stash -u to also stash also - unversioned files.

+

Dans l'exemple ci-dessus, alors que nous avions toutes les modifications + prêtes à être validées et ajoutées, un git reset --hard + les a complétement supprimées. Le dossier de travail et la zone d'attente + sont ré-initialisés à l'extrémité de la branche courante ou HEAD.

+ +

Vous pouvez remplacer HEAD avec le SHA-1 d'une validation + ou une autre référence vers un parent pour ré-initialiser en un point + spécifique.

+ +

+ Pour résumer, + vous exécutez git reset HEAD pour annuler la dernière validation, + sortir de la zone d'attente des fichiers sur lesquels vous aviez exécuté + git add et que vous ne désirez pas inclure dans le prochain + instantané d'une validation.

+ +
+
+ +
+

+ + docs   + livre + + git rm + supprimer des fichiers de la zone d'attente +

+ +
+ +

git rm va supprimer des entrées de la zone d'attente. + C'est un peu différent de git reset HEAD qui enlève des + fichiers de la zone d'attente. Sortir de la zone d'attente signifie + ré-initialiser la zone d'attente à l'état dans lequel elle était avant + que nous commencions à modifier des choses. git rm d'un + autre côté sort simplement le fichier de la zone d'attente, de sorte + qu'il ne sera pas inclus dans le prochain instantané de validation, + le supprimant effectivement ainsi.

+ +

Par défaut, un git rm file va supprimer complètement + le fichier de la zone d'attente et aussi de votre disque (le dossier + de travail). Pour laisser le fichier dans le dossier de travail, + vous pouvez utiliser git rm --cached.

+ +

+ git mv + git rm --cached orig; mv original nouveau; git add nouveau +

+ +

+ Contrairement à la plupart des systèmes de gestion de versions, Git ne + suit pas le renommage des fichiers. À la place, il suit juste les instantanés + et ensuite arrive à comprendre quels fichiers ont pu être renommés + en comparant les instantanés. Si un fichier a été supprimé d'un instantané + et un autre fichier a été ajouté au suivant et leur contenu est similaire, + Git décidera que c'est sûrement un renommage. Alors, bien que la commande + git mv existe, elle est superflue - tout ce qu'elle fait est un + git rm --cached, renomme le fichier sur le disque, puis exécute un + git add sur le nouveau fichier. Vous n'avez pas vraiment besoin + de l'utiliser, mais si cela vous semble plus simple, n'hésitez pas. +

+ +

+ Dans sa forme commune la commande est utilisée pour supprimer les fichiers. + Mais il est souvent plus simple de juste supprimer les fichiers du disque + puis exécuter git commit -a, ce qui va également automatiquement + les supprimer de l'index.

+ +

+ Pour résumer, + vous exécutez git rm pour supprimer des fichiers du suivi de Git. + Cela va également les supprimer de votre dossier de travail. +

+ +
+
+ +
+

+ + docs   + livre + + git stash + sauvegarder des modifications faites dans l'index courant et le dossier de travail pour plus tard +

+ +
+ +

Vous êtes au beau milieu de modifications mais quelque chose se présente + qui nécessite que vous vous en occupiez, comme une si urgente-tout-de-suite + correction de bug, mais ne souhaitez pas valider ou perdre vos modifications + en cours. git stash est là pour vous. +

+ +

+ git stash + réserver les modifications courantes sur la pile +

+ +

Réserver prend l'état courant de votre dossier de travail et de l'index, + les place sur une pile pour plus tard, et vous offre en retour un dossier + de travail propre. Cela va vous ramener à l'état de la dernière validation. +

+ +

Si vous avez des fichiers non suivis, git stash ne les inclura pas. + Vous pouvez soit les placer en zone d'attente avec git add (vous n'avez + pas à valider) avant de les réserver, ou, si vous avez une version récente de Git + (1.7.7 ou plus), vous pouvez utiliser git stash -u pour aussi + réserver des fichiers non versionnés.

 $ git status -s
@@ -868,24 +891,24 @@ 

 nothing to commit (working directory clean)
-

- git stash list - view stashes currently on the stack -

+

+ git stash list + voir les réservations présentes sur la pile +

-

It's helpful to know what you've got stowed on the stash and this is where - git stash list comes in. Running this command will display a queue - of current stash items. -

+

C'est utile de savoir ce que vous avez stocké sur la pile et c'est la où + git stash list entre en jeu. Exécuter cette commande + va vous afficher la liste courante des éléments réservés. + 

 $ git stash list
 stash@{0}: WIP on master: 5857ac1 hello with a flower
-

The last item added onto the stash will be referenced by - stash@{0} and increment those already there by one. -

+

Le dernier élément ajouté sur la pile sera référencé par + stash@{0} et incrémentera ceux déjà présents. + 

 $ vim hello.rb
@@ -901,15 +924,15 @@ 

 stash@{1}: WIP on master: 5857ac1 hello with a flower
-

- git stash apply - grab the item from the stash list and apply to current working directory -

+

+ git stash apply + récupérer l'élément depuis la liste de la pile et l'appliquer au dossier de travail courant +

-

When you're ready to continue from where you left off, run the - git stash apply command to bring back the saved changes - onto the working directory. -

+

Quand vous êtes prêt à continuer là où vous en êtiez, exécutez la + commande git stash apply pour récupérer les modifications + sauvegardées dans le dossier de travail. + 

 $ git stash apply
@@ -923,51 +946,50 @@ 

 no changes added to commit (use "git add" and/or "git commit -a")
-

By default it will reapply the last added stash item to the working - directory. This will be the item referenced by stash@{0}. - You can grab another stash item instead if you reference it in the arguments - list. For example, git stash apply stash@{1} will apply the item - referenced by stash@{1}. -

- -

If you also want to remove the item from the stack at the same time, - use git stash pop instead. -

- -

- git stash drop - remove an item from the stash list -

- -

When you're done with the stashed item and/or want to remove it from the - list, run the git stash drop command. By default this will - remove the last added stash item. You can also remove a specific item if - you include it as an argument. -

- -

In this example, our stash list has at least two items, but we want - to get rid of the item added before last, which is referenced by - stash@{1}. -

+

Par défaut il va appliquer le dernier élément appliqué au dossier + de travail. Ce sera l'élément référencé par stash@{0}. + Vous pouvez récupérer à la place un autre élément réservé si vous le référencez + dans la liste des arguments. Par exemple, git stash apply stash@{1} + va appliquer l'élément référencé par stash@{1}. +

+ +

Si vous voulez également supprimer l'élément de la pile en même temps, + utilisez git stash pop à la place. +

+ +

+ git stash drop + supprimer un élément de la liste de la pile +

+ +

Quand vous en avez fini avec un élément réservé et/ou vous voulez le + supprimer de la liste, exécutez la commande git stash drop. + Par défaut cela va supprimer le dernier élément réservé ajouté. Vous pouvez + aussi supprimer un élément en particulier si vous l'indiquez en tant qu'argument. +

+ +

Dans cet exemple, notre pile a au moins deux éléments, mais nous + voulons nous débarasser de l'élément ajouté avant le dernier, qui + est référencé par stash@{1}. + 

 $ git stash drop stash@{1}
 Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
-

If you want to remove of all the stored items, just run - the git stash clear command. But only do this if you're - sure you're done with the stash. -

- -

- In a nutshell, run git stash to quickly save - some changes that you're not ready to commit or save, but want to come - back to while you work on something else. -

+

Si vous voulez supprimer tous les éléments réservés, exécutez juste + la commande git stash clear. Mais faites cela seulement + si vous êtes sûr d'en avoir fini avec la pile. +

-
-
+

+ Pour résumer, exécutez git stash pour rapidement + sauvegarder les modifications que vous n'êtes pas prêt de valider ou sauver, mais + auxquelles vous voulez revenir après avoir travaillé sur autre chose. +

-

On to Branching and Merging »

+
+
+

Aller à Branche et Fusion »

From 2b9507a4119c3ab8c23316d234fbdeaeef62b411 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 14 Jan 2016 21:58:05 +0100 Subject: [PATCH 12/22] FR: Branching --- fr/branching/index.html | 787 +++++++++++++++++++++------------------- 1 file changed, 410 insertions(+), 377 deletions(-) diff --git a/fr/branching/index.html b/fr/branching/index.html index 96112be..47a91fd 100644 --- a/fr/branching/index.html +++ b/fr/branching/index.html @@ -1,35 +1,36 @@ --- -layout: reference +layout: fr_reference ---

- book + livre - Branching and Merging + Branches et Fusions

-

Branching in Git is one of its many great features. If you have used other - version control systems, it's probably helpful to forget most of what you - think about branches - in fact, it may be more helpful to think of them - practically as contexts since that is how you will most often be - using them. When you checkout different branches, you change contexts - that you are working in and you can quickly context-switch back and forth - between several different branches. +

Les branches sont une des nombreuses fonctionnalités intéressantes de Git. + Si vous avez utilisé d'autres systèmes de gestion de versions, il sera + probablement utile d'oublier tout ce que vous savez sur les branches - + En fait, il sera encore plus utile de les voir quasiment comme des + contextes car c'est la façon la plus courante dont vous allez + vous en servir. Quand vous basculez dans des branches, vous changez de + contextes de travail et vous pouvez rapidement basculer de l'une à l'autre.

- In a nutshell you can create a branch with - git branch (branchname), switch into that context with - git checkout (branchname), record commit snapshots while - in that context, then can switch back and forth easily. When you switch - branches, Git replaces your working directory with the snapshot of the - latest commit on that branch so you don't have to have multiple directories - for multiple branches. You merge branches together with - git merge. You can easily merge multiple times from the same - branch over time, or alternately you can choose to delete a branch - immediately after merging it. + Pour résumer, vous pouvez créer une branche avec + git branch (nombranche), basculer dans ce contexte avec + git checkout (nombranche), enregistrer un instantané de validation + depuis ce contexte, puis basculer d'une branche à l'autre facilement. + Quand vous changez de branche, Git remplace votre dossier de travail + avec l'instantané de la dernière validation de cette branche afin que vous + n'ayez pas de multiples dossiers pour de multiples branches. Vous fusionnez + des branches ensemble avec git merge. Vous pouvez facilement + faire plusieurs fusions étalées dans le temps depuis la même branche, + ou alternativement vous pouvez choisir de supprimer une branche dès + que vous l'avez fusionnée.

@@ -39,10 +40,10 @@

docs   - book + livre git branch - list, create and manage working contexts + lister, créer et gérer les contextes de travail


@@ -50,30 +51,30 @@

docs   - book + livre git checkout - switch to a new branch context + basculer vers un nouveau contexte de branche

-

The git branch command is a general branch management tool - for Git and can do several different things. We'll cover the basic ones - that you'll use most - listing branches, creating branches and deleting - branches. We will also cover basic git checkout here which - switches you between your branches. +

La commande git branch est un outil de gestion général des branches + de Git et peut faire de nombreuses choses différentes. Nous allons aborder + celles de base que vous utiliserez le plus souvent - lister les branches, créer + des branches et supprimer des branches. Nous allons aussi aborder + git checkout ici qui vous permet de basculer entre branches.

git branch - list your available branches + lister vos branches disponibles

-

Without arguments, git branch will list out the local - branches that you have. The branch that you are currently working on will - have a star next to it and if you have - coloring turned on, - will show the current branch in green. +

Sans argument, git branch va lister vos branches locales. + La branche courante sur laquelle vous êtes sera précédée d'un astérisque + et si vous avez + la colorisation activée, + la branche courante sera affichée en vert. 

@@ -81,21 +82,21 @@ 

 * master
-

This means that we have a 'master' branch and we are currently on it. - When you run git init it will automatically create a 'master' - branch for you by default, however there is nothing special about the name - - you don't actually have to have a 'master' branch but since it's the default - that is created, most projects do. +

Cela signifie que nous avons une branche 'master' et que nous sommes sur + celle-ci. Quand vous exécutez git init cela va automatiquement + créer une branche 'master' pour vous par défaut, néanmoins il n'y a rien + de particulier dans ce nom - vous n'avez pas en fait à avoir de branche 'master' + mais étant donné qu'elle est créée par défaut, la plupart des projets en ont une.

- git branch (branchname) - create a new branch + git branch (nombranche) + créer une nouvelle branche

-

So let's start by creating a new branch and switching to it. You can do - that by running git branch (branchname). -

+

Commençons par créer une nouvelle branche puis basculons vers celle-ci. + Vous pouvez le faire en exécutant git branch (nombranche). + 

 $ git branch testing
@@ -104,13 +105,13 @@ 

   testing
-

Now we can see that we have a new branch. When you create a branch this - way it creates the branch at your last commit so if you record some commits - at this point and then switch to 'testing', it will revert your working - directory context back to when you created the branch in the first place - - you can think of it like a bookmark for where you currently are. Let's see - this in action - we use git checkout (branch) to switch the - branch we're currently on. +

Vous pouvez voir que nous avons une nouvelle branche. Quand vous créez une + branche de cette manière cela crée la branche basée sur votre dernière validation + donc si à ce stade vous créez des validations puis basculez vers 'testing', + vous rétablirez le contexte de votre dossier de travail à celui où il était + lorsque la branche a été créée initialement - Vous pouvez penser à cela comme + un signet qui indique où vous en êtes. Voyons cela en action - nous utilisons + git checkout (branche) pour changer de branche courante. 

@@ -132,9 +133,9 @@ 

 README   hello.rb
-

So now we can see that when we switch to the 'testing' branch, our new - files were removed. We could switch back to the 'master' branch and see - them re-appear.

+

Nous voyons que lorsque nous basculons vers la branche 'testing', + nos nouveaux fichiers ont disparu. Nous pouvons retourner vers la + branche 'master' et les voir ré-apparaître.

 $ ls
@@ -145,13 +146,13 @@ 

 README   hello.rb more.txt test.txt
-

- git branch -v - see the last commit on each branch -

+

+ git branch -v + voir la dernière validation de chaque branche +

-

If we want to see last commits on each branch - we can run git branch -v to see them.

+

Si nous voulons voir les dernières validations de chaque branche + nous pouvons exécuter git branch -v pour les voir.

 $ git branch -v
@@ -160,19 +161,20 @@ 

   testing     62a557a update test scripts
-

- git checkout -b (branchname) - create and immediately switch to a branch -

- -

- In most cases you will be wanting to switch to the branch immediately, so - you can do work in it and then merging into a branch that only contains - stable work (such as 'master') at a later point when the work in your new - context branch is stable. You can do this pretty easily with - git branch newbranch; git checkout newbranch, but Git gives - you a shortcut for this: git checkout -b newbranch. -

+

+ git checkout -b (nombranche) + créer et basculer immédiatement vers une branche +

+ +

+ Dans la plupart des cas vous voudrez basculer vers la branche immédiatement, + afin de pouvoir y travailler puis fusionner dans une branche qui contient + seulement du travail stable (comme 'master') plus tard lorsque le travail + dans votre nouveau contexte de branche sera stable. Vous pouvez faire cela + relativement facilement avec + git branch nouvellebranche; git checkout nouvellebranche, + mais Git a un raccourci pour cela: git checkout -b nouvellebranche. + 

 $ git branch
@@ -198,27 +200,28 @@ 

 README   hello.rb more.txt test.txt
-

You can see there how we created a branch, removed some of our files - while in the context of that branch, then switched back to our main branch - and we see the files return. Branching safely isolates work that we do into - contexts we can switch between.

- -

- If you start on work it is very useful to - always start it in a branch (because it's fast and easy to do) and then - merge it in and delete the branch when you're done. That way if what you're - working on doesn't work out you can easily discard it and if you're forced - to switch back to a more stable context your work in progress is easy to put - aside and then come back to.

- -

- git branch -d (branchname) - delete a branch -

- -

If we want to delete a branch (such as the 'testing' branch in the - previous example, since there is no unique work on it), - we can run git branch -d (branch) to remove it.

+

Vous pouvez voir ici comment nous avons créé une branche, supprimé certains de nos + fichiers depuis le contexte de cette branche, puis nous sommes retournés dans + notre branche principale et nous voyons à nouveau nos fichiers. Les branches + isolent de manière sécurisée le travail que nous faisons en des contextes + entre lesquels nous pouvons basculer.

+ +

+ Si vous démarrez un travail il est très sutile de toujours le démarrer dans une + branche (parce-que cela est rapide et facile à faire) puis de le fusionner et + supprimer la branche quand vous en avez terminé. De cette manière si ce sur quoi + vous travaillez ne convient pas vous pouvez facilement vous en débarasser, et + si vous êtes forcé de basculer vers un contexte de travail plus stable, votre travail + en cours est facile à mettre de côté et à retrouver plus tard.

+ +

+ git branch -d (nombranche) + supprimer une branche +

+ +

Si nous voulons supprimer une branche (comme la branche 'testing' de + l'exemple précédent vu qu'il n'y a aucun travail particulier sur celle-ci), + nous pouvons exécuter git branch -d (branche) pour la supprimer.

 $ git branch
@@ -230,15 +233,15 @@ 

 * master
-

- git push (remote-name) :(branchname) - delete a remote branch -

+

+ git push (nom-distant) :(nombranche) + supprimer une branche distante +

-

When you're done with a remote branch, whether it's been merged - into the remote master or you want to abandon it and sweep it under - the rug, you'll issue a git push command with a specially - placed colon symbol to remove that branch.

+

Quand vous en avez fini avec une branche distante, qu'elle ait + été fusionnée dans le dépôt distant ou que vous vouliez l'abandonner + et la cacher des regards, vous exécuterez la commande git push + avec un symbôle deux-points savamment placé pour supprimer la branche:

 $ git push origin :tidy-cutlery
@@ -246,50 +249,53 @@ 

  - [deleted]         tidy-cutlery
-

In the above example you've deleted the "tidy-cutlery" branch - of the "origin" remote. A way to remember this is to think of the - git push remote-name local-branch:remote-branch syntax. - This states that you want to push your local branch to match that - of the remote. When you remove the local-branch portion - you're now matching nothing to the remote, effectively telling the - remote branch to become nothing. -

- -

Alternatively, you can run - git push remote-name --delete branchname - which is a wrapper for the colon refspec (a source:destination pair) - of deleting a remote branch. -

- -

- In a nutshell you use git branch to list your - current branches, create new branches and delete unnecessary or - already merged branches. -

- -
-
- -
-

- - docs   - book - - git merge - merge a branch context into your current one -

- -
-

Once you have work isolated in a branch, you will eventually want to - incorporate it into your main branch. You can merge any branch into your - current branch with the git merge command. Let's take as a - simple example the 'removals' branch from above. If we create a branch - and remove files in it and commit our removals to that branch, it is - isolated from our main ('master', in this case) branch. To include those - deletions in your 'master' branch, you can just merge in the 'removals' - branch. -

+

Dans l'exemple ci-dessus vous avez supprimé la branche "tidy-cutlery" + du dépôt distant "origin". Un moyen de se souvenir de cette syntaxe est + de penser à celle de + git push nom-distant branche-locale:branche-distante. + Cela signifie que vous désirez pousser votre branche locale pour + qu'elle soit similaire sur le dépôt distant. Quand vous supprimez + la portion branche-locale vous ne faites alors plus rien + correspondre sur le dépôt distant, signifiant concrètement à la + branche distante d'être nulle. +

+ +

Alternativement, vous pouvez exécuter + git push nom-distant --delete nombranche + qui est raccourci pour la syntaxe deux-points (une paire + source:destination) de suppression d'une branche distante. +

+ +

+ Pour résumer, vous utilisez git branch pour lister + vos branches, créer de nouvelles branches et supprimer des branches + inutiles ou qui ont été fusionnées. +

+ +
+
+ +
+

+ + docs   + livre + + git merge + fusionner le contexte d'une branche dans votre contexte courant +

+ +
+

Une fois isolé un travail dans une branche, vous allez peut-être + l'incorporer dans votre branche principale. Vous pouvez fusionner + toute branche dans votre branche courante avec la commande + git merge. Prenons comme exemple simple la branche + 'removals' précédente. Si nous créons une branche et supprimons les fichiers + qui s'y trouvent puis que nous validons ces suppressions dans cette branche, + cela est isolé de notre branche principale ('master', dans notre cas). Pour + inclure ces suppressions dans notre branche 'master', vous pouvez simplement + fusionner la branche 'removals'. + 

 $ git branch
@@ -309,16 +315,17 @@ 

 README   hello.rb
-

- more complex merges -

+

+ fusions plus avancées +

-

Of course, this doesn't just work for simple file additions and - deletions. Git will merge file modifications as well - in fact, it's very - good at it. For example, let's see what happens when we edit a file in - one branch and in another branch we rename it and then edit it and then - merge these branches together. Chaos, you say? Let's see. -

+

Bien sûr, cela ne marche pas juste pour de simples ajouts et suppressions + de fichiers. Git va tout autant fusionner les modifications de fichiers - + En fait, il est même très bon pour ça. Par exemple, voyons ce qu'il arrive + quand on édite un fichier dans une branche et dans une autre branche + nous le renommons et puis l'éditons et enfin nous fusionnons ensemble + ces branches. Chaos, vous avez dit? Voyons cela. + 

 $ git branch
@@ -333,9 +340,10 @@ 

 HelloWorld.hello
-

So first we're going to create a new branch named 'change_class' and - switch to it so your class renaming changes are isolated. We're going to - change each instance of 'HelloWorld' to 'HiWorld'.

+

Nous allons donc commencer par créer une nouvelle branche nommée + 'change_class' basculer vers celle-ci afin que vos modifications + de renommage de classe soient isolées. Nous allons changer chaque + instance de 'HelloWorld' en 'HiWorld'.

 $ git checkout -b change_class
@@ -348,12 +356,13 @@ 

  1 files changed, 2 insertions(+), 4 deletions(-)
-

So now we've committed the class renaming changes to the 'change_class' - branch. To switch back to the 'master' branch the class name will - revert to what it was before we switched branches. Here we can change - something different (in this case the printed output) and at the same - time rename the file from hello.rb to ruby.rb. -

+

Nous avons alors validé les changements de nom de la classe dans + une branche 'change_class'. En retournant vers la branche 'master' + le nom de la classe sera ré-initialisé à ce à quoi il était avant + que nous changions de branche. Ici nous pouvons modifier quelque chose + de différent (dans ce cas la sortie affichée) et en même temps + renommer le fichier hello.rb en ruby.rb. + 

 $ git checkout master
@@ -380,11 +389,11 @@ 

  rename hello.rb => ruby.rb (65%)
-

Now those changes are recorded in the 'master' branch. Notice that the - class name is back to 'HelloWorld', not 'HiWorld'. To incorporate - the 'HiWorld' change we can just merge in the 'change_class' - branch. However, the name of the file has changed since we branched, - what will Git do?

+

Désormais ces modifications sont sauvées dans la branche 'master'. Notez + que le nom de la classe est de nouveau 'HelloWorld', et non 'HiWorld'. + Pou incorporer le changement 'HiWorld' nous pouvons juste fusionner + la branche 'change_class'. Néanmoins, le nom du fichier a changé depuis + que nous avons changé de branche, que va faire Git?

 $ git branch
@@ -406,20 +415,20 @@ 

 HiWorld.hello
-

Well, it will just figure it out. Notice that there are no merge conflicts - and the file that had been renamed now has the 'HiWorld' class name change - that was done in the other branch. Pretty cool.

+

Et bien, il va simplement s'en rendre compte. Notez qu'il n'y a aucun conflit de + fusion et que le fichier qui a été renommé a maintenant le changement de nom + de de classe 'HiWorld' qui a été fait dans l'autre branche. Plutôt cool.

-

- merge conflicts -

+

+ merge conflicts +

-

So, Git merges are magical, we never ever have to deal with merge - conflicts again, right? Not quite. In situations where the same block - of code is edited in different branches there is no way for a computer - to figure it out, so it's up to us. Let's see another example of changing - the same line in two branches. -

+

Donc, les fusions Git relèvent de la magie, nous n'avons jamais à traiter + des conflits de fusion? Pas tout à fait. Dans des situations où + un même bloc de code est édité dans différentes branches il n'y a aucun moyen + pour un ordinateur de s'y retrouver, alors c'est à nous de nous débrouiller. + Voyons un autre exemple de changement d'une même ligne dans deux branches. + 

 $ git branch
@@ -432,9 +441,9 @@ 

  1 files changed, 1 insertions(+), 1 deletions(-)
-

Now we have committed a change to one line in our README file in a - branch. Now let's change the same line in a different way back on - our 'master' branch.

+

Maintenant nous avons validé un changement d'une ligne dans notre + fichier README dans une branche. Maintenant changeons la même ligne + d'une manière différente depuis notre branche 'master'.

 $ git checkout master
@@ -445,8 +454,8 @@ 

  1 files changed, 1 insertions(+), 1 deletions(-)
-

Now is the fun part - we will merge the first branch into our master - branch, causing a merge conflict.

+

C'est maintenant le plus rigolo - nous allons fusionner la première + branche dans notre branche 'master', provoquant un conflit de fusion.

 $ git merge fix_readme
@@ -464,13 +473,14 @@ 

 nearly every programming language.
-

You can see that Git inserts standard merge conflict markers, much like - Subversion, into files when it gets a merge conflict. Now it's up to us - to resolve them. We will do it manually here, but check out - git mergetool - if you want Git to fire up a graphical mergetool - (like kdiff3, emerge, p4merge, etc) instead. -

+

Vous pouvez voir que Git insère des marqueurs standards de conflit de fusion, + très similaires à Subversion, dans les fichiers qui ont un conflit de fusion. + Maintenant c'est à vous de les résoudre. Nous allons le faire manuellement, + mais regardez + git mergetool + si vous voulez que Git lance un outil graphique de fusion + (comme kdiff3, emerge, p4merge, etc) à la place. + 

 $ vim README   # here I'm fixing the conflict
@@ -487,11 +497,12 @@ 

   This project has examples of hello world in
-

A cool tip in doing merge conflict resolution in Git is that if you - run git diff, it will show you both sides of the conflict - and how you've resolved it as shown here. Now it's time to mark - the file as resolved. In Git we do that with git add - - to tell Git the file has been resolved you have to stage it.

+

Un bon conseil lors de la résolution de conflit de fusion est que si + vous exécutez git diff, cela va vous montrer chaque côté + du conflit et comment vous l'avez résolu comme affiché ici. Maintenant + il est l'heure de marquer notre fichier comme résolu. Avec Git on le fait + avec git add - pour dire à Git que le fichier a été résolu + vous devez le mettre en attente.

 $ git status -s
@@ -503,55 +514,59 @@ 

 [master 8d585ea] Merge branch 'fix_readme'
-

And now we've successfully resolved our merge conflict and committed - the result.

- -

- In a nutshell you use git merge to combine another - branch context into your current branch. It automatically figures out - how to best combine the different snapshots into a new snapshot with the - unique work of both. -

- -
-
- -
-

- - docs   - book - - git log - show commit history of a branch -

- -
- -

So far we have been committing snapshots of your project and switching - between different isolated contexts, but what if we've forgotten how we've - got to where we are? Or what if we want to know how one branch differs - from another? Git provides a tool that shows you all the commit messages - that have lead up to the snapshot you are currently on, which is called - git log.

- -

To understand the log command, you have to understand what information - is stored when you run the git commit command to store a - snapshot. In addition to the manifest of files and commit message and - information about the person who committed it, Git also stores the commit - that you based this snapshot on. That is, if you clone a project, what was - the snapshot that you modified to get to the snapshot that you saved? This - is helpful to give context to how the project got to where it is and allows - Git to figure out who changed what. If Git has the snapshot you save and - the one you based it on, then it can automatically figure out what you - changed. The commit that a new commit was based on is called the "parent". -

- -

To see a chronological list of the parents of any branch, you can run - git log when you are in that branch. For example, if we run - git log in the Hello World project that we have been working - on in this section, we'll see all the commit messages that we've done. -

+

Et nous avons alors résolu avec succès notre conflit de fusion et validé + le résultat.

+ +

+ Pour résumer, vous utilisez git merge pour combiner + un autre contexte de branche dans votre branche courante. Cela va + automatiquement décider comment combiner au mieux les différents instantanés + en un nouvel instantané avec le travail unique à chacune des branches. +

+ +
+
+ +
+

+ + docs   + livre + + git log + afficher l'historique des validations d'une branche +

+ +
+ +

Jusqu'à présent nous avons validé des instantanés de votre projet et basculé + entre différents contextes isolés, mais comment faire si nous avons oublié + comment nous en sommes arrivés à un certain point? Ou si nous voulons + savoir à quel point une branche diffère d'une autre? Git fournit un outil + qui affiche tous les messages de validations qui vous ont amené jusqu'à + votre instantané courant, appelé git log.

+ +

Pour comprendre la commande d'historique, vous devez connaître quelles + informations sont stockées quand vous exécutez la commande + git commit pour enregistrer un instantané. En plus de la référence + des fichiers et du message de validation et des informations sur l'auteur + de la validation, Git stocke également la validation sur laquelle vous avez + basé votre instantané. C'est-à-dire que, si vous clonez un projet, quel + est l'instantané que vous avez modifié pour obtenir l'instantané que vous + enregistrez? C'est utile pour connaître le contexte dans quelle mesure + le projet est arrivé à cet état et permet à Git de savoir qui a changé quoi. + Si Git a l'instantané que vous avez sauvegardé et celui sur lequel vous vous + êtes basé, alors il peut automatiquement savoir ce que vous avez changé. + La validation sur laquelle une autre validation est basée est appelée le + "parent". +

+ +

Pour voir une liste chronologique des parents de n'importe quelle branche, + vous pouvez exécuter git log quand vous êtes dans cette branche. + Par exemple, si vous exécutez git log dans le projet Hello World + sur lequel nous avons travaillé dans cette section, nous allons voir tous les + messages des validations faites. + 

 $ git log
@@ -586,8 +601,8 @@ 

 ...
-

To see a more compact version of the same history, we can use the - --oneline option.

+

Pour voir une version plus compacte de ce même historique, nous pouvons + utiliser l'option --oneline.

 $ git log --oneline
@@ -600,14 +615,14 @@ 

 17f4acf first commit
-

What this is telling us is that this is the history of the development - of this project. If the commit messages are descriptive, this can inform - us as to what all changes have been applied or have influenced the current - state of the snapshot and thus what is in it.

+

Cela nous informe que c'est l'historique du développement de ce projet. + Si les messages de validations sont descriptifs, cela peut nous informer + sur les changements apportés ou qui ont influencé l'état de l'instantané + et donc ce qu'il contient.

-

We can also use it to see when the history was branched and merged with - the very helpful --graph option. Here is the same command - but with the topology graph turned on:

+

Nous pouvons aussi l'utiliser pour voir quand l'historique a connu des + branches ou fusions avec l'option très utile --graph. + Voici la même commande mais avec le graphe de topologie activé:

 $ git log --oneline --graph
@@ -624,18 +639,19 @@ 

 * 17f4acf first commit
-

Now we can more clearly see when effort diverged and then was merged - back together. This is very nice for seeing what has happened or what - changes are applied, but - it is also incredibly useful for managing your branches. Let's create a new - branch, do some work in it and then switch back and do some work in our - master branch, then see how the log command can help us figure - out what is happening on each.

+

Nous pouvons maintenant voir quand le travail a divergé et puis a + été fusionné. C'est très pratique pour voir ce qui s'est passé ou + quels changements ont été appliqués, mais c'est aussi extrêmement utile + pour gérer vos branches. Créons une nouvelle branche, effectuons + du travail dans celle-ci puis basculons et faisons du travail dans notre + branche master, puis voyons comment la commande log peut + nous aider à savoir ce qui se passe sur chacune d'elle.

-

First we'll create a new branch to add the Erlang programming language - Hello World example - we want to do this in a branch so that we don't - muddy up our stable branch with code that may not work for a while so we - can cleanly switch in and out of it.

+

D'abord nous allons créer une nouvelle branche pour ajouter le langage + Erlang comme exemple Hello World - nous désirons le faire dans une branche + afin de ne pas casser notre branche stable avec du code qui peut ne pas + fonctionner pendant un certain temps pour pouvoir basculer proprement + depuis ou vers cette branche.

 $ git checkout -b erlang
@@ -648,9 +664,10 @@ 

  create mode 100644 erlang_hw.erl
-

Since we're having fun playing in functional programming languages we - get caught up in it and also add a Haskell example program while still in - the branch named 'erlang'.

+

Étant donné que nous nous amusons beaucoup avec les langages de + programmation fonctionnelle nous restons dans notre lancée et ajoutons + également un programme exemple Haskell alors que nous sommes toujours + dans la branche 'erlang'.

 $ vim haskell.hs
@@ -661,10 +678,10 @@ 

  create mode 100644 haskell.hs
-

Finally, we decide that we want to change the class name of our Ruby - program back to the way it was. So, we can go back to the master branch - and change that and we decide to just commit it directly in the master - branch instead of creating another branch.

+

Enfin, nous décidons de remettre le nom de classe de notre programme Ruby + à ce qu'il était précédemment. Alors, nous pouvons retourner à la branche + master, le changer et décider de le valider directement dans la branche + master au lieu de créer une autre bracnhe.

 $ git checkout master
@@ -677,13 +694,16 @@ 

  1 files changed, 2 insertions(+), 2 deletions(-)
-

So, now say we don't work on the project for a while, we have other - things to do. When we come back we want to know what the 'erlang' branch - is all about and where we've left off on the master branch. Just by looking - at the branch name, we can't know that we made Haskell changes in there, but - using git log we easily can. If you give Git a branch name, - it will show you just the commits that are "reachable" in the history of - that branch, that is the commits that influenced the final snapshot.

+

Alors, maintenant imaginons que nous ne travaillons pas sur le projet + pendant quelques temps, nous avons autre chose à faire. Quand nous + y revenons nous voulons en savoir plus sur la branche 'erlang' et + où nous nous en sommes arrêtés sur la branche master. Juste en regardant + le nom de la branche, nous ne pouvons savoir que nous avons fait des modifications + en Haskell dans celle-ci, mais en utilisant git log nous pouvons + facilement le savoir. Si vous donnez à Git un nom de branche, cela va vous afficher + uniquement les validations qui sont "accessibles" dans l'historique de cette + branche, c'est-à-dire les validations qui ont influencé l'instantané + final.

 $ git log --oneline erlang
@@ -698,24 +718,25 @@ 

 17f4acf first commit
-

This way, it's pretty easy to see that we have Haskell code included in - the branch (highlighted in the output). What is even cooler is that we can - easily tell Git that we only are interested in the commits that are - reachable in one branch that are not reachable in another, in other words - which commits are unique to a branch in comparison to another. -

- -

- In this case if we are interested in merging in the 'erlang' branch we - want to see what commits are going to effect our snapshot when we do - that merge. The way we tell Git that is by putting a ^ in - front of the branch that we don't want to see. For instance, if we want - to see the commits that are in the 'erlang' branch that are not in the - 'master' branch, we can do erlang ^master, or vice versa. - Note that the Windows command-line treats ^ as a special - character, in which case you'll need to surround ^master - in quotes. -

+

De cette manière, c'est très simple de voir que nous avons du code Haskell + inclus dans la branche (mis en surbrillance dans la sortie). + Ce qui est encore plus cool est que nous pouvons facilement dire à Git + que nous sommes seulement intéressés par les validations qui sont + accessibles dans une branche mais non accessibles dans une autre, en d'autres + termes quelles validations sont uniques à une branche par rapport à une autre. +

+ +

+ Dans ce cas si nous sommes intéressés par la fusion de la branche 'erlang' + nous voulons savoir quelles validations vont affecter notre instantané + quand nous allons fusionner. Pour dire à Git de le faire on utilise + un ^ devant la branche que nous ne voulons voir. Par exemple, + si nous voulons voir les validations qui sont dans la branche 'erlang' + qui ne sont pas dans la branche 'master', on peut exécuter + erlang ^master, et vice-versa. Notez que la ligne de + commande Windows traite ^ comme un caractère spécial, + dans ce cas vous devrez mettre ^master entre guillemets. + 

 $ git log --oneline erlang ^master
@@ -725,59 +746,65 @@ 

 594f90b reverted to old class name
-

This gives us a nice, simple branch management tool. It allows us to - easily see what commits are unique to which branches so we know what - we're missing and what we would be merging in if we were to do a merge. -

- -

- In a nutshell you use git log to list out the commit - history or list of changes people have made that have lead to the snapshot - at the tip of the branch. This allows you to see how the project in that - context got to the state that it is currently in. -

- -
-
- -
-

- - docs   - book - - git tag - tag a point in history as important -

- -
- -

- If you get to a point that is important and you want to forever remember - that specific commit snapshot, you can tag it with git tag. - The tag command will basically put a permanent bookmark at - a specific commit so you can use it to compare to other commits in the - future. This is often done when you cut a release or ship something. -

- -

Let's say we want to release our Hello World project as version "1.0". - We can tag the last commit (HEAD) as "v1.0" by running - git tag -a v1.0. The -a means "make an annotated - tag", which allows you to add a tag message to it, which is what you almost - always want to do. Running this without the -a works too, but - it doesn't record when it was tagged, who tagged it, or let you add a tag - message. It's recommended you always create annotated tags.

+

Cela nous donne un outil de gestion de branche simple et pratique. + Cela nous permet de facilement voir quelles validations sont uniques + dans quelles branches afin de savoir ce qu'il nous manque et ce que + nous fusionnerions si nous faisions la fusion. +

+ +

+ Pour résumer, vous pouvez utiliser git log pour lister + l'historique de validation ou lister les changements faits par d'autres + qui ont mené l'instantané jusqu'à l'extrêmité de la branche. Cela vous permet + de voir comment le projet dans ce contexte est arrivé à l'état dans lequel il + est actuellement. +

+ +
+
+ +
+

+ + docs   + livre + + git tag + étiqueter un moment dans l'historique comme important +

+ +
+ +

+ Si vous arrivez à un moment qui est important et vous voulez définitivement + vous souvenir de cet instantané de validation spécifiquement, vous pouvez + l'étiqueter avec git tag. La commande tag + va basiquement mettre un signet permanent sur une validation spécifique + afin de pouvoir l'utiliser pour le comparer à d'autres validations dans + le futur. C'est souvent utilisé lorsque vous publier une version ou vous + déployez quelque chose. +

+ +

Disons que vous vouliez publier notre projet Hello World en tant + que version "1.0". Nous pouvons étiqueter la dernière validation + (HEAD) comme "v1.0" en exécutant git tag -a v1.0. + Le -a signifie "fait une étiquette annotée", qui permet + de lui ajouter un message d'étiquette, ce que vous voudrez quasiment + toujours faire. L'exécuter sans le -a fonctionne aussi, + mais cela n'enregistre pas quand cela a été étiqueté, qui l'a étiqueté, + ou ne vous laisse pas ajouter un message d'étiquette. Il est recommandé + de toujours créer des étiquettes annotées.

 $ git tag -a v1.0
-

When you run the git tag -a command, Git will open your editor - and have you write a tag message, just like you would write a commit - message.

+

Quand vous exécutez la ocmmande git tag -a, Git + va ouvrir votre éditeur et vous laisser écrire un message d'étiquette, + tout comme vous écrieriez un message de validation.

-

Now, notice when we run git log --decorate, we can see our - tag there.

+

Maintenant, notez que quand vous exécutez git log --decorate, + nous pouvons y voir nos étiquettes.

 $ git log --oneline --decorate --graph
@@ -795,15 +822,18 @@ 

 * 17f4acf first commit
-

If we do more commits, the tag will stay right at that commit, so we have - that specific snapshot tagged forever and can always compare future - snapshots to it.

+

Si nous faisons des validations supplémentaires, l'étiquette va rester + sur cette validation, nous avons alors cet instantané spécifique étiqueté + indéfiniment et nous pourrons toujours comparer de futurs instantanés + à celui-ci.

-

We don't have to tag the commit that we're on, however. If we forgot to - tag a commit that we released, we can retroactively tag it by running the - same command, but with the commit SHA at the end. For example, say we had - released commit 558151a (several commits back) but forgot to - tag it at the time. We can just tag it now:

+

Nous ne sommes pas limiter à étiqueter la validation sur laquelle nous sommes, + néanmoins. Si nous avons oublié d'étiqueter une validation que nous avons + publiée, nous pouvons rétroactivement l'étiqueter en exécutant la même + commande, mais avec le SHA de la validation à la fin. Par exemple, disons + que nous avons publié la validation 558151a (de plusieurs + validations en arrière) mais avons oublié de l'étiqueter à ce moment-là. + Nous pouvons l'étiqueter maintenant:

 $ git tag -a v0.9 558151a
@@ -822,12 +852,14 @@ 

 * 17f4acf first commit
-

Tags pointing to objects tracked from branch heads will be - automatically downloaded when you fetch from a remote - repository. However, tags that aren't reachable from branch heads - will be skipped. If you want to make sure all tags are always - included, you must include the --tags option. -

+

Les étiquettes pointant sur des objet suivis par les extrêmités + des branches seront automatiquement téléchargées quand vous utilisez + la commande fetch sur un dépôt distant. Néanmoins, + les étiquettes qui ne sont pas accessibles depuis les extrêmités + de sbranches seront ignorées. Si vous voulez être sûr que + toutes les étiquettes sont toujours incluses, + vous devez inclure l'option --tags. + 

 $ git fetch origin --tags
@@ -841,24 +873,25 @@ 

  * [new tag]         v1.1       -> v1.1
-

If you just want a single tag, use - git fetch <remote> tag <tag-name>. -

+

Si vous voulez juste une seule étiquette, utilisez + git fetch <dépôt-distant> tag <nom-étiquette>. +

-

By default, tags are not included when you push to - a remote repository. In order to explicitly update these you must - include the --tags option when using git push. -

+

Par défaut, les étiquettes ne sont pas incluses quand + vous utilisez la commande push vers un dépôt distant. + Pour explicitement les actualiser vous devez inclure l'option + --tags quand vous utilisez git push. +

-

- In a nutshell you use git tag to mark a - commit or point in your repo as important. This also allows - you to refer to that commit with a more memorable reference - than a SHA. -

+

+ Pou résumer, vous utilisez git tag pour marquer + une validation ou un point dans votre dépôt comme important. + Cela vous permet de faire référence à cette validation avec + quelque chose de plus mémorable qu'un SHA. +

-
-
+ + -

On to Sharing and Updating Projects »

+

Aller à Partager et Actualiser des Projets »

From f8a8420f32c7d0c39807aa5710981d39a3f0d53d Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 14 Jan 2016 21:38:10 +0100 Subject: [PATCH 13/22] FR: update layout --- _layouts/fr_reference.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html index 1f929a3..3da42b2 100755 --- a/_layouts/fr_reference.html +++ b/_layouts/fr_reference.html @@ -43,7 +43,7 @@

Récupérer et Créer des Projets

-

Instantanés de base

+

Instantanés de Base

-

Partager et Mettre à Jour des Projets

+

Partager et Actualiser des Projets

  • remote
  • fetch, pull
    • From 5ec0c6b7311849b810b6480891ab33dd0bd19764 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Fri, 22 Jan 2016 12:00:17 +0100 Subject: [PATCH 14/22] FR: final touches for 1st draft --- _layouts/fr_reference.html | 4 ++-- fr/basic/index.html | 4 ++-- fr/branching/index.html | 4 ++-- fr/creating/index.html | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html index 3da42b2..035554d 100755 --- a/_layouts/fr_reference.html +++ b/_layouts/fr_reference.html @@ -43,7 +43,7 @@

    Récupérer et Créer des Projets

-

Instantanés de Base

+

Bases des Instantanés

-

Branche et Fusion

+

Branches et Fusions

  • branch
  • checkout
    • diff --git a/fr/basic/index.html b/fr/basic/index.html index 59556aa..c1edcbd 100644 --- a/fr/basic/index.html +++ b/fr/basic/index.html @@ -7,7 +7,7 @@

    livre - Instantanés de Base + Bases des Instantanés

    @@ -992,4 +992,4 @@

-

Aller à Branche et Fusion »

+

Aller à Branches et Fusions »

diff --git a/fr/branching/index.html b/fr/branching/index.html index 47a91fd..646c1f7 100644 --- a/fr/branching/index.html +++ b/fr/branching/index.html @@ -40,7 +40,7 @@

docs   - livre + livre git branch lister, créer et gérer les contextes de travail @@ -73,7 +73,7 @@

Sans argument, git branch va lister vos branches locales. La branche courante sur laquelle vous êtes sera précédée d'un astérisque et si vous avez - la colorisation activée, + la colorisation activée, la branche courante sera affichée en vert.

diff --git a/fr/creating/index.html b/fr/creating/index.html index a981780..8129eb5 100644 --- a/fr/creating/index.html +++ b/fr/creating/index.html @@ -142,4 +142,4 @@

-

Aller à Instantanés de Base »

+

Aller à Bases des Instantanés »

From e5b6f2224567e614fe6efa0de5c9d9dc3297d1fc Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 25 Feb 2016 18:30:43 +0100 Subject: [PATCH 15/22] FR: Fixes reference README about --- _layouts/fr_reference.html | 8 ++++---- fr/README.md | 2 +- fr/about.html | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html index 035554d..f707f32 100755 --- a/_layouts/fr_reference.html +++ b/_layouts/fr_reference.html @@ -35,7 +35,7 @@
-

Récupérer et Créer des Projets

+

Obtention et Création des Projets

-

Bases des Instantanés

+

Capture d’Instantané Basique

-

Branches et Fusions

+

Création de Branches et Fusion

-

Partager et Actualiser des Projets

+

Partage et Mise à Jour de Projets

  • remote
  • fetch, pull
    • diff --git a/fr/README.md b/fr/README.md index eff1680..7ea0b58 100644 --- a/fr/README.md +++ b/fr/README.md @@ -15,4 +15,4 @@ participation est la bienvenue. Les traductions choisies pour les termes spécifiques à Git se basent sur [les références](https://github.com/progit/progit2-fr#références-pour-la-traduction) -de l'effort de traduction en français de la deuxième édition du livre Progit. +de l'effort de traduction en français de la deuxième édition du livre Pro Git. diff --git a/fr/about.html b/fr/about.html index 5f29750..a294fcd 100644 --- a/fr/about.html +++ b/fr/about.html @@ -2,7 +2,7 @@ layout: fr_reference ---
    -

    Qui est à l'origine de ce site?

    +

    Qui est à l'origine de ce site ?


    -

    Le site Référence Git a été réalisé par l'équipe Github.

    +

    Le site Référence Git a été réalisé par l'équipe GitHub.

    From 822bcb3a49d915f8ee8496db9a7de2d2a3750cde Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Thu, 25 Feb 2016 23:34:53 +0100 Subject: [PATCH 16/22] Fixing a lot basic.html, and little other files --- fr/basic/index.html | 260 ++++++++++++++++++++-------------------- fr/branching/index.html | 130 ++++++++++---------- fr/creating/index.html | 20 ++-- fr/index.html | 21 ++-- fr/inspect/index.html | 74 ++++++------ fr/remotes/index.html | 82 ++++++------- 6 files changed, 297 insertions(+), 290 deletions(-) diff --git a/fr/basic/index.html b/fr/basic/index.html index c1edcbd..271f38f 100644 --- a/fr/basic/index.html +++ b/fr/basic/index.html @@ -7,7 +7,7 @@

    livre - Bases des Instantanés + Capture d’Instantané Basique

    @@ -18,7 +18,7 @@

    - Un concept important ici est que Git dispose d'un 'index', qui se comporte + Un concept important ici est que Git dispose d'un « index », qui se comporte comme une sorte de zone d'attente pour votre instantané. Cela vous permet d'accumuler des séries bien ordonnées d'instantanés à partir de fichiers modifiés de votre dossier de travail, plutôt que de valider toutes les modifications de @@ -27,10 +27,10 @@

    Pour résumer, vous utiliserez git add pour - commencer à suivre de nouveaux fichiers et aussi pour mettre en attente + commencer à suivre de nouveaux fichiers et aussi pour préparer la capture des modifications apportées à des fichiers déjà suivis, puis git status et git diff pour voir ce qui a été - modifié et mis en attente et finalement git commit pour + modifié et préparé pour la capture et finalement git commit pour enregistrer un instantané dans votre historique. Ce sera le flux de travail basique que vous utiliserez la plupart du temps.

    @@ -45,7 +45,7 @@

    livre git add - ajouter le contenu d'un fichier dans la zone d'attente + ajoute le contenu d'un fichier dans la zone d'attente

    @@ -53,13 +53,14 @@

    Dans Git, vous devez ajouter le contenu d'un fichier dans la zone d'attente avant de pouvoir le valider. Si c'est un nouveau fichier, vous pouvez exécuter git add pour l'ajouter au préalable à la zone d'attente, - mais même si le fichier est déjà "suivi" - ie, il fait partie de votre dernière - validation - vous devez toujours lancer git add pour ajouter de - nouvelles modifications à votre zone d'attente. Voyons quelques exemples. + mais même si le fichier est déjà « suivi »—en d'autres termes, il fait partie + de votre dernière validation—vous devez toujours lancer git add + pour ajouter de nouvelles modifications à votre zone d'attente. + Voyons quelques exemples.

    Revenons à notre exemple Hello World, une fois initialisé notre projet, - nous commencerions à présent à y ajouter des fichiers et le ferions avec + nous commencerions alors à y ajouter des fichiers et le ferions avec git add. Nous pouvons utiliser git status pour afficher l'état de notre projet.

    @@ -87,18 +88,19 @@

    Il est aussi courant d'ajouter récursivement tous les fichiers d'un nouveau projet - en indiquant le dossier de travail courant comme suit: git add .. + en indiquant le dossier de travail courant comme suit : git add .. Sachant que Git va ajouter récursivement tous les fichiers dans un dossier que vous lui donnez, si vous lui donnez le répertoire de travail courant, il va simplement faire le suivi de chaque fichier qui s'y trouve. Dans ce cas, la commande git add . aurait donné la même chose que - git add README hello.rb, et par la même également + git add README hello.rb, et d'ailleurs également git add *, mais c'est seulement parce-que nous n'avons pas de sous-dossiers, et que * ne pourrait pas les parcourir récursivement.

    -

    OK, maintenant nous éditons un de ces fichiers et exécutons git status - à nouveau, et nous allons observer un comportement étrange.

    +

    OK, à présent si nous éditons un de ces fichiers et exécutons + git status à nouveau, nous allons observer + un comportement étrange.

     $ vim README
 $ git status -s
@@ -106,26 +108,28 @@ 
    
 A  hello.rb
    -

    Le statut 'AM' signifie que le fichier a été modifié depuis la dernière +

    Le statut « AM » signifie que le fichier a été modifié depuis la dernière fois qu'il a été ajouté. Cela signifie que si nous validons notre instantané tout de suite, nous enregistrerions la version du fichier lors de l'exécution - précédente de git add, pas la version actuelle. Git n'assume pas - que le version dans sa version actuelle est nécessairement celle que vous - voulez prendre en instantané - vous devez le préciser à Git avec la commande + précédente de git add, pas la version actuelle. Git ne suppose + pas que le fichier dans sa version actuelle est nécessairement celui que vous + voulez prendre en instantané—vous devez le préciser à Git avec la commande git add.

    Pour résumer, vous exécutez git add sur un fichier lorsque vous voulez inclure - toute modification apportée au fichier dnas le prochain instantané à valider. - Toute modification qui ne sera pas ajoutée ne sera pas incluse à l'instantané - - cela signifie que vous pouvez créer vos instantanés de manière plus fine - que la plupart des systèmes de gestion de révisions.

    + toute modification apportée au fichier dans le prochain instantané. + Toute modification qui ne sera pas ajoutée ne sera pas incluse dans + l'instantané—cela signifie que vous pouvez créer vos instantanés + de manière plus fine que dans la plupart des systèmes de gestion + de versions.

    -

    Pour un exemple concret de la flexibilité de mise en attente une à une - de seulement certaines parties de fichiers modifiés, regardez l'option - '-p' de git add du livre Pro Git.

    +

    Pour voir cette flexibilité de capture en action dans un exemple + particulièrement intéressant qui ne capture que certaines des + modifications apportées à un même fichier, voyez l’option + « -p » de git add du livre Pro Git.

    @@ -139,7 +143,7 @@

    livre git status - voir le statut de vos fichiers du dossier courant et de la zone d'attente + affiche le statut de vos fichiers dans le dossier de travail et dans la zone d'attente

    @@ -149,7 +153,7 @@

    l'option -s l'affichage de la sortie sera réduit. Sans cette option la commande git status vous donnera plus de contexte et d'indications. Voici le même affichage de la sortie du statut avec et sans le -s. - La sortie courte ressemble à ça: + La sortie courte ressemble à ça : 

    @@ -158,7 +162,7 @@ 
    
 A  hello.rb
    - Alors que le même statut avec la sortie longue ressemble à ça: + Alors que le même statut avec la sortie longue ressemble à ça : 
     $ git status
@@ -167,7 +171,7 @@ 
    
 # Initial commit
 #
 # Changes to be committed:
-#   (use "git rm --cached <file>..." to unstage)
+#   (use "git rm --staged <file>..." to unstage)
 #
 # new file:   README
 # new file:   hello.rb
@@ -180,9 +184,9 @@ 
    
 #
    -

    Vous pouvez rapidement vous apercevoir comme l'affichage court de la sortie - est beaucoup plus compact, mais la sortie longue a d'utiles informations et - indications dont vous pourriez avoir besoin. +

    Vous pouvez facilement constater que l'affichage court de la sortie + est beaucoup plus compact, mais la sortie longue a des informations et + indications utiles dont vous pourriez avoir besoin par la suite.

    Git vous dira également quels fichiers ont été effacés @@ -193,11 +197,11 @@

    D hello.rb - Vous pouvez voir qu'il y a deux colonnes dans la sortie courte du statut. + Remarquez qu'il y a deux colonnes dans la sortie courte du statut. La première colonne est pour la zone d'attente, la seconde est pour le dossier de travail. Par exemple, si vous avez le fichier README en zone d'attente et qu'ensuite vous le modifiez sans exécuter git add - une seconde fois, vous verrez ceci: + une seconde fois, vous verrez ceci : 
     $ git status -s
@@ -223,25 +227,26 @@ 
    
           livre
         
         git diff
-        afficher les modifications indexées et non indexées
+        affiche les modifications indexées et non indexées
       
    
 
       
    
         
    Il y a deux utilisations principales de la commande git diff.
-          Une utilisation que nous allons décrire ici, l'autre sera décrite plus loin
+          Nous allons décrire la première ici, l'autre sera décrite plus loin
           dans la section "Inspection et Comparaison".
-          La manière dont nous allons l'utiliser ici est de décrire les changements
-          qui sont indexés, ou ceux modifiés sur disque mais non indexés.
    
+          Pour le moment, nous allons l’utiliser pour visualiser les modifications
+          déjà indexées pour le prochain instantané, et celles qui ne sont encore
+          présentes que dans notre dossier de travail.
    
 
         
    
           git diff
-          Afficher les modifications non indexées
+          affiche les modifications non indexées
         
    
 
         
    Sans aucun argument, un simple git diff vous affichera au
-          format diff unifié (un correctif) ce que vous avez changé comme code ou contenu
-          de votre projet depuis la dernière vaildation qui n'est pas encore indexé ou le
-          prochain instantané à valider.
+          format diff unifié (un correctif) ce que vous avez changé comme code ou
+          contenu de votre projet depuis la dernière mise en zone d'attente ou,
+          à défaut, le dernier instantané.
         
    
 
 
    @@ -266,21 +271,21 @@ 
    
 
         
    Là où git status vous affichera quels fichiers ont changé
           et/ou a été indexé depuis votre dernière validation, git diff
-          va vous montrer quels sont concrétement ces changements, ligne par ligne.
-          C'est généralement une bonne commande à la suite d'un git status.
+          va vous montrer quels sont concrètement ces changements, ligne par ligne.
+          C'est généralement une commande utile à la suite d'un git status.
         
    
 
-        
    
-          git diff --cached
-          montrer les changements indexés
+        
    
+          git diff --staged
+          affiche les modifications indexées
         
    
 
-        
    La commande git diff --cached  montrera le contenu indexé.
-          C'est-à-dire, cela vous affichera les changements qui seront inclus
+        
    La commande git diff --staged  montrera le contenu indexé.
+          C'est-à-dire, elle vous affichera les changements qui seront inclus
           dans le prochain instantané validé. Ainsi, si vous deviez indexer
           les modifications de hello.rb de l'exemple précédent,
-          git diff tel quel ne vous affichera rien car il ne devra
-          vous afficher que ce qui n'a pas encore été indexé.
+          git diff tel quel ne vous affichera rien car il
+          vous afficherait que ce qui n'a pas encore été indexé.
         
    
 
 
    @@ -294,14 +299,14 @@ 
    
 
    
 
         
    Si vous voulez voir les changements indexés, vous pouvez exécuter
-          git diff --cached à la place.
    
+          git diff --staged à la place.
    
 
 
     $ git status -s
 M  hello.rb
 $ git diff
 $ 
-$ git diff --cached
+$ git diff --staged
 diff --git a/hello.rb b/hello.rb
 index d62ac43..8d15d50 100644
 --- a/hello.rb
@@ -319,16 +324,16 @@ 
    
 
           
    
             git diff HEAD
-            afficher toutes les modifications indexées ou non indexéess
+            affiche toutes les modifications, indexées ou non
           
    
 
           
    Si vous voulez voir aussi bien les modifications indexées que non indexées ensemble,
-            vous pouvez exécuter git diff HEAD - cela veut simplement
-            dire que vous voulez voir les différences entre votre répertoire de travail et la
-            dernière validation, ignorant la zone d'index. Si nous apportons une autre modification
-            au fichier hello.rb alors nous aurons des modifications indexées et certaines
-            modifications non indexées. Voici ce que chacune des trois commandes diff
-            vous affichera:
    
+            vous pouvez exécuter git diff HEAD—cela veut simplement
+            dire que vous voulez voir les différences entre votre répertoire de travail et le
+            dernier instantané, ignorant la zone d'index. Si nous apportons une autre modification
+            au fichier hello.rb, alors nous aurons des modifications indexées et
+            d'autres modifications non indexées. Voici ce que chacune des trois commandes
+            diff vous affichera :
    
 
     $ vim hello.rb 
 $ git diff
@@ -345,7 +350,7 @@ 
    
    end
 
  end
-$ git diff --cached
+$ git diff --staged
 diff --git a/hello.rb b/hello.rb
 index 2aabb6e..4f40006 100644
 --- a/hello.rb
@@ -378,14 +383,14 @@ 
    
 
             
    
               git diff --stat
-              afficher un résumé des changements au lieu de toutes les modifications
+              affiche un résumé des modifications au lieu de leur détail
             
    
 
             
    Si nous ne voulons pas de l'affichage complet des modifications,
-              mais plus que la sortie de git status, on peut utiliser
-              l'option --stat, qui nous donnera à la place un résumé des
-              changements. Voici le même exemple que précédemment, mais en utilisant
-              l'option --stat à la place.
+              mais souhaitons davantage que la sortie de git status,
+              on peut utiliser l'option --stat, qui nous donnera
+              à la place un résumé. Voici le même exemple que
+              précédemment, mais en utilisant l'option --stat.
             
    
 
 
    @@ -394,7 +399,7 @@ 
    
 $ git diff --stat
  hello.rb |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
-$ git diff --cached --stat
+$ git diff --staged --stat
  hello.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 $ git diff HEAD --stat
@@ -403,17 +408,17 @@ 
    
 
    
 
             
    
-              Vous pouvez aussi donner un chemin de fichier à la fin de n'importe laquelle
-              de ces options pour réduire la sortie de diff à un fichier ou dossier
-              spécifique.
+              Vous pouvez aussi ajouter des chemins à la fin de n’importe laquelle
+              de ces variantes pour réduire la sortie de diff
+              à des fichiers ou dossiers spécifiques.
             
    
 
 
             
    
               Pour résumer,
               vous exécutez git diff pour voir les détails de la commande
-              git status - dans quelle mesure les fichiers ont été modifiés
-              ou indexés ligne par ligne.
+              git status : dans quelle mesure les fichiers ont été
+              modifiés ou indexés, ligne par ligne.
             
    
 
 
@@ -427,7 +432,7 @@ 
    
               livre
             
             git commit
-            valider un instantané de la zone d'index
+            valide un instantané à partir de la zone d'index
           
    
 
           
    
@@ -435,8 +440,8 @@ 
    
             
    Maintenant que vous avez indexé le contenu dont vous voulez faire un instantané
               avec la commande git add, vous exécutez git commit
               pour enregistrer l'instantané.
-              Git enregistre le nom et l'adresse email de chacune de vos validations,
-              il faut donc commencer par indiquer à Git à quoi ils correspondent.
+              Git enregistre vos nom et adresse email, il faut donc commencer par indiquer
+              leurs valeurs à Git.
             
    
 
 
    @@ -460,10 +465,10 @@ 
    
 
    
 
             
    Nous avons désormais enregistré un instantané. Si nous exécutons
-              git status à nouveau, nous allons voir que "la copie
-              de travail est propre", ce qui signifie que nous n'avons fait aucune
-              modification depuis notre dernière validation - il n'y a aucun 
-              instantané en attente.
    
+              git status à nouveau, nous allons voir que « la copie
+              de travail est propre », ce qui signifie que nous n'avons fait aucune
+              modification depuis notre dernière validation—il n'y a aucun
+              travail en attente.
    
 
 
     $ git status
@@ -475,7 +480,7 @@ 
    
                 d'ouvrir un éditeur de texte pour écrire votre message de validation.
                 Dans vim, qui est utilisé par défaut à moins que vous
                 n'ayez configuré une alternative à utiliser, votre écran ressemblera
-                vraisemblablement à cela:
+                vraisemblablement à cela :
               
    
 
 
    @@ -494,13 +499,13 @@ 
    
 
    
 
               
    À ce stade vous ajoutez votre message de validation final au tout
-                début du document. Toute ligne qui commence par '#' sera ignorée - Git
+                début du document. Toute ligne qui commence par « # » sera ignorée—Git
                 va vous y ajouter la sortie de la commande git status
                 pour vous rappeler ce que vous avez modifié et mis en attente.
    
 
               
    En règle générale, il est très important d'écrire de bons messages de validation.
                 Pour des projets libres, par convention vous écrirez votre message
-                plus ou moins dans ce format:
    
+                plus ou moins dans ce format :
    
 
 
     Un court (50 caractères ou moins) résumé des modifications
@@ -509,7 +514,7 @@ 
    
 sur environ 72 caractères. Dans certains cas, la première ligne est
 traitée comme le sujet d'un email et le reste du texte comme le corps.
 Le saut de ligne entre le résumé et le corps est très important
-(à moins que vous omettiez complétement le corps); certains outils git
+(à moins que vous omettiez complétement le corps) ; certains outils git
 peuvent mal fonctionner si vous les mettez l'un après l'autre.
 
 Les paragraphes supplémentaires viennent après d'autres sauts de ligne.
@@ -517,7 +522,7 @@ 
    
  - Les listes à puces sont possibles, aussi
 
  - Typiquement, un tiret ou une astérisque est utilisée comme puce,
-   précédée d'un seul espace, séparées par des sauts de ligne, mais
+   précédée d'une seule espace, séparées par des sauts de ligne, mais
    différentes conventions existent
 
 # Please enter the commit message for your changes. Lines starting
@@ -535,7 +540,7 @@ 
    
 
    
 
                 
    
-                  Le message de validation est très important. Étant donné qu'une grande
+                  Le message d'instantané est très important. Étant donné qu'une grande
                   part de la puissance de Git est cette souplesse dans la création attentionnée
                   des validations en local pour les partager ensuite, c'est très utile de
                   pouvoir écrire trois ou quatre validations sur des modifications indépendantes
@@ -548,16 +553,16 @@ 
    
 
                 
    
                   git commit -a
-                  mettre automatiquement en attente toutes modifications suivies et modifiées avant la validation
+                  indexe automatiquement, avant la validation, toutes les modifications aux fichiers suivis
                 
    
 
                 
    Si l'étape git add du flux de travail vous paraît lourde,
                   Git vous permet de sauter celle-ci avec l'option -a.
-                  Cela va basiquement dire à Git d'exécuter git add sur
-                  chaque fichier qui est "suivi" - c'est-à-dire, chaque fichier qui fait
-                  partie de votre dernière validation et qui a été modifiée. Cela vous permet
+                  Cela va simplement dire à Git d'exécuter git add sur
+                  chaque fichier qui est « suivi »—c'est-à-dire, chaque fichier qui fait
+                  partie de votre dernière validation et qui a été modifié. Cela vous permet
                   d'avoir un flux de travail plus proche de celui de Subversion si vous le voulez,
-                  éditez simplement vos fichiers puis exécutez git commit -a
+                  en éditant simplement vos fichiers puis en exécutant git commit -a
                   pour réaliser un instantané de tout ce qui a changé. Vous aurez toujours à
                   exécuter git add pour commencer à suivre de nouveaux fichiers,
                   néanmoins, tout comme avec Subversion.
@@ -581,20 +586,20 @@ 
    
  1 files changed, 2 insertions(+), 1 deletions(-)
 
    
 
-                
    Notez que si vous ne placez en attente aucune modification et que vous exécutez
+                
    Notez que si vous n'indexez aucune modification et que vous exécutez
                   git commit, Git va simplement vous retourner la sortie de la
-                  commande git status, pour vous rappeler que rien n'a été mis en attente.
-                  La partie importante de ce message a été mise en valeur, et signifie que
+                  commande git status, pour vous rappeler que rien n'a été indexé.
+                  La partie importante de ce message a été mise en exergue, et signifie que
                   rien n'a été ajouté pour validation. Si vous utilisez -a,
                   cela va tout ajouter et valider en même temps.
                 
    
 
                 
    Cela va vous permettre de finaliser le flux de travail complet des
-                  instantanés - vous faites des modifications à vos fichiers, vous utilisez
+                  instantanés—vous faites des modifications à vos fichiers, vous utilisez
                   ensuite git add pour mettre en attente les fichiers que vous avez
                   modifiés, git status et git diff pour voir
                   ce que vous avez modifié, et finalement git commit
-                  pour finalement enregistrer définitivement votre instantané.
    
+                  pour enregistrer définitivement votre instantané.
    
 
                 
    
                   Pour résumer,
@@ -613,30 +618,30 @@ 
    
                   livre
                 
                 git reset
-                annuler des changements et validations
+                annule des changements et instantanés
               
    
 
               
    
                 
    git reset est probablement la commande source de la plus
-                  grande confusion jamais écrite, mais elle peut être extrémement utile
+                  grande confusion jamais écrite, mais elle peut être extrêmement utile
                   une fois qu'on en a saisi le principe. Il y a trois invocations spécifiques
                   de cette commande qui sont communément utilisées.
                 
    
 
                 
    
                   git reset HEAD
-                  retirer des fichiers de l'index et ré-initialiser le pointeur vers HEAD
+                  retire des fichiers de l'index et ré-initialise le pointeur vers HEAD
                 
    
 
                 
    Pour commencer, vous pouvez l'utiliser pour enlever quelque chose de placé
                   accidentellement dans la zone d'attente. Imaginons que vous avez modifié
                   deux fichiers et que vous vouliez les enregistrer dans deux validations différentes.
                   Vous devriez faire une mise en attente et validation, puis mettre en attente et valider
-                  l'autre. Si vous avez accidentellement mis les deux en attente, comme en
-                  dé-mettre en attente une? Vous le faites avec
+                  l'autre. Si vous avez accidentellement mis les deux en attente, comment
+                  dé-mettre en attente une ? Vous le faites avec
                   git reset HEAD -- fichier.  Techniquement vous n'avez pas à ajouter
-                  le -- - il est utilisé pour dire à Git où se termine la liste des options
-                  et où commence la liste des chemins de fichiers, mais il est probablement sûr
+                  le --—il est utilisé pour dire à Git où se termine la liste des options
+                  et où commence la liste des chemins, mais c'est probablement une bonne idée
                   de prendre l'habitude de l'utiliser pour séparer les options des chemins
                   même si vous n'en avez pas besoin.
                 
    
@@ -661,17 +666,17 @@ 
    
  M hello.rb
 
    
 
-                  
    Maintenant vous pouvez exécuter git commit qui va juste
+                  
    Vous pouvez alors exécuter git commit qui va juste
                     enregistrer les modifications du fichier README, pas celles
                     du fichier hello.rb.
                   
    
 
                   
    
-                    Si vous êtes curieux, ce qui est fait concrétement ici est de rembobiner
-                    la somme de contrôle de l'entrée de ce fichier dans l'"index" à ce qu'il
+                    Si vous êtes curieux, ce Git fait concrètement ici est de recaler
+                    la somme de contrôle de l'entrée de ce fichier dans l'« index » à ce qu'elle
                     était dans la dernière validation. Vu que  git add crée une somme
                     de contrôle d'un fichier et l'ajoute à l'"index", git reset HEAD
-                    écrase cela avec ce qui l'était précédemment, pour ainsi effectivement le sortir
+                    écrase cela avec sa valeur précédente, pour ainsi effectivement le sortir
                     de la zone d'attente.
                   
    
 
@@ -688,7 +693,7 @@ 
    
                     dans la sortie de la commande normale git status.
                     Par exemple, si vous exécutez git status sans le
                     -s quand vous avez des fichiers en attente, il vous
-                    dira comment les en sortir:
    
+                    dira comment les en sortir :
    
 
 
     $ git status
@@ -707,15 +712,15 @@ 
    
 
                     
    
                       git reset --soft
-                      déplacer HEAD vers une référence spécifique de validation, l'index et la zone d'attente restant inchangés
+                      déplace HEAD vers une référence spécifique de validation, la zone d'attente restant inchangée
                     
    
 
                     
    La première chose que fait git reset est d'annuler
                       la dernière validation et remettre les fichiers dans la zone d'attente.
-                      Si vous incluez le drapeau --soft il s'en arrête là.
+                      Si vous incluez le drapeau --soft il s'arrête là.
                       Par exemple, si vous exécutez git reset --soft HEAD~
                       (le parent de HEAD) la dernière validation sera annulée et les fichiers
-                      modifiés seront remis dans la zone d'attente à nouveau.
    
+                      modifiés seront mis à nouveau dans la zone d'attente.
    
 
 
     $ git status -s
@@ -731,21 +736,22 @@ 
    
 M  hello.rb
 
    
 
-                      
    Cela fait basiquement la même chose que
+                      
    Ça fait en gros la même chose que
                         git commit --amend, vous permettant de continuer
                         à travailler avant que vous n'ajoutiez les modifications de fichiers
                         dans la même validation.
    
 
                       
    
                         git reset --hard
-                        sortir de la zone d'attente ET annuler les modifications du dossier de travail depuis la dernière validation
+                        annule toute modification, indexée ou encore dans la copie de travail, survenue depuis le dernier commit
                       
    
 
-                      
    La troisième option est --hard pour rendre votre dossier de
-                        travail identique à l'index, sortir les fichiers de la zone d'attente et
-                        annuler toute modification faite depuis la dernière validation.
-                        C'est l'option la plus dangereuse et non sûre pour votre dossier de
-                        travail. Toute modification non présente dans l'index ou une validation sera perdue.
    
+                      
    La troisième option est --hard. Cette variante annule toute
+                        modification indexée ou présente dans la copie de travail. En d'autres
+                        termes, elle ramène les deux à leur état du dernier commit en date.
+                        C'est la variante la plus dangereuse, car elle peut passer à la trappe
+                        des modifications de votre copie de travail. Toute modification
+                        non validée au préalable sera perdue.
    
 
 
     $ git status
@@ -770,8 +776,8 @@ 
    
 
                         
    Dans l'exemple ci-dessus, alors que nous avions toutes les modifications
                           prêtes à être validées et ajoutées, un git reset --hard
-                          les a complétement supprimées. Le dossier de travail et la zone d'attente
-                          sont ré-initialisés à l'extrémité de la branche courante ou HEAD.
    
+                          les a complètement supprimées. Le dossier de travail et la zone d'attente
+                          sont ré-initialisés à la pointe de la branche courante ou HEAD.
    
 
                         
    Vous pouvez remplacer HEAD avec le SHA-1 d'une validation
                           ou une autre référence vers un parent pour ré-initialiser en un point
@@ -811,11 +817,11 @@ 
    
                         
    Par défaut, un git rm file va supprimer complètement
                           le fichier de la zone d'attente et aussi de votre disque (le dossier
                           de travail). Pour laisser le fichier dans le dossier de travail,
-                          vous pouvez utiliser git rm --cached.
    
+                          vous pouvez utiliser git rm --staged.
    
 
                         
    
                           git mv
-                          git rm --cached orig; mv original nouveau; git add nouveau
+                          git rm --staged orig; mv original nouveau; git add nouveau
                         
    
 
                         
    
@@ -825,8 +831,8 @@ 
    
                           en comparant les instantanés. Si un fichier a été supprimé d'un instantané
                           et un autre fichier a été ajouté au suivant et leur contenu est similaire,
                           Git décidera que c'est sûrement un renommage. Alors, bien que la commande
-                          git mv existe, elle est superflue - tout ce qu'elle fait est un
-                          git rm --cached, renomme le fichier sur le disque, puis exécute un
+                          git mv existe, elle est superflue—tout ce qu'elle fait est un
+                          git rm --staged, renomme le fichier sur le disque, puis exécute un
                           git add sur le nouveau fichier. Vous n'avez pas vraiment besoin
                           de l'utiliser, mais si cela vous semble plus simple, n'hésitez pas.
                         
    
@@ -866,7 +872,7 @@ 
    
 
                         
    
                           git stash
-                          réserver les modifications courantes sur la pile
+                          réserve les modifications courantes sur la pile
                         
    
 
                         
    Réserver prend l'état courant de votre dossier de travail et de l'index,
@@ -893,7 +899,7 @@ 
    
 
                           
    
                             git stash list
-                            voir les réservations présentes sur la pile
+                            affiche les réservations présentes sur la pile
                           
    
 
                           
    C'est utile de savoir ce que vous avez stocké sur la pile et c'est la où
@@ -926,7 +932,7 @@ 
    
 
                           
    
                             git stash apply
-                            récupérer l'élément depuis la liste de la pile et l'appliquer au dossier de travail courant
+                            récupére l'élément depuis la liste de la pile et l'appliquer au dossier de travail courant
                           
    
 
                           
    Quand vous êtes prêt à continuer là où vous en êtiez, exécutez la
@@ -959,7 +965,7 @@ 
    
 
                           
    
                             git stash drop
-                            supprimer un élément de la liste de la pile
+                            supprime un élément de la liste de la pile
                           
    
 
                           
    Quand vous en avez fini avec un élément réservé et/ou vous voulez le
@@ -992,4 +998,4 @@

    -

    Aller à Branches et Fusions »

    +

    Aller à Création de Branches et Fusion »

    diff --git a/fr/branching/index.html b/fr/branching/index.html index 646c1f7..b689d47 100644 --- a/fr/branching/index.html +++ b/fr/branching/index.html @@ -7,7 +7,7 @@

    livre - Branches et Fusions + Création de Branches et Fusion

    Les branches sont une des nombreuses fonctionnalités intéressantes de Git. @@ -43,7 +43,7 @@

    livre git branch - lister, créer et gérer les contextes de travail + liste, crée et gére les contextes de travail


    @@ -54,20 +54,20 @@

    livre git checkout - basculer vers un nouveau contexte de branche + bascule vers un nouveau contexte de branche

    La commande git branch est un outil de gestion général des branches de Git et peut faire de nombreuses choses différentes. Nous allons aborder - celles de base que vous utiliserez le plus souvent - lister les branches, créer + celles de base que vous utiliserez le plus souvent—lister les branches, créer des branches et supprimer des branches. Nous allons aussi aborder git checkout ici qui vous permet de basculer entre branches.

    git branch - lister vos branches disponibles + liste vos branches disponibles

    Sans argument, git branch va lister vos branches locales. @@ -82,16 +82,16 @@

    * master -

    Cela signifie que nous avons une branche 'master' et que nous sommes sur +

    Cela signifie que nous avons une branche « master » et que nous sommes sur celle-ci. Quand vous exécutez git init cela va automatiquement - créer une branche 'master' pour vous par défaut, néanmoins il n'y a rien - de particulier dans ce nom - vous n'avez pas en fait à avoir de branche 'master' + créer une branche « master » pour vous par défaut, néanmoins il n'y a rien + de particulier dans ce nom—vous n'avez pas en fait à avoir de branche « master » mais étant donné qu'elle est créée par défaut, la plupart des projets en ont une.

    git branch (nombranche) - créer une nouvelle branche + crée une nouvelle branche

    Commençons par créer une nouvelle branche puis basculons vers celle-ci. @@ -107,10 +107,10 @@

    Vous pouvez voir que nous avons une nouvelle branche. Quand vous créez une branche de cette manière cela crée la branche basée sur votre dernière validation - donc si à ce stade vous créez des validations puis basculez vers 'testing', + donc si à ce stade vous créez des validations puis basculez vers « testing », vous rétablirez le contexte de votre dossier de travail à celui où il était - lorsque la branche a été créée initialement - Vous pouvez penser à cela comme - un signet qui indique où vous en êtes. Voyons cela en action - nous utilisons + lorsque la branche a été créée initialement—Vous pouvez penser à cela comme + un signet qui indique où vous en êtes. Voyons cela en action—nous utilisons git checkout (branche) pour changer de branche courante.

    @@ -133,9 +133,9 @@

    README hello.rb -

    Nous voyons que lorsque nous basculons vers la branche 'testing', +

    Nous voyons que lorsque nous basculons vers la branche « testing », nos nouveaux fichiers ont disparu. Nous pouvons retourner vers la - branche 'master' et les voir ré-apparaître.

    + branche « master » et les voir ré-apparaître.

     $ ls
@@ -148,7 +148,7 @@ 
    
 
       
    
         git branch -v
-        voir la dernière validation de chaque branche
+        affiche la dernière validation de chaque branche
       
    
 
       
    Si nous voulons voir les dernières validations de chaque branche
@@ -163,17 +163,17 @@ 
    
 
         
    
           git checkout -b (nombranche)
-          créer et basculer immédiatement vers une branche
+          crée et bascule immédiatement vers une branche
         
    
 
         
    
           Dans la plupart des cas vous voudrez basculer vers la branche immédiatement,
           afin de pouvoir y travailler puis fusionner dans une branche qui contient
-          seulement du travail stable (comme 'master') plus tard lorsque le travail
+          seulement du travail stable (comme « master ») plus tard lorsque le travail
           dans votre nouveau contexte de branche sera stable. Vous pouvez faire cela
           relativement facilement avec
           git branch nouvellebranche; git checkout nouvellebranche,
-          mais Git a un raccourci pour cela: git checkout -b nouvellebranche.
+          mais Git a un raccourci pour cela : git checkout -b nouvellebranche.
         
    
 
 
    @@ -216,10 +216,10 @@ 
    
 
         
    
           git branch -d (nombranche)
-          supprimer une branche
+          supprime une branche
         
    
 
-        
    Si nous voulons supprimer une branche (comme la branche 'testing' de
+        
    Si nous voulons supprimer une branche (comme la branche « testing » de
           l'exemple précédent vu qu'il n'y a aucun travail particulier sur celle-ci),
           nous pouvons exécuter git branch -d (branche) pour la supprimer.
    
 
@@ -235,13 +235,13 @@ 
    
 
           
    
             git push (nom-distant) :(nombranche)
-            supprimer une branche distante
+            supprime une branche distante
           
    
 
           
    Quand vous en avez fini avec une branche distante, qu'elle ait
             été fusionnée dans le dépôt distant ou que vous vouliez l'abandonner
             et la cacher des regards, vous exécuterez la commande git push
-            avec un symbôle deux-points savamment placé pour supprimer la branche:
    
+            avec un symbôle deux-points savamment placé pour supprimer la branche :
    
 
 
     $ git push origin :tidy-cutlery
@@ -249,8 +249,8 @@ 
    
  - [deleted]         tidy-cutlery
 
    
 
-            
    Dans l'exemple ci-dessus vous avez supprimé la branche "tidy-cutlery"
-              du dépôt distant "origin". Un moyen de se souvenir de cette syntaxe est
+            
    Dans l'exemple ci-dessus vous avez supprimé la branche « tidy-cutlery »
+              du dépôt distant « origin ». Un moyen de se souvenir de cette syntaxe est
               de penser à celle de
               git push nom-distant branche-locale:branche-distante.
               Cela signifie que vous désirez pousser votre branche locale pour
@@ -282,7 +282,7 @@ 
    
               livre
             
             git merge
-            fusionner le contexte d'une branche dans votre contexte courant
+            fusionne le contexte d'une branche dans votre contexte courant
           
    
 
           
    
@@ -290,11 +290,11 @@ 
    
               l'incorporer dans votre branche principale. Vous pouvez fusionner
               toute branche dans votre branche courante avec la commande
               git merge.  Prenons comme exemple simple la branche
-              'removals' précédente.  Si nous créons une branche et supprimons les fichiers
+              « removals » précédente.  Si nous créons une branche et supprimons les fichiers
               qui s'y trouvent puis que nous validons ces suppressions dans cette branche,
-              cela est isolé de notre branche principale ('master', dans notre cas). Pour
-              inclure ces suppressions dans notre branche 'master', vous pouvez simplement
-              fusionner la branche 'removals'.
+              cela est isolé de notre branche principale (« master », dans notre cas). Pour
+              inclure ces suppressions dans notre branche « master », vous pouvez simplement
+              fusionner la branche « removals ».
             
    
 
 
    @@ -324,7 +324,7 @@ 
    
               En fait, il est même très bon pour ça. Par exemple, voyons ce qu'il arrive
               quand on édite un fichier dans une branche et dans une autre branche
               nous le renommons et puis l'éditons et enfin nous fusionnons ensemble
-              ces branches. Chaos, vous avez dit? Voyons cela.
+              ces branches. Chaos, vous avez dit ? Voyons cela.
             
    
 
 
    @@ -341,9 +341,9 @@ 
    
 
    
 
             
    Nous allons donc commencer par créer une nouvelle branche nommée
-              'change_class' basculer vers celle-ci afin que vos modifications
+              « change_class » basculer vers celle-ci afin que vos modifications
               de renommage de classe soient isolées. Nous allons changer chaque
-              instance de 'HelloWorld' en 'HiWorld'.
    
+              instance de « HelloWorld » en « HiWorld ».
    
 
 
     $ git checkout -b change_class
@@ -357,7 +357,7 @@ 
    
 
    
 
               
    Nous avons alors validé les changements de nom de la classe dans
-                une branche 'change_class'. En retournant vers la branche 'master'
+                une branche « change_class ». En retournant vers la branche « master »
                 le nom de la classe sera ré-initialisé à ce à quoi il était avant
                 que nous changions de branche. Ici nous pouvons modifier quelque chose
                 de différent (dans ce cas la sortie affichée) et en même temps
@@ -389,11 +389,11 @@ 
    
  rename hello.rb => ruby.rb (65%)
 
    
 
-              
    Désormais ces modifications sont sauvées dans la branche 'master'. Notez
-                que le nom de la classe est de nouveau 'HelloWorld', et non 'HiWorld'.
-                Pou incorporer le changement 'HiWorld' nous pouvons juste fusionner
-                la branche 'change_class'. Néanmoins, le nom du fichier a changé depuis
-                que nous avons changé de branche, que va faire Git?
    
+              
    Désormais ces modifications sont sauvées dans la branche « master ». Notez
+                que le nom de la classe est de nouveau « HelloWorld », et non « HiWorld ».
+                Pou incorporer le changement « HiWorld » nous pouvons juste fusionner
+                la branche « change_class ». Néanmoins, le nom du fichier a changé depuis
+                que nous avons changé de branche, que va faire Git ?
    
 
 
     $ git branch
@@ -417,14 +417,14 @@ 
    
 
                 
    Et bien, il va simplement s'en rendre compte. Notez qu'il n'y a aucun conflit de
                   fusion et que le fichier qui a été renommé a maintenant le changement de nom
-                  de de classe 'HiWorld' qui a été fait dans l'autre branche. Plutôt cool.
    
+                  de de classe « HiWorld » qui a été fait dans l'autre branche. Plutôt cool.
    
 
                 
    
-                  merge conflicts
+                  conflits de fusion
                 
    
 
                 
    Donc, les fusions Git relèvent de la magie, nous n'avons jamais à traiter
-                  des conflits de fusion? Pas tout à fait. Dans des situations où
+                  des conflits de fusion ? Pas tout à fait. Dans des situations où
                   un même bloc de code est édité dans différentes branches il n'y a aucun moyen
                   pour un ordinateur de s'y retrouver, alors c'est à nous de nous débrouiller.
                   Voyons un autre exemple de changement d'une même ligne dans deux branches.
@@ -443,7 +443,7 @@ 
    
 
                 
    Maintenant nous avons validé un changement d'une ligne dans notre
                   fichier README dans une branche. Maintenant changeons la même ligne
-                  d'une manière différente depuis notre branche 'master'.
    
+                  d'une manière différente depuis notre branche « master ».
    
 
 
     $ git checkout master
@@ -454,8 +454,8 @@ 
    
  1 files changed, 1 insertions(+), 1 deletions(-)
 
    
 
-                  
    C'est maintenant le plus rigolo - nous allons fusionner la première
-                    branche dans notre branche 'master', provoquant un conflit de fusion.
    
+                  
    C'est maintenant le plus rigolo—nous allons fusionner la première
+                    branche dans notre branche « master », provoquant un conflit de fusion.
    
 
 
     $ git merge fix_readme
@@ -501,7 +501,7 @@ 
    
                       vous exécutez git diff, cela va vous montrer chaque côté
                       du conflit et comment vous l'avez résolu comme affiché ici. Maintenant
                       il est l'heure de marquer notre fichier comme résolu. Avec Git on le fait
-                      avec git add - pour dire à Git que le fichier a été résolu
+                      avec git add—pour dire à Git que le fichier a été résolu
                       vous devez le mettre en attente.
    
 
 
    @@ -534,15 +534,15 @@ 
    
                         livre
                       
                       git log
-                      afficher l'historique des validations d'une branche
+                      affiche l'historique des validations d'une branche
                     
    
 
                     
    
 
                       
    Jusqu'à présent nous avons validé des instantanés de votre projet et basculé
                         entre différents contextes isolés, mais comment faire si nous avons oublié
-                        comment nous en sommes arrivés à un certain point? Ou si nous voulons
-                        savoir à quel point une branche diffère d'une autre? Git fournit un outil
+                        comment nous en sommes arrivés à un certain point ? Ou si nous voulons
+                        savoir à quel point une branche diffère d'une autre ? Git fournit un outil
                         qui affiche tous les messages de validations qui vous ont amené jusqu'à
                         votre instantané courant, appelé git log.
    
 
@@ -553,12 +553,12 @@ 
    
                         de la validation, Git stocke également la validation sur laquelle vous avez
                         basé votre instantané. C'est-à-dire que, si vous clonez un projet, quel
                         est l'instantané que vous avez modifié pour obtenir l'instantané que vous
-                        enregistrez? C'est utile pour connaître le contexte dans quelle mesure
+                        enregistrez ? C'est utile pour connaître le contexte dans quelle mesure
                         le projet est arrivé à cet état et permet à Git de savoir qui a changé quoi.
                         Si Git a l'instantané que vous avez sauvegardé et celui sur lequel vous vous
                         êtes basé, alors il peut automatiquement savoir ce que vous avez changé.
                         La validation sur laquelle une autre validation est basée est appelée le
-                        "parent".
+                        « parent ».
                       
    
 
                       
    Pour voir une liste chronologique des parents de n'importe quelle branche,
@@ -622,7 +622,7 @@ 
    
 
                         
    Nous pouvons aussi l'utiliser pour voir quand l'historique a connu des
                           branches ou fusions avec l'option très utile --graph.
-                          Voici la même commande mais avec le graphe de topologie activé:
    
+                          Voici la même commande mais avec le graphe de topologie activé :
    
 
 
     $ git log --oneline --graph
@@ -648,7 +648,7 @@ 
    
                             nous aider à savoir ce qui se passe sur chacune d'elle.
    
 
                           
    D'abord nous allons créer une nouvelle branche pour ajouter le langage
-                            Erlang comme exemple Hello World - nous désirons le faire dans une branche
+                            Erlang comme exemple Hello World—nous désirons le faire dans une branche
                             afin de ne pas casser notre branche stable avec du code qui peut ne pas
                             fonctionner pendant un certain temps pour pouvoir basculer proprement
                             depuis ou vers cette branche.
    
@@ -667,7 +667,7 @@ 
    
                             
    Étant donné que nous nous amusons beaucoup avec les langages de
                               programmation fonctionnelle nous restons dans notre lancée et ajoutons
                               également un programme exemple Haskell alors que nous sommes toujours
-                              dans la branche 'erlang'.
    
+                              dans la branche « erlang ».
    
 
 
     $ vim haskell.hs
@@ -681,7 +681,7 @@ 
    
                               
    Enfin, nous décidons de remettre le nom de classe de notre programme Ruby
                                 à ce qu'il était précédemment. Alors, nous pouvons retourner à la branche
                                 master, le changer et décider de le valider directement dans la branche
-                                master au lieu de créer une autre bracnhe.
    
+                                master au lieu de créer une autre branche.
    
 
 
     $ git checkout master
@@ -696,12 +696,12 @@ 
    
 
                                 
    Alors, maintenant imaginons que nous ne travaillons pas sur le projet
                                   pendant quelques temps, nous avons autre chose à faire. Quand nous
-                                  y revenons nous voulons en savoir plus sur la branche 'erlang' et
+                                  y revenons nous voulons en savoir plus sur la branche « erlang » et
                                   où nous nous en sommes arrêtés sur  la branche master. Juste en regardant
                                   le nom de la branche, nous ne pouvons savoir que nous avons fait des modifications
                                   en Haskell dans celle-ci, mais en utilisant git log nous pouvons
                                   facilement le savoir. Si vous donnez à Git un nom de branche, cela va vous afficher
-                                  uniquement les validations qui sont "accessibles" dans l'historique de cette
+                                  uniquement les validations qui sont « accessibles » dans l'historique de cette
                                   branche, c'est-à-dire les validations qui ont influencé l'instantané
                                   final.
    
 
@@ -727,12 +727,12 @@ 
    
                                   
    
 
                                   
    
-                                    Dans ce cas si nous sommes intéressés par la fusion de la branche 'erlang'
+                                    Dans ce cas si nous sommes intéressés par la fusion de la branche « erlang »
                                     nous voulons savoir quelles validations vont affecter notre instantané
                                     quand nous allons fusionner. Pour dire à Git de le faire on utilise
                                     un ^ devant la branche que nous ne voulons voir. Par exemple,
-                                    si nous voulons voir les validations qui sont dans la branche 'erlang'
-                                    qui ne sont pas dans la branche 'master', on peut exécuter
+                                    si nous voulons voir les validations qui sont dans la branche « erlang »
+                                    qui ne sont pas dans la branche « master », on peut exécuter
                                     erlang ^master, et vice-versa. Notez que la ligne de
                                     commande Windows traite ^ comme un caractère spécial,
                                     dans ce cas vous devrez mettre ^master entre guillemets.
@@ -770,7 +770,7 @@ 
    
                                     livre
                                   
                                   git tag
-                                  étiqueter un moment dans l'historique comme important
+                                  étiquette un moment dans l'historique comme important
                                 
    
 
                                 
    
@@ -786,9 +786,9 @@ 
    
                                   
    
 
                                   
    Disons que vous vouliez publier notre projet Hello World en tant
-                                    que version "1.0". Nous pouvons étiqueter la dernière validation
-                                    (HEAD) comme "v1.0" en exécutant git tag -a v1.0.
-                                    Le -a signifie "fait une étiquette annotée", qui permet
+                                    que version « 1.0 ». Nous pouvons étiqueter la dernière validation
+                                    (HEAD) comme « v1.0 » en exécutant git tag -a v1.0.
+                                    Le -a signifie « fait une étiquette annotée », qui permet
                                     de lui ajouter un message d'étiquette, ce que vous voudrez quasiment
                                     toujours faire. L'exécuter sans le -a fonctionne aussi,
                                     mais cela n'enregistre pas quand cela a été étiqueté, qui l'a étiqueté,
@@ -833,7 +833,7 @@ 
    
                                         commande, mais avec le SHA de la validation à la fin. Par exemple, disons
                                         que nous avons publié la validation 558151a (de plusieurs
                                         validations en arrière) mais avons oublié de l'étiqueter à ce moment-là.
-                                        Nous pouvons l'étiqueter maintenant:
    
+                                        Nous pouvons l'étiqueter maintenant :
    
 
 
     $ git tag -a v0.9 558151a
@@ -893,5 +893,5 @@ 
    
                                       
    
                                     
    
 
-                                    
    Aller à Partager et Actualiser des Projets »
    
+                                    
    Aller à Partage et Mise à Jour de Projets »
    
 
diff --git a/fr/creating/index.html b/fr/creating/index.html
index 8129eb5..41ade81 100644
--- a/fr/creating/index.html
+++ b/fr/creating/index.html
@@ -3,7 +3,7 @@
 ---
 
 
    
-  
    Récupérer et Créer des Projets
    
+  
    Obtention et Création des Projets
    
   
    
     
    
       Pour pouvoir faire quoi que ce soit avec Git, vous devez
@@ -14,7 +14,7 @@ 
    Récupérer et Créer des Projets
    
     
    
       Il y a deux moyens d'avoir un dépôt Git. Le premier est de simplement
       en initialiser un depuis un dossier existant, comme un nouveau projet
-      ou un projet débutant sa gestion de révisions. Le second est de cloner
+      ou un projet débutant sa gestion de versions. Le second est de cloner
       un dépôt public Git, comme vous le feriez si vous vouliez une copie
       ou si vous vouliez collaborer avec quelqu'un sur un projet. Nous allons
       aborder chacun de ces cas.
@@ -27,17 +27,17 @@ 
    Récupérer et Créer des Projets
    
   
    
     
       docs  
-      book
+      livre
     
     git init
-    initialiser un répertoire comme dépôt Git
+    initialise un répertoire comme dépôt Git
   
    
 
   
    
     
    Pour créer un dépôt à partir d'un répertoire de fichiers existant,
       vous pouvez simplement faire git init dans ce répertoire.
       Par exemple, disons que nous avons un répertoire comprenant quelques fichiers,
-      ressemblant à:
+      ressemblant à :
     
    
 
 
    @@ -47,7 +47,7 @@ 
    
 
    
 
     
    C'est un projet dans lequel nous écrivons des exemples de programmes
-      "Hello World" dans chaque langage. Pour l'instant, nous avons simplement Ruby,
+      « Hello World » dans chaque langage. Pour l'instant, nous avons simplement Ruby,
       mais ce n'est qu'un début. Pour commencer à en gérer les versions avec Git,
       nous pouvons simplement lancer git init.
     
    
@@ -83,10 +83,10 @@ 
    
   
    
     
       docs  
-      book
+      livre
     
     git clone
-    copier un dépôt git pour pouvoir le modifier
+    copie un dépôt git pour pouvoir le modifier
   
    
   
    
     
    
@@ -129,7 +129,7 @@ 
    
 
     
    
       Par défaut, Git crée un dossier avec le même nom que le projet de l'URL
-      donnée - typiquement tout ce qui se trouve après le dernier slash de l'URL.
+      donnée—typiquement tout ce qui se trouve après le dernier slash de l'URL.
       Si vous voulez quelque chose de différent, vous pouvez l'indiquer à la fin
       de la commande, après l'URL.
     
    
@@ -142,4 +142,4 @@ 
    
   
    
 
    
 
-
    Aller à Bases des Instantanés »
    
+
    Aller à Capture d’Instantané Basique »
    
diff --git a/fr/index.html b/fr/index.html
index f84aae1..34f4fc6 100644
--- a/fr/index.html
+++ b/fr/index.html
@@ -30,19 +30,20 @@ 
    Comment penser à la Git
    
   
    
     
    
       La première chose à comprendre sur Git est qu'il
-      gère les révisions d'une manière totalement différente
+      gère les versions d'une manière totalement différente
       de Subversion ou Perforce ou tout autre gestionnaire de code source
       auquel vous pourriez être habitué. Il est souvent plus simple
       d'apprendre Git en essayant d'oublier toute assertion sur
-      le fonctionnement de la gestion de révisions et d'essayer d'y penser
+      le fonctionnement de la gestion de versions et d'essayer d'y penser
       à la Git.
     
    
 
     
    
       Partons de zéro. Imaginons que vous conceviez un nouveau système de gestion
-      de code source. Comment géreriez-vous simplement des révisions avant d'utiliser
-      un outil dédié? Il y a de fortes chances pour que vous ayez fait de simples
-      copies du répertoire de votre projet pour sauvegarder son état à ce moment-là.
+      de code source. Comment gériez-vous simplement différentes versions
+      avant d'utiliser un outil dédié à ça ? Il y a de fortes chances pour que vous ayez
+      fait de simples copies du répertoire de votre projet pour sauvegarder
+      son état à ce moment-là.
     
    
 
     
     $ cp -R project project.bak 
    
@@ -56,7 +57,7 @@ 
    Comment penser à la Git
    
 
     
    
       Si vous êtes réellement paranoïaque, vous le ferez peut-être souvent,
-      et vous inclurez la date dans le nom de la sauvegarde:
+      et vous inclurez la date dans le nom de la sauvegarde :
     
    
 
     
     $ cp -R project project.2010-06-01.bak 
    
@@ -90,7 +91,7 @@ 
    Comment penser à la Git
    
     
    
       Ceci fonctionne en fait plutôt bien, alors disons que nous désirons
       écrire un outil pour effectuer ce processus basique plus rapidement
-      et plus facilement. Au lieu d'écrire un outil qui crée des révisions
+      et plus facilement. Au lieu d'écrire un outil qui crée des versions
       de chaque fichier individuellement, comme Subversion, nous en écririons
       probablement un qui permettrait de manière plus simple de conserver
       des instantanés de notre projet sans avoir à copier la totalité du
@@ -100,8 +101,8 @@ 
    Comment penser à la Git
    
     
    
       C'est fondamentalement ce que fait Git. Vous dites à Git de sauvegarder
       un instantané de votre projet avec la commande git commit
-      et il va simplement enregistrer l'état de tous vos fichiers de votre projet
-      à ce moment. Ensuite la plupart des commandes travaille avec ces enregistrements
+      et il va simplement enregistrer l'état de tous les fichiers de votre projet
+      à ce moment. Ensuite la plupart des commandes travaillent avec ces enregistrements
       d'état pour voir comment ils différent ou y récupérer du contenu, etc.
     
    
 
@@ -116,4 +117,4 @@ 
    Comment penser à la Git
    
   
    
 
    
 
-
    Aller à Récupérer et Créer des Projets »
    
+
    Aller à Obtention et Création des Projets »
    
diff --git a/fr/inspect/index.html b/fr/inspect/index.html
index 3647a0b..3308fa5 100644
--- a/fr/inspect/index.html
+++ b/fr/inspect/index.html
@@ -13,16 +13,16 @@ 
    
     
    
       Vous avez désormais plusieurs branches dont vous vous servez pour des
       besoins éphémères, des fonctionnalités durables et autres. Comment
-      vous y retrouver parmi celles-ci? Git a différents outils pour vous
+      vous y retrouver parmi celles-ci ? Git a différents outils pour vous
       aider à savoir où un travail donné a eu lieu, quelles sont les différences
       entre deux branches et bien d'autres choses.
     
    
 
     
    
       Pour résumer, vous utilisez git log pour retrouver des
-      validations spécifiques dans l'historique de votre projet - par auteur, date,
+      validations spécifiques dans l'historique de votre projet—par auteur, date,
       contenu et historique. Vous pouvez utiliser git diff pour comparer
-      deux points différents dans votre historique - habituellement pour voir de quelle
+      deux points différents dans votre historique—habituellement pour voir de quelle
       manière deux branches diffèrent ou ce qui a changé entre une version de votre
       logiciel et une autre.
     
    
@@ -36,13 +36,13 @@ 
    
       livre
     
     git log
-    limiter la longueur de l'historique
+    limite la longueur de l'historique
   
    
 
   
    
     
    Nous avons déjà vu comment utiliser git log pour comparer
       des branches, en visualisant les validations d'une branche. (Si vous ne vous
-      en souvenez pas, cela ressemble à: git log brancheA ^brancheB).
+      en souvenez pas, cela ressemble à : git log brancheA ^brancheB).
       Cependant, vous pouvez utiliser git log pour rechercher une
       validation spécifique. Ici nous allons nous intéresser à certaines options
       communément utilisées par git log, mais il en existe de très
@@ -51,7 +51,7 @@ 
    
 
     
    
       git log --author
-      rechercher uniquement les validations d'un auteur en particulier
+      recherche uniquement les validations d'un auteur en particulier
     
    
 
     
    
@@ -76,7 +76,7 @@ 
    
 
     
    
       git log --since --before
-      filtrer les validations suivant la date de validation
+      filtre les validations suivant la date de validation
     
    
 
     
    
@@ -86,7 +86,7 @@ 
    
       et --after. Par exemple, pour voir toutes les validations du projet
       Git d'il y a trois semaines mais après le 18 Avril, vous pourriez exécuter ceci
       (Nous allons aussi utiliser --no-merges pour ignorer les validations
-      de fusion):
+      de fusion) :
     
    
 
 
    @@ -104,14 +104,14 @@ 
    
 
     
    
       git log --grep
-      filtrer les validations suivant les messages de validation
+      filtre les validations suivant les messages de validation
     
    
 
     
    
       Vous désireriez peut-être également rechercher les validations avec une certaine
       phrase dans le message de validation. Utilisez --grep pour cela.
       Disons qu'il y a une validation qui portait sur la variable d'environnement P4EDITOR
-      et que vous vouliez vous remémorer à quoi ressemblaient les modificiations - vous
+      et que vous vouliez vous remémorer à quoi ressemblaient les modificiations—vous
       pourriez retrouver cette validation avec --grep.
     
    
 
@@ -140,8 +140,8 @@ 
    
       l'option --format, afin de voir qui est l'auteur de chaque validation.
     
    
 
-    
    Si nous recherchons les validations dont le message contient 'p4 depo',
-      nous obtenons ces trois validations:
    
+    
    Si nous recherchons les validations dont le message contient « p4 depo »,
+      nous obtenons ces trois validations :
    
 
 
     $ git log --grep="p4 depo" --format="%h %an %s"
@@ -152,7 +152,7 @@ 
    
 
       
    Si nous ajoutons l'argument --author=Hausmann,
         au lieu de filtrer les validations de Simon, il va plutôt nous montrer
-        toutes les validations par Simon ou dont le message contient "p4 depo".
    
+        toutes les validations par Simon ou dont le message contient « p4 depo".
    
 
 
     $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
@@ -172,7 +172,7 @@ 
    
 
    
 
         
    Néanmoins, ajouter --all-match va vous retourner les résultats
-          que vous attendez:
    
+          que vous attendez :
    
 
 
     $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match
@@ -181,18 +181,18 @@ 
    
 
           
    
             git log -S
-            filtrer suivant les changements introduits
+            filtre suivant les changements introduits
           
    
 
           
    
-            Que faire si vos messages de validations sont vraiment mauvais? Ou si
+            Que faire si vos messages de validations sont vraiment mauvais ? Ou si
             vous recherchez quand une fonction a été rajoutée, ou quand des
-            variables ont commencé à être utilisées? Vous pouvez aussi dire à Git
+            variables ont commencé à être utilisées ? Vous pouvez aussi dire à Git
             de rechercher parmi les modifications de chaque validation pour une certaine
             chaîne de caractères. Par exemple, si nous voulions trouver quelles
             validations ont modifié tout ce qui ressemble au nom de function
-            'userformat_find_requirements', nous exécuterions ceci (notez qu'il
-            n'y a pas de '=' entre le '-S' et ce que vous recherchez):
+            « userformat_find_requirements', nous exécuterions ceci (notez qu'il
+            n'y a pas de « = » entre le « -S » et ce que vous recherchez) :
           
    
 
 
    @@ -217,7 +217,7 @@ 
    
 
           
    
             git log -p
-            afficher le correctif introduit par chaque validation
+            affiche le correctif introduit par chaque validation
           
    
 
           
    
@@ -278,7 +278,7 @@ 
    
 
           
    
             git log --stat
-            afficher un résumé des modifications introduites par chaque validation
+            affiche un résumé des modifications introduites par chaque validation
           
    
 
           
    Si vous trouvez l'option -p trop verbeuse, vous pouvez résumer
@@ -306,7 +306,7 @@ 
    
  1 files changed, 1 insertions(+), 1 deletions(-)
 
    
 
-            
    Basiquement les mêmes informations, mais plus succintement - vous pouvez
+            
    Basiquement les mêmes informations, mais plus succintement—vous pouvez
               toujours les diférences et quelles fichiers ont été modifiés.
    
 
           
    
@@ -326,7 +326,7 @@ 
    
 
             
    Enfin, pour voir les changements absolus entre deux instantanés de validations,
               vous pouvez utiliser la commande git diff. Ceci est très utilisé
-              principalement dans deux cas - voir en quoi deux branches diffèrent
+              principalement dans deux cas—voir en quoi deux branches diffèrent
               l'une de l'autre et voir ce qui a changé depuis la publication d'une version
               ou tout autre ancien moment donné passé dans l'historique.
               Voyons chacune de ces situations.
    
@@ -378,16 +378,16 @@ 
    
 
               
    Pour comparer deux branches divergentes, néanmoins, vous pouvez exécucter
                 quelque chose de similaire à git diff branchA branchB mais
-                le problème est que cela va faire exactement ce que vous lui demandez
-                - cela va concrétement vous fournir le correctif qui transformerai l'instantané
+                le problème est que cela va faire exactement ce que vous lui
+                demandez—cela va concrètement vous fournir le correctif qui transformerai l'instantané
                 à l'extrémité de la branche brancheA en l'instantané de l'extrémité de la
-                branche brancheB. Cela signifie que si deux branches ont divergé - elles
-                ont pris des directions différentes - cela va occulter toutes les modifications
+                branche brancheB. Cela signifie que si deux branches ont divergé—elles
+                ont pris des directions différentes—cela va occulter toutes les modifications
                 introduites dans brancheA puis ajouter tout ce qui a été introduit dans brancheB.
-                Ce n'est probablement pas ce que vous voulez - vous voulez les changements ajoutés
+                Ce n'est probablement pas ce que vous voulez—vous voulez les changements ajoutés
                 à brancheB qui ne sont pas dans brancheA, vous voulez donc vraiment les différences
                 entre là où les deux branches ont divergé et l'extrémité de brancheB. Donc,
-                si notre historique ressemble à ça:
    
+                si notre historique ressemble à ça :
    
 
 
     $ git log --graph --oneline --decorate --all
@@ -399,8 +399,8 @@ 
    
 ...
 
    
 
-                
    Et si nous voulions voir ce qui se trouve sur la branche "erlang" 
-                  par rapport à la branche "master", exécuter git diff master erlang
+                
    Et si nous voulions voir ce qui se trouve sur la branche « erlang »
+                  par rapport à la branche « master », exécuter git diff master erlang
                   ne nous afficherait pas la bonne chose.
    
 
 
    @@ -415,9 +415,9 @@ 
    
                     que nous avons fait dans cette branche, mais la sortie revient aussi sur les
                     changements du fichier ruby que nous avons effetués dans la branche master.
                     Ce que nous voulons vraiment voir sont juste les changements qui ont été faits
-                    dans la branche "erlang" (l'ajout des deux fichiers). Nous pouvons obtenir le
+                    dans la branche « erlang » (l'ajout des deux fichiers). Nous pouvons obtenir le
                     résultat attendu en faisant la différence entre la validation commune de laquelle
-                    elles ont divergé:
    
+                    elles ont divergé :
    
 
 
     $ git diff --stat 8d585ea erlang
@@ -431,7 +431,7 @@ 
    
                       Heureusement, Git a un raccourci pour ça. Si vous exécutez
                       git diff master...erlang (avec trois points entre les noms de
                       branches), Git va automatiquement savoir quelle est la validation commune
-                      (aussi connue sous le nom de "base de fusion") entre les deux validations et
+                      (aussi connue sous le nom de « base de fusion") entre les deux validations et
                       afficher les modifications en se basant sur celle-ci.
    
 
 
    @@ -453,7 +453,7 @@ 
    
 
                       
    En guise de bonus, vous pouvez aussi faire calculer manuellement par Git quelle
                         serait la base de fusion (la première validation ancêtre commune) entre deux validations
-                        avec la commande git merge-base:
    
+                        avec la commande git merge-base :
    
 
 
     $ git merge-base master erlang
@@ -461,7 +461,7 @@ 
    
 
    
 
                         
    Vous pouvez faire l'équivalent de git diff master...erlang
-                          en exécutant:
    
+                          en exécutant :
    
 
 
     $ git diff --stat $(git merge-base master erlang) erlang
@@ -484,5 +484,5 @@ 
    
                         
    
                       
    
 
-                      
    Et c'est la fin! Pour plus d'informations, essayez de lire le
+                      
    Et c'est la fin ! Pour plus d'informations, essayez de lire le
                         Livre Pro Git.
    
diff --git a/fr/remotes/index.html b/fr/remotes/index.html
index 8cf72ab..676a753 100644
--- a/fr/remotes/index.html
+++ b/fr/remotes/index.html
@@ -7,7 +7,7 @@ 
    
     
       livre
     
-    Partager et actualiser des projets
+    Partage et Mise à Jour de Projets
   
    
   
    
     
    
@@ -16,9 +16,9 @@ 
    
       de données locale. Pour collaborer avec d'autres développeurs sous Git,
       vous devez mettre toutes ces données sur un serveur auquel les autres
       ont accès. Git rend cela possible en synchronisant vos données avec un
-      autre dépôt. Il n'y a pas de réelle différence entre un serveur et un client
-      - un dépôt Git est un dépôt Git et vous pouvez les synchroniser indifféremment
-      entre eux facilement.
+      autre dépôt. Il n'y a pas de réelle différence entre un serveur et un
+      client—un dépôt Git est un dépôt Git et vous pouvez les synchroniser
+      indifféremment entre eux facilement.
     
    
 
     
    Dès que vous avez un dépôt Git, que ce soit un que vous hébergez sur votre
@@ -49,7 +49,7 @@ 
    
       livre
     
     git remote
-    lister, ajouter et supprimer les alias de dépôts distants
+    liste, ajoute et supprime les alias de dépôts distants
   
    
 
   
    
@@ -57,7 +57,7 @@ 
    
     
    Contrairement aux systèmes de gestion de versions centralisés qui ont un client
       qui est très différent du serveur, les dépôts Git sont tout simplement équivalents
       et vous les synchronisez simplement entre eux. Cela simplifie la possibilité
-      d'avoir plus d'un dépôt distant - vous pouvez en avoir certains en lecture seule
+      d'avoir plus d'un dépôt distant—vous pouvez en avoir certains en lecture seule
       ainsi que d'autres accessibles en écriture.
    
 
     
    Afin de ne pas avoir à donner l'URL complète d'un dépôt distant à chaque
@@ -68,13 +68,13 @@ 
    
 
     
    
       git remote
-      lister vos alias distants
+      liste vos alias distants
     
    
 
     
    Sans argument, Git va simplement vous afficher les alias de dépôt distants
       qu'ils stockent. Par défaut, si vous avez cloné le projet (par opposition
       à en créer un nouveau localement), Git va automatiquement ajouter l'URL
-      de ce dépôt source que vous avez cloné sous le nom 'origin'. SI vous exécutez
+      de ce dépôt source que vous avez cloné sous le nom « origin ». SI vous exécutez
       la commande avec l'option -v, vous pouvez voir
       l'URL réelle de chaque alias.
    
 
@@ -93,11 +93,11 @@ 
    
 
       
    
         git remote add
-        ajouter un nouveau dépôt distant à votre projet
+        ajoute un nouveau dépôt distant à votre projet
       
    
 
       
    Si vous voulez partager un dépôt créé localement, ou vous voulez
-        récupérer les contributions depuis le dépôt d'un tiers - si vous voulez
+        récupérer les contributions depuis le dépôt d'un tiers—si vous voulez
         interagir de n'importe quelle manière avec un nouveau dépôt, le plus simple
         est généralement de l'ajouter comme dépôt distant. Vous faites cela en
         exécutant git remote add [alias] [url]. Cela ajoute
@@ -107,9 +107,9 @@ 
    
       
    Par exemple, si nous voulons partager notre programme Hello World avec
         le reste du monde, nous pouvons créer un nouveau dépôt sur un serveur
         (utilisons Github comme exemple), vous devriez obtenir une URL,
-        dans notre cas "git@github.com:schacon/hw.git". Pour l'ajouter à notre
+        dans notre cas « git@github.com:schacon/hw.git ». Pour l'ajouter à notre
         projet afin de pouvoir y pousser et récupérer des mises à jour depuis celui-ci
-        nous ferions:
    
+        nous ferions :
    
 
 
     $ git remote
@@ -120,21 +120,21 @@ 
    
 
    
 
         
    Tout comme la dénomination des branches, le nommage des alias de dépôts
-          distants est arbitraire - tout comme 'master' n'a aucune signification spéciale
+          distants est arbitraire—tout comme « master » n'a aucune signification spéciale
           mais est très largement utilisé car git init le configure par défaut,
-          'origin' est souvent utilisé comme nom de dépôt distant car
+          « origin » est souvent utilisé comme nom de dépôt distant car
           git clone le configure par défaut comme URL source de clonage. Dans
-          notre cas nous allons appeler ce dépôt distant 'github', mais vous pourriez le
+          notre cas nous allons appeler ce dépôt distant « github », mais vous pourriez le
           nommer comme bon vous semblerait.
         
    
 
         
    
           git remote rm
-          enlever un alias existant de dépôt distant
+          enlève un alias existant de dépôt distant
         
    
 
-        
    Si vous avez besoin d'enlever un dépôt distant - vous ne l'utilisez plus, le projet
-          n'existe plus, etc - vous pouvez l'enlever avec git remote rm [alias].
    
+        
    Si vous avez besoin d'enlever un dépôt distant—vous ne l'utilisez plus, le projet
+          n'existe plus, etc—vous pouvez l'enlever avec git remote rm [alias].
    
 
 
     $ git remote -v
@@ -154,7 +154,7 @@ 
    
 
           
    
             git remote rename [ancien-alias] [nouvel-alias]
-            renommer des alias de dépôt distant
+            renomme des alias de dépôt distant
           
    
 
           
    Si vous voulez renommer des alias de dépôt distant sans avoir à les supprimer puis les
@@ -183,7 +183,7 @@ 
    
 
             
    
               git remote set-url
-              actualiser une URL distante existante
+              actualise une URL distante existante
             
    
 
             
    Si vous aviez besoin d'actualiser l'URL d'un dépôt distant, vous
@@ -268,7 +268,7 @@ 
    
               livre
             
             git fetch
-            récupérer de nouvelles branches et données depuis un dépôt distant
+            récupère de nouvelles branches et données depuis un dépôt distant
           
    
 
           
    
@@ -279,7 +279,7 @@ 
    
               livre
             
             git pull
-            récupérer depuis un dépôt distant et essaye de fusionner dans la branche courante
+            récupère depuis un dépôt distant et essaye de fusionner dans la branche courante
           
    
 
           
    
@@ -288,8 +288,8 @@ 
    
               git fetch va vous synchroniser avec un autre dépôt, récupérant
               en local tout donnée non présente en local et vous donnant des marqueurs sur où
               chaque branche sur ce dépôt distant en était au momemt de la synchronisation.
-              Celles-ci sont appelées "branches distantes" et sont identiques aux branches locales
-              mis à part que Git ne vous autorisera pas de les extraire - par contre, vous pouvez
+              Celles-ci sont appelées « branches distantes » et sont identiques aux branches locales
+              mis à part que Git ne vous autorisera pas de les extraire—par contre, vous pouvez
               fusionner avec, les comparer à d'autres branches, exécuter des journaux d'historique
               dessus, etc. Vous faites toutes ces opérations en local une fois votre synchronisation
               faite.
@@ -312,7 +312,7 @@ 
    
               branche courante tout ce qu'il y de nouveau sur le serveur (par exemple si quelqu'un
               a poussé entretemps). Au final, si vous travailliez sur un projet Hello World avec
               plusieurs autres personnes et que vous vouliez récupérer toutes modifications qui
-              ont été poussées depuis votre dernière connexion, vous feriez quelque chose comme:
    
+              ont été poussées depuis votre dernière connexion, vous feriez quelque chose comme :
    
 
 
     $ git fetch github
@@ -331,18 +331,18 @@ 
    
 
               
    Dans cet exemple nous pouvons voir que depuis notre dernière synchronisation
                 avec le dépôt distant, cinq branches ont été créées ou mises à jour. Les
-                branches 'ada' et 'lisp' sont nouvelles, alors que les branches 'master', 'c-langs'
-                et 'java' ont été actualisées. Dans notre scénario exemple, les autres développeurs
-                poussent leurs modifications dans des branches distantes pour revue avant d'être
-                fusionnées dans 'master'.
+                branches « ada » et « lisp » sont nouvelles, alors que les branches « master »,
+                « c-langs » et « java » ont été actualisées. Dans notre scénario exemple,
+                les autres développeurs poussent leurs modifications dans des branches distantes
+                pour revue avant d'être fusionnées dans « master ».
               
    
 
-              
    Vous pouvez observer ce que Git met en place. La branche 'master' sur le dépôt
-                distant devient une branche appelée 'github/master' en local. De cette manière
-                vous pouvez fusionner la branche 'master' de ce dépôt distant dans la branche locale
-                'master' en exécutant git merge github/master. Ou vous pouvez voir
+              
    Vous pouvez observer ce que Git met en place. La branche « master » sur le dépôt
+                distant devient une branche appelée « github/master » en local. De cette manière
+                vous pouvez fusionner la branche « master » de ce dépôt distant dans la branche locale
+                « master » en exécutant git merge github/master. Ou vous pouvez voir
                 quelles sont les nouvelles validations en exécutant git log github/master ^master.
-                Si votre dépôt distant est nommé 'origin' il sera plutôt nommé origin/master.
+                Si votre dépôt distant est nommé « origin » il sera plutôt nommé origin/master.
                 Quasiment tout commande utilisable sur les branches locales est utilisable également
                 sur les branches distantes.
               
    
@@ -370,7 +370,7 @@ 
    
                 livre
               
               git push
-              pousser vos nouvelles branches et données vers un dépôt distant
+              pousse vos nouvelles branches et données vers un dépôt distant
             
    
 
             
    
@@ -378,7 +378,7 @@ 
    
                 vos modifications vers un dépôt distant. Pour cela, vous exécutez
                 git push [alias] [branche]  qui va tenter de faire de votre [branche]
                 une nouvelle [branche] sur le dépôt distant [alias]. Essayons de le faire en commençant
-                par pousser notre branche 'master' vers le dépôt distant 'github' créé précédemment.
    
+                par pousser notre branche « master » vers le dépôt distant « github » créé précédemment.
    
 
 
     $ git push github master
@@ -394,8 +394,8 @@ 
    
                 
    Plutôt simple. Désormais si quelqu'un clone ce dépôt il va obtenir exactement
                   toutes ses validations et tout son historique.
    
 
-                
    Comment faire si vous avez une branche spécifique comme la branche 'erlang'
-                  créée précédemment et que vous vouliez just partager celle-ci? Vous pouvez
+                
    Comment faire si vous avez une branche spécifique comme la branche « erlang »
+                  créée précédemment et que vous vouliez just partager celle-ci ? Vous pouvez
                   uniquement pousser cette branche à la place.
    
 
 
    @@ -410,7 +410,7 @@ 
    
 
    
 
                   
    Désormais quand quelqu'un clonera ou récupérera depuis ce dépôt, elle aura
-                    une branche 'erlang' qu'elle pourra étudier et fusionner. Vous pouvez pousser
+                    une branche « erlang » qu'elle pourra étudier et fusionner. Vous pouvez pousser
                     toute branche de cette manière vers n'importe quel dépôt distant auquel
                     vous avez accès en écriture. Si votre branche est déjà sur le serveur,
                     Git tentera de la mettre à jour, si elle n'est pas présente, Git l'ajoutera.
    
@@ -425,11 +425,11 @@ 
    
                     de la branche du serveur dans l'historique de ce que vous poussez. S'il ne
                     peut voir ce qu'il trouve sur le serveur dans votre historique, il en conclut
                     que vous n'êtes pas à jour et ne va pas accepter que vous poussiez. Pour bien
-                    faire, vous devriez récupérer, fusionner puis pousser à nouveau - pour être sûr
+                    faire, vous devriez récupérer, fusionner puis pousser à nouveau—pour être sûr
                     de prendre ses modifications en compte.
    
 
                   
    Voici ce qui arrive lorsque vous essayez de pousser une branche vers une branche
-                    distante qui a été mise à jour en même temps:
    
+                    distante qui a été mise à jour en même temps :
    
 
 
     $ git push github master

From 3b788c87ecd9fa02e650ce2a2ccb4ce83fdd3b29 Mon Sep 17 00:00:00 2001
From: Benoit Benedetti 
Date: Sun, 28 Feb 2016 12:05:11 +0100
Subject: [PATCH 17/22] Reviewing fr/index.html

---
 fr/index.html | 57 +++++++++++++++++++++++++--------------------------
 1 file changed, 28 insertions(+), 29 deletions(-)

diff --git a/fr/index.html b/fr/index.html
index 34f4fc6..4d16e4c 100644
--- a/fr/index.html
+++ b/fr/index.html
@@ -9,17 +9,17 @@ 
    Introduction à Référence Git
    
       de référence rapide pour apprendre et retenir les commandes
       les plus importantes et les plus utilisées de Git. Les commandes
       sont organisées en sections selon le type d'opérations que vous
-      seriez tenté de faire, et vous présenteront les options et commandes
-      habituelles pour réaliser ces tâches usuelles.
+      seriez amené à faire, et vous présenteront les options et commandes
+      courantes pour les réaliser.
     
    
     
    
-      Chaque section pointe vers la section suivante, vous pourrez suivre
+      Chaque section pointe vers la section suivante, vous pourrez les suivre
       à la manière d'un tutoriel. Chaque page pointera également vers
       une documentation Git plus approfondie comme les pages de manuel
       officielles ou aux sections appropriées du
       Livre Pro Git,
       de cette manière vous pourrez en apprendre plus sur les commandes.
-      Nous commencerons par découvrir comment penser gestion de code source
+      Nous commencerons par découvrir comment penser gestion de sources
       à la manière de Git.
     
    
   
    
@@ -31,55 +31,54 @@ 
    Comment penser à la Git
    
     
    
       La première chose à comprendre sur Git est qu'il
       gère les versions d'une manière totalement différente
-      de Subversion ou Perforce ou tout autre gestionnaire de code source
-      auquel vous pourriez être habitué. Il est souvent plus simple
-      d'apprendre Git en essayant d'oublier toute assertion sur
-      le fonctionnement de la gestion de versions et d'essayer d'y penser
+      de Subversion ou Perforce ou tout autre gestionnaire de sources
+      auquel vous seriez habitué. Il est souvent plus simple
+      d'apprendre Git en mettant de côté toute connaissance sur
+      le fonctionnement de la gestion de sources et d'essayer d'y penser
       à la Git.
     
    
 
     
    
       Partons de zéro. Imaginons que vous conceviez un nouveau système de gestion
-      de code source. Comment gériez-vous simplement différentes versions
+      de sources. Comment gériez-vous simplement différentes versions
       avant d'utiliser un outil dédié à ça ? Il y a de fortes chances pour que vous ayez
       fait de simples copies du répertoire de votre projet pour sauvegarder
       son état à ce moment-là.
     
    
 
-    
     $ cp -R project project.bak 
    
+    
     $ cp -R projet projet.bak 
    
 
     
    
       De cette manière, vous pouvez facilement rétablir des fichiers qui
-      deviendraient inutilisables plus tard, ou pour voir ce que vous avez changé en
-      comparant ce à quoi le projet ressemble maintenant avec ce à quoi il
-      ressemblait lorsque vous l'avez copié.
+      seraient devenus inutilisables plus tard, ou pour voir ce que vous avez changé en
+      comparant l'état du projet actuel avec celui de la copie de sauvegarde.
     
    
 
     
    
-      Si vous êtes réellement paranoïaque, vous le ferez peut-être souvent,
+      Si vous êtes réellement paranoïaque, vous le ferez sûrement souvent,
       et vous inclurez la date dans le nom de la sauvegarde :
     
    
 
-    
     $ cp -R project project.2010-06-01.bak 
    
+    
     $ cp -R projet projet.2010-06-01.bak 
    
 
     
    
       Dans ce cas, vous aurez un tas d'instantanés de votre projet à
       disposition comme source de comparaison et d'inspection. Vous pouvez
       également utiliser cette méthode pour partager de manière plutôt
-      efficace des modifications avec un tiers. Si vous compressez votre
-      projet à un certain état et le mettez sur votre site web, d'autres développeurs
-      peuvent le télécharger, le modifier et vous envoyer un correctif
+      efficace des modifications avec un tiers. Si vous créez une archive compressée
+      de l'état actuel de votre projet et la partagez sur votre site web, d'autres développeurs
+      peuvent la télécharger, modifier votre projet et vous envoyer un correctif
       assez facilement.
     
    
 
     
    - $ wget http://example.com/project.2010-06-01.zip
- $ unzip project.2010-06-01.zip
- $ cp -R project.2010-06-01 project-my-copy
- $ cd project-my-copy
- $ (change something)
- $ diff project-my-copy project.2010-06-01 > change.patch
- $ (email change.patch)
    
+ $ wget http://exemple.com/projet.2010-06-01.zip
+ $ unzip projet.2010-06-01.zip
+ $ cp -R projet.2010-06-01 projet-ma-copie
+ $ cd projet-ma-copie
+ $ (vous faites des modifications)
+ $ diff projet-ma-copie projet.2010-06-01 > modif.patch
+ $ (email modif.patch)
    
 
     
    
       Le développeur original peut alors appliquer le correctif à sa copie
@@ -89,7 +88,7 @@ 
    Comment penser à la Git
    
     
    
 
     
    
-      Ceci fonctionne en fait plutôt bien, alors disons que nous désirons
+      Ceci fonctionne en fait plutôt bien, alors imaginons que nous désirions
       écrire un outil pour effectuer ce processus basique plus rapidement
       et plus facilement. Au lieu d'écrire un outil qui crée des versions
       de chaque fichier individuellement, comme Subversion, nous en écririons
@@ -103,15 +102,15 @@ 
    Comment penser à la Git
    
       un instantané de votre projet avec la commande git commit
       et il va simplement enregistrer l'état de tous les fichiers de votre projet
       à ce moment. Ensuite la plupart des commandes travaillent avec ces enregistrements
-      d'état pour voir comment ils différent ou y récupérer du contenu, etc.
+      d'état pour comparer leurs différences ou y récupérer du contenu, etc..
     
    
 
     
    
 
     
    
-      Si vous pensez à Git comme un outil pour conserver et comparer et fusionner des instantanés
+      Si vous pensez à Git comme un outil pour conserver, comparer et fusionner des instantanés
       de votre projet, il sera plus facile de comprendre ce qui se passe et comment
-      faire différents choses correctement.
+      faire différentes choses correctement.
     
    
 
   
    

From 5adadea93f09a0cf7d64b99e23b7710e081f4c40 Mon Sep 17 00:00:00 2001
From: Benoit Benedetti 
Date: Sun, 28 Feb 2016 12:39:40 +0100
Subject: [PATCH 18/22] fr/basic/index.html: hola mundo => bonjour monde

---
 fr/basic/index.html | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/fr/basic/index.html b/fr/basic/index.html
index 271f38f..708d419 100644
--- a/fr/basic/index.html
+++ b/fr/basic/index.html
@@ -263,7 +263,7 @@ 
    
 
    def self.hello
 -    puts "hello world"
-+    puts "hola mundo"
++    puts "bonjour monde"
    end
 
  end
@@ -316,7 +316,7 @@ 
    
 
    def self.hello
 -    puts "hello world"
-+    puts "hola mundo"
++    puts "bonjour monde"
    end
 
  end
@@ -346,7 +346,7 @@ 
    
 
 +  # says hello
    def self.hello
-     puts "hola mundo"
+     puts "bonjour monde"
    end
 
  end
@@ -360,7 +360,7 @@ 
    
 
    def self.hello
 -    puts "hello world"
-+    puts "hola mundo"
++    puts "bonjour monde"
    end
 
  end
@@ -375,7 +375,7 @@ 
    
 +  # says hello
    def self.hello
 -    puts "hello world"
-+    puts "hola mundo"
++    puts "bonjour monde"
    end
 
  end
@@ -459,8 +459,8 @@ 
    
 $ git add hello.rb 
 $ git status -s
 M  hello.rb
-$ git commit -m 'my hola mundo changes'
-[master 68aa034] my hola mundo changes
+$ git commit -m 'mes modifications bonjour monde'
+[master 68aa034] mes modifications bonjour monde
  1 files changed, 2 insertions(+), 1 deletions(-)
 
    
 

From 529e1594f5b95c93b50f66eec21ebbbaa40b813f Mon Sep 17 00:00:00 2001
From: Benoit Benedetti 
Date: Sun, 28 Feb 2016 14:43:32 +0100
Subject: [PATCH 19/22] FR: fr/basic/index.html review

---
 fr/basic/index.html | 186 +++++++++++++++++++++++---------------------
 1 file changed, 97 insertions(+), 89 deletions(-)

diff --git a/fr/basic/index.html b/fr/basic/index.html
index 708d419..1c1497d 100644
--- a/fr/basic/index.html
+++ b/fr/basic/index.html
@@ -93,9 +93,7 @@ 
    
       vous lui donnez, si vous lui donnez le répertoire de travail courant, il va
       simplement faire le suivi de chaque fichier qui s'y trouve. Dans ce cas,
       la commande git add . aurait donné la même chose que
-      git add README hello.rb, et d'ailleurs également
-      git add *, mais c'est seulement parce-que nous n'avons pas
-      de sous-dossiers, et que * ne pourrait pas les parcourir récursivement.
+      git add README hello.rb.
     
    
 
     
    OK, à présent si nous éditons un de ces fichiers et exécutons
@@ -129,7 +127,7 @@ 
    
       
    Pour voir cette flexibilité de capture en action dans un exemple
         particulièrement intéressant qui ne capture que certaines des
         modifications apportées à un même fichier, voyez l’option
-       « -p » de git add du livre Pro Git.
    
+        « -p » de git add du livre Pro Git.
    
 
 
     
    
@@ -212,7 +210,7 @@ 
    
         
    
           Pour résumer,
           vous exécutez git status pour voir si quoi que ce soit a été
-          modifié ou mis en attente depuis votre dernière validation pour que vous
+          modifié ou mis en attente depuis votre dernier instantané pour que vous
           puissiez décider si vous voulez valider un nouvel instantané et avec quel
           contenu.
         
    
@@ -231,6 +229,16 @@ 
    
       
    
 
       
    
+        
    
+          Git utilise le terme « indexé » pour indiquer l'action qui consiste
+          à mettre une modification en zone d'attente, en vue de son inclusion
+          dans le prochain instantané. En fait, dans la littérature Git, les termes
+          stage (zone d'attente) et index sont interchangeables.
+          On trouve d'ailleurs très souvent le terme index dans les manuels officiels de Git.
+          Nous utiliserons donc le terme « indexer » et
+          l’adjectif « indexé » dans la suite de ce document.
+        
    
+
         
    Il y a deux utilisations principales de la commande git diff.
           Nous allons décrire la première ici, l'autre sera décrite plus loin
           dans la section "Inspection et Comparaison".
@@ -245,7 +253,7 @@ 
    
 
         
    Sans aucun argument, un simple git diff vous affichera au
           format diff unifié (un correctif) ce que vous avez changé comme code ou
-          contenu de votre projet depuis la dernière mise en zone d'attente ou,
+          contenu de votre projet depuis la dernière indexation ou,
           à défaut, le dernier instantané.
         
    
 
@@ -270,7 +278,7 @@ 
    
 
    
 
         
    Là où git status vous affichera quels fichiers ont changé
-          et/ou a été indexé depuis votre dernière validation, git diff
+          et/ou ont été indexés depuis votre dernière validation, git diff
           va vous montrer quels sont concrètement ces changements, ligne par ligne.
           C'est généralement une commande utile à la suite d'un git status.
         
    
@@ -451,7 +459,7 @@ 
    
 
             
    Indexons et validons tous les changements de notre fichier
               hello.rb. Dans ce premier exemple, nous allons utiliser
-              l'option -m pour fournir un message de validation sur la ligne
+              l'option -m pour fournir un message de commit sur la ligne
               de commande.
             
    
 
@@ -467,7 +475,7 @@ 
    
             
    Nous avons désormais enregistré un instantané. Si nous exécutons
               git status à nouveau, nous allons voir que « la copie
               de travail est propre », ce qui signifie que nous n'avons fait aucune
-              modification depuis notre dernière validation—il n'y a aucun
+              modification depuis notre dernier commit—il n'y a aucun
               travail en attente.
    
 
 
    @@ -477,7 +485,7 @@ 
    
 
    
 
               
    Si vous n'utilisez pas l'option -m option, Git va essayer
-                d'ouvrir un éditeur de texte pour écrire votre message de validation.
+                d'ouvrir un éditeur de texte pour écrire votre message de commit.
                 Dans vim, qui est utilisé par défaut à moins que vous
                 n'ayez configuré une alternative à utiliser, votre écran ressemblera
                 vraisemblablement à cela :
@@ -498,12 +506,12 @@ 
    
 ".git/COMMIT_EDITMSG" 9L, 257C
    -

    À ce stade vous ajoutez votre message de validation final au tout +

    À ce stade vous ajoutez votre message de commit final au tout début du document. Toute ligne qui commence par « # » sera ignorée—Git va vous y ajouter la sortie de la commande git status - pour vous rappeler ce que vous avez modifié et mis en attente.

    + pour vous rappeler ce que vous avez modifié et indexé.

    -

    En règle générale, il est très important d'écrire de bons messages de validation. +

    En règle générale, il est très important d'écrire de bons messages de commit. Pour des projets libres, par convention vous écrirez votre message plus ou moins dans ce format :

    @@ -514,7 +522,7 @@

    sur environ 72 caractères. Dans certains cas, la première ligne est traitée comme le sujet d'un email et le reste du texte comme le corps. Le saut de ligne entre le résumé et le corps est très important -(à moins que vous omettiez complétement le corps) ; certains outils git +(à moins que vous omettiez complètement le corps) ; certains outils git peuvent mal fonctionner si vous les mettez l'un après l'autre. Les paragraphes supplémentaires viennent après d'autres sauts de ligne. @@ -540,27 +548,27 @@

    - Le message d'instantané est très important. Étant donné qu'une grande + Le message de commit est très important. Étant donné qu'une grande part de la puissance de Git est cette souplesse dans la création attentionnée - des validations en local pour les partager ensuite, c'est très utile de + des commits en local pour les partager ensuite, c'est très utile de pouvoir écrire trois ou quatre validations sur des modifications indépendantes afin que votre travail puisse être examiné plus facilement par vos pairs. - Étant donné qu'il y a une séparation entre valider et pousser ses modifications, + Étant donné qu'il y a une différence entre créer un commit et pousser ses modifications, prenez bien le temps de faciliter aux personnes avec lesquelles vous travaillez la lecture de ce que vous avez fait en plaçant chaque modification indépendante - dans une validation propre avec un joli message de validation pour que ce soit + dans un commit propre avec un joli message pour que ce soit simple pour eux de voir ce que vous faites et pourquoi.

    git commit -a - indexe automatiquement, avant la validation, toutes les modifications aux fichiers suivis + indexe automatiquement, avant un commit, toutes les modifications aux fichiers suivis

    Si l'étape git add du flux de travail vous paraît lourde, Git vous permet de sauter celle-ci avec l'option -a. Cela va simplement dire à Git d'exécuter git add sur chaque fichier qui est « suivi »—c'est-à-dire, chaque fichier qui fait - partie de votre dernière validation et qui a été modifié. Cela vous permet + partie de votre dernier commit et qui a été modifié. Cela vous permet d'avoir un flux de travail plus proche de celui de Subversion si vous le voulez, en éditant simplement vos fichiers puis en exécutant git commit -a pour réaliser un instantané de tout ce qui a changé. Vous aurez toujours à @@ -590,13 +598,13 @@

    git commit, Git va simplement vous retourner la sortie de la commande git status, pour vous rappeler que rien n'a été indexé. La partie importante de ce message a été mise en exergue, et signifie que - rien n'a été ajouté pour validation. Si vous utilisez -a, - cela va tout ajouter et valider en même temps. + rien n'a été ajouté pour commit. Si vous utilisez -a, + cela va tout ajouter et créer un commit en même temps.

    Cela va vous permettre de finaliser le flux de travail complet des instantanés—vous faites des modifications à vos fichiers, vous utilisez - ensuite git add pour mettre en attente les fichiers que vous avez + ensuite git add pour indexer les fichiers que vous avez modifiés, git status et git diff pour voir ce que vous avez modifié, et finalement git commit pour enregistrer définitivement votre instantané.

    @@ -604,7 +612,7 @@

    Pour résumer, vous exécutez git commit pour enregistrer l'instantané - de votre contenu en attente. Cet instantané peut ensuite être comparé, + de votre contenu indexé. Cet instantané peut ensuite être comparé, partagé et rembobiné au besoin.

    @@ -634,11 +642,11 @@

    Pour commencer, vous pouvez l'utiliser pour enlever quelque chose de placé - accidentellement dans la zone d'attente. Imaginons que vous avez modifié - deux fichiers et que vous vouliez les enregistrer dans deux validations différentes. - Vous devriez faire une mise en attente et validation, puis mettre en attente et valider - l'autre. Si vous avez accidentellement mis les deux en attente, comment - dé-mettre en attente une ? Vous le faites avec + accidentellement dans l'index. Imaginons que vous avez modifié + deux fichiers et que vous vouliez les enregistrer dans deux commits différents. + Vous devriez indexer et faire un commit pour un fichier, puis indexer et faire un commit + pour l'autre. Si vous avez accidentellement indexé les deux, comment + en désindexer un ? Vous le faites avec git reset HEAD -- fichier. Techniquement vous n'avez pas à ajouter le --—il est utilisé pour dire à Git où se termine la liste des options et où commence la liste des chemins, mais c'est probablement une bonne idée @@ -646,9 +654,9 @@

    même si vous n'en avez pas besoin.

    -

    Voyons à quoi cela ressemble de sortir quelque chose de la zone d'attente. - Ici nous avons deux fichiers qui ont été modifiés depuis notre dernière validation. - Nous allons les mettre en attente tous les deux, puis en sortir un des deux.

    +

    Voyons à quoi cela ressemble de désindexer quelque chose. + Ici nous avons deux fichiers qui ont été modifiés depuis notre dernier commit. + Nous allons les indexer tous les deux, puis en désindexer un des deux.

     $ git status -s
@@ -672,12 +680,12 @@ 
    
                   
    
 
                   
    
-                    Si vous êtes curieux, ce Git fait concrètement ici est de recaler
-                    la somme de contrôle de l'entrée de ce fichier dans l'« index » à ce qu'elle
+                    Si vous êtes curieux, ce que Git fait concrètement ici est de recaler
+                    la somme de contrôle de l'entrée de ce fichier dans l'index à ce qu'elle
                     était dans la dernière validation. Vu que  git add crée une somme
-                    de contrôle d'un fichier et l'ajoute à l'"index", git reset HEAD
+                    de contrôle d'un fichier et l'ajoute à l'index, git reset HEAD
                     écrase cela avec sa valeur précédente, pour ainsi effectivement le sortir
-                    de la zone d'attente.
+                    de l'index.
                   
    
 
                   
    
@@ -688,12 +696,12 @@ 
    
                     git unstage [fichier] à la place.
                   
    
 
-                  
    Si vous oubliez quelle est la commande pour sortir quelque chose
-                    de la zone d'attente , Git vient à votre aide en vous le rappelant
+                  
    Si vous oubliez quelle est la commande pour désindexer
+                    quelque chose, Git vient à votre aide en vous le rappelant
                     dans la sortie de la commande normale git status.
                     Par exemple, si vous exécutez git status sans le
-                    -s quand vous avez des fichiers en attente, il vous
-                    dira comment les en sortir :
    
+                    -s quand vous avez des fichiers indexés, il vous
+                    dira comment les sortir de l'index :
    
 
 
     $ git status
@@ -712,15 +720,15 @@ 
    
 
                     
    
                       git reset --soft
-                      déplace HEAD vers une référence spécifique de validation, la zone d'attente restant inchangée
+                      déplace HEAD vers une référence spécifique de commit, la zone d'attente restant inchangée
                     
    
 
                     
    La première chose que fait git reset est d'annuler
-                      la dernière validation et remettre les fichiers dans la zone d'attente.
+                      le dernier commit et remettre les fichiers dans l'index.
                       Si vous incluez le drapeau --soft il s'arrête là.
                       Par exemple, si vous exécutez git reset --soft HEAD~
-                      (le parent de HEAD) la dernière validation sera annulée et les fichiers
-                      modifiés seront mis à nouveau dans la zone d'attente.
    
+                      (le parent de HEAD) le dernier commit sera annulé et les fichiers
+                      modifiés seront mis à nouveau dans l'index.
    
 
 
     $ git status -s
@@ -739,7 +747,7 @@ 
    
                       
    Ça fait en gros la même chose que
                         git commit --amend, vous permettant de continuer
                         à travailler avant que vous n'ajoutiez les modifications de fichiers
-                        dans la même validation.
    
+                        dans le même commit.
    
 
                       
    
                         git reset --hard
@@ -776,19 +784,19 @@ 
    
 
                         
    Dans l'exemple ci-dessus, alors que nous avions toutes les modifications
                           prêtes à être validées et ajoutées, un git reset --hard
-                          les a complètement supprimées. Le dossier de travail et la zone d'attente
+                          les a complètement supprimées. Le dossier de travail et l'index
                           sont ré-initialisés à la pointe de la branche courante ou HEAD.
    
 
-                        
    Vous pouvez remplacer HEAD avec le SHA-1 d'une validation
+                        
    Vous pouvez remplacer HEAD avec le SHA-1 d'un commit
                           ou une autre référence vers un parent pour ré-initialiser en un point
                           spécifique.
    
 
                         
    
                           Pour résumer,
-                          vous exécutez git reset HEAD pour annuler la dernière validation,
-                          sortir de la zone d'attente des fichiers sur lesquels vous aviez exécuté
+                          vous exécutez git reset HEAD pour annuler le dernier commit,
+                          sortir de l'index des fichiers sur lesquels vous aviez exécuté
                           git add et que vous ne désirez pas inclure dans le prochain
-                          instantané d'une validation.
    
+                          commit.

    @@ -800,22 +808,21 @@

    livre git rm - supprimer des fichiers de la zone d'attente + supprime des fichiers de l'index

    -

    git rm va supprimer des entrées de la zone d'attente. - C'est un peu différent de git reset HEAD qui enlève des - fichiers de la zone d'attente. Sortir de la zone d'attente signifie - ré-initialiser la zone d'attente à l'état dans lequel elle était avant - que nous commencions à modifier des choses. git rm d'un - autre côté sort simplement le fichier de la zone d'attente, de sorte - qu'il ne sera pas inclus dans le prochain instantané de validation, - le supprimant effectivement ainsi.

    +

    git rm va supprimer des entrées de l'index. + C'est un peu différent de git reset HEAD qui désindexe des + fichiers. Désindexer signifie recaler l'index à l'état dans lequel + il était avant que nous fassions des modifications. git rm d'un + autre côté sort complétement le fichier de l'index, de sorte + qu'il ne sera pas inclus dans le prochain commit, + le supprimant ainsi carrément.

    Par défaut, un git rm file va supprimer complètement - le fichier de la zone d'attente et aussi de votre disque (le dossier + le fichier de l'index et aussi de votre disque (le dossier de travail). Pour laisser le fichier dans le dossier de travail, vous pouvez utiliser git rm --staged.

    @@ -825,12 +832,12 @@

    - Contrairement à la plupart des systèmes de gestion de versions, Git ne - suit pas le renommage des fichiers. À la place, il suit juste les instantanés - et ensuite arrive à comprendre quels fichiers ont pu être renommés - en comparant les instantanés. Si un fichier a été supprimé d'un instantané - et un autre fichier a été ajouté au suivant et leur contenu est similaire, - Git décidera que c'est sûrement un renommage. Alors, bien que la commande + Contrairement à la plupart des systèmes de gestion de sources, Git ne + suit pas le renommage des fichiers. À la place, il suit juste les commits + et arrive par la suite à réaliser quels fichiers ont pu être renommés + en comparant les commits. Si un fichier a été supprimé d'un commit + et un autre fichier a été ajouté au suivant avec un contenu similaire, + Git supposera que c'est sûrement un renommage. Alors, bien que la commande git mv existe, elle est superflue—tout ce qu'elle fait est un git rm --staged, renomme le fichier sur le disque, puis exécute un git add sur le nouveau fichier. Vous n'avez pas vraiment besoin @@ -838,7 +845,7 @@

    - Dans sa forme commune la commande est utilisée pour supprimer les fichiers. + La commande est communément utilisée pour supprimer les fichiers. Mais il est souvent plus simple de juste supprimer les fichiers du disque puis exécuter git commit -a, ce qui va également automatiquement les supprimer de l'index.

    @@ -859,32 +866,32 @@

    livre git stash - sauvegarder des modifications faites dans l'index courant et le dossier de travail pour plus tard + remise pour plus tard des modifications faites dans l'index et le dossier de travail

    Vous êtes au beau milieu de modifications mais quelque chose se présente - qui nécessite que vous vous en occupiez, comme une si urgente-tout-de-suite + qui nécessite que vous vous en occupiez, comme une très-très-urgente correction de bug, mais ne souhaitez pas valider ou perdre vos modifications en cours. git stash est là pour vous.

    git stash - réserve les modifications courantes sur la pile + remise les modifications courantes sur la pile

    -

    Réserver prend l'état courant de votre dossier de travail et de l'index, +

    Un remisage prend l'état courant de votre dossier de travail et de l'index, les place sur une pile pour plus tard, et vous offre en retour un dossier - de travail propre. Cela va vous ramener à l'état de la dernière validation. + de travail propre. Cela va vous ramener à l'état du dernier commit.

    Si vous avez des fichiers non suivis, git stash ne les inclura pas. - Vous pouvez soit les placer en zone d'attente avec git add (vous n'avez - pas à valider) avant de les réserver, ou, si vous avez une version récente de Git + Vous pouvez soit les indexer avec git add (sans faire un commit) + avant de les remiser, ou, si vous avez une version récente de Git (1.7.7 ou plus), vous pouvez utiliser git stash -u pour aussi - réserver des fichiers non versionnés.

    + remiser des fichiers non versionnés.

     $ git status -s
@@ -899,12 +906,12 @@ 
    
 
                           
    
                             git stash list
-                            affiche les réservations présentes sur la pile
+                            affiche les remisages présents sur la pile
                           
    
 
                           
    C'est utile de savoir ce que vous avez stocké sur la pile et c'est la où
                             git stash list entre en jeu. Exécuter cette commande
-                            va vous afficher la liste courante des éléments réservés.
+                            va vous afficher la liste courante des éléments remisés.
                           
    
 
 
    @@ -913,7 +920,8 @@ 
    
 
    
 
                           
    Le dernier élément ajouté sur la pile sera référencé par
-                            stash@{0} et incrémentera ceux déjà présents.
+                            stash@{0} et incrémentera d'une unité la référence
+                            vers les éléments déjà présents.
                           
    
 
 
    @@ -932,12 +940,12 @@ 
    
 
                           
    
                             git stash apply
-                            récupére l'élément depuis la liste de la pile et l'appliquer au dossier de travail courant
+                            récupère l'élément depuis la pile et l'applique au dossier de travail
                           
    
 
-                          
    Quand vous êtes prêt à continuer là où vous en êtiez, exécutez la
-                            commande git stash apply pour récupérer les modifications
-                            sauvegardées dans le dossier de travail.
+                          
    Quand vous êtes prêt à reprendre là où vous en êtiez, exécutez la
+                            commande git stash apply pour appliquer dans le dossier
+                            de travail des modifications remisées.
                           
    
 
 
    @@ -952,9 +960,9 @@ 
    
 no changes added to commit (use "git add" and/or "git commit -a")
 
    
 
-                          
    Par défaut il va appliquer le dernier élément appliqué au dossier
+                          
    Par défaut cela va appliquer le dernier élément remisé au dossier
                             de travail. Ce sera l'élément référencé par stash@{0}.
-                            Vous pouvez récupérer à la place un autre élément réservé si vous le référencez
+                            Vous pouvez récupérer à la place un autre élément remisé si vous le référencez
                             dans la liste des arguments. Par exemple, git stash apply stash@{1}
                             va appliquer l'élément référencé par stash@{1}.
                           
    
@@ -965,12 +973,12 @@ 
    
 
                           
    
                             git stash drop
-                            supprime un élément de la liste de la pile
+                            supprime un élément de la pile
                           
    
 
-                          
    Quand vous en avez fini avec un élément réservé et/ou vous voulez le
+                          
    Quand vous en avez fini avec un élément remisé et/ou vous voulez le
                             supprimer de la liste, exécutez la commande git stash drop.
-                            Par défaut cela va supprimer le dernier élément réservé ajouté. Vous pouvez
+                            Par défaut cela va supprimer le dernier élément remisé ajouté. Vous pouvez
                             aussi supprimer un élément en particulier si vous l'indiquez en tant qu'argument.
                           
    
 
@@ -984,14 +992,14 @@ 
    
 Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
 
    
 
-                          
    Si vous voulez supprimer tous les éléments réservés, exécutez juste
+                          
    Si vous voulez supprimer tous les éléments remisés, exécutez juste
                             la commande git stash clear. Mais faites cela seulement
                             si vous êtes sûr d'en avoir fini avec la pile.
                           
    
 
                           
    
                             Pour résumer, exécutez git stash pour rapidement
-                            sauvegarder les modifications que vous n'êtes pas prêt de valider ou sauver, mais
+                            remiser des modifications que vous n'êtes pas prêt à valider ou sauver, mais
                             auxquelles vous voulez revenir après avoir travaillé sur autre chose.
                           
    
 

From e2ababb07c38eb6c0e944773f5c33d2998af2fbe Mon Sep 17 00:00:00 2001
From: Benoit Benedetti 
Date: Sun, 28 Feb 2016 15:44:57 +0100
Subject: [PATCH 20/22] FR: fr/branching/index.html review

---
 fr/branching/index.html | 154 ++++++++++++++++++++--------------------
 1 file changed, 77 insertions(+), 77 deletions(-)

diff --git a/fr/branching/index.html b/fr/branching/index.html
index b689d47..c148544 100644
--- a/fr/branching/index.html
+++ b/fr/branching/index.html
@@ -12,20 +12,20 @@ 
    
   
    
     
    Les branches sont une des nombreuses fonctionnalités intéressantes de Git.
       Si vous avez utilisé d'autres systèmes de gestion de versions, il sera
-      probablement utile d'oublier tout ce que vous savez sur les branches -
-      En fait, il sera encore plus utile de les voir quasiment comme des
+      probablement utile d'oublier tout ce que vous savez sur les branches—En fait,
+      il sera encore plus utile de les voir quasiment comme des
       contextes car c'est la façon la plus courante dont vous allez
-      vous en servir. Quand vous basculez dans des branches, vous changez de
-      contextes de travail et vous pouvez rapidement basculer de l'une à l'autre.
+      vous en servir. Quand vous basculez dans une branche, vous changez de
+      contexte de travail, et vous pouvez rapidement basculer de l'une à l'autre.
     
    
 
     
    
       Pour résumer, vous pouvez créer une branche avec
       git branch (nombranche), basculer dans ce contexte avec
-      git checkout (nombranche), enregistrer un instantané de validation
+      git checkout (nombranche), enregistrer un commit
       depuis ce contexte, puis basculer d'une branche à l'autre facilement.
       Quand vous changez de branche, Git remplace votre dossier de travail
-      avec l'instantané de la dernière validation de cette branche afin que vous
+      avec l'instantané du dernier commit de cette branche afin que vous
       n'ayez pas de multiples dossiers pour de multiples branches. Vous fusionnez
       des branches ensemble avec git merge. Vous pouvez facilement
       faire plusieurs fusions étalées dans le temps depuis la même branche,
@@ -106,8 +106,8 @@

    Vous pouvez voir que nous avons une nouvelle branche. Quand vous créez une - branche de cette manière cela crée la branche basée sur votre dernière validation - donc si à ce stade vous créez des validations puis basculez vers « testing », + branche de cette manière cela crée la branche basée sur votre dernier commit + donc si à ce stade vous créez des commits puis basculez vers « testing », vous rétablirez le contexte de votre dossier de travail à celui où il était lorsque la branche a été créée initialement—Vous pouvez penser à cela comme un signet qui indique où vous en êtes. Voyons cela en action—nous utilisons @@ -148,10 +148,10 @@

    git branch -v - affiche la dernière validation de chaque branche + affiche le dernier commit de chaque branche

    -

    Si nous voulons voir les dernières validations de chaque branche +

    Si nous voulons voir les derniers commits de chaque branche nous pouvons exécuter git branch -v pour les voir.

    @@ -163,14 +163,14 @@ 
    
 
         
    
           git checkout -b (nombranche)
-          crée et bascule immédiatement vers une branche
+          crée puis bascule immédiatement vers une branche
         
    
 
         
    
           Dans la plupart des cas vous voudrez basculer vers la branche immédiatement,
-          afin de pouvoir y travailler puis fusionner dans une branche qui contient
-          seulement du travail stable (comme « master ») plus tard lorsque le travail
-          dans votre nouveau contexte de branche sera stable. Vous pouvez faire cela
+          afin de pouvoir y travailler puis la fusionner plus tard dans une branche qui contient
+          seulement du travail stable (comme « master ») lorsque le travail
+          dans votre nouvelle branche sera stable. Vous pouvez faire cela
           relativement facilement avec
           git branch nouvellebranche; git checkout nouvellebranche,
           mais Git a un raccourci pour cela : git checkout -b nouvellebranche.
@@ -203,7 +203,7 @@ 
    
         
    Vous pouvez voir ici comment nous avons créé une branche, supprimé certains de nos
           fichiers depuis le contexte de cette branche, puis nous sommes retournés dans
           notre branche principale et nous voyons à nouveau nos fichiers. Les branches
-          isolent de manière sécurisée le travail que nous faisons en des contextes
+          isolent de manière sécurisée le travail que nous faisons dans des contextes
           entre lesquels nous pouvons basculer.
    
 
         
    
@@ -262,7 +262,7 @@ 
    
 
             
    Alternativement, vous pouvez exécuter
               git push nom-distant --delete nombranche
-              qui est raccourci pour la syntaxe deux-points (une paire
+              qui est un raccourci de la syntaxe deux-points (une paire
               source:destination) de suppression d'une branche distante.
             
    
 
@@ -320,10 +320,10 @@ 
    
             
    
 
             
    Bien sûr, cela ne marche pas juste pour de simples ajouts et suppressions
-              de fichiers. Git va tout autant fusionner les modifications de fichiers -
-              En fait, il est même très bon pour ça. Par exemple, voyons ce qu'il arrive
-              quand on édite un fichier dans une branche et dans une autre branche
-              nous le renommons et puis l'éditons et enfin nous fusionnons ensemble
+              de fichiers. Git va tout autant fusionner les modifications de fichiers—En
+              fait, il est même très bon pour ça. Par exemple, voyons ce qu'il arrive
+              quand on édite un fichier dans une branche et nous le renommons et puis
+              l'éditons dans une autre branche et enfin nous fusionnons ensemble
               ces branches. Chaos, vous avez dit ? Voyons cela.
             
    
 
@@ -341,9 +341,9 @@

    Nous allons donc commencer par créer une nouvelle branche nommée - « change_class » basculer vers celle-ci afin que vos modifications + « change_class », puis basculer vers celle-ci afin que les modifications de renommage de classe soient isolées. Nous allons changer chaque - instance de « HelloWorld » en « HiWorld ».

    + occurrence de « HelloWorld » en « HiWorld ».

     $ git checkout -b change_class
@@ -416,14 +416,14 @@

    Et bien, il va simplement s'en rendre compte. Notez qu'il n'y a aucun conflit de - fusion et que le fichier qui a été renommé a maintenant le changement de nom - de de classe « HiWorld » qui a été fait dans l'autre branche. Plutôt cool.

    + fusion et que le fichier qui a été renommé a désormais le changement de nom + de classe « HiWorld » qui a été fait dans l'autre branche. Plutôt cool.

    conflits de fusion

    -

    Donc, les fusions Git relèvent de la magie, nous n'avons jamais à traiter +

    Les fusions Git relèvent donc de la magie, nous n'avons jamais à traiter des conflits de fusion ? Pas tout à fait. Dans des situations où un même bloc de code est édité dans différentes branches il n'y a aucun moyen pour un ordinateur de s'y retrouver, alors c'est à nous de nous débrouiller. @@ -441,7 +441,7 @@

    1 files changed, 1 insertions(+), 1 deletions(-) -

    Maintenant nous avons validé un changement d'une ligne dans notre +

    Nous avons alors créé un commit du changement d'une ligne dans notre fichier README dans une branche. Maintenant changeons la même ligne d'une manière différente depuis notre branche « master ».

    @@ -454,7 +454,7 @@

    1 files changed, 1 insertions(+), 1 deletions(-) -

    C'est maintenant le plus rigolo—nous allons fusionner la première +

    Arrive le plus amusant—nous allons fusionner la première branche dans notre branche « master », provoquant un conflit de fusion.

    @@ -502,7 +502,7 @@ 
    
                       du conflit et comment vous l'avez résolu comme affiché ici. Maintenant
                       il est l'heure de marquer notre fichier comme résolu. Avec Git on le fait
                       avec git add—pour dire à Git que le fichier a été résolu
-                      vous devez le mettre en attente.
    
+                      vous devez l'indexer.
    
 
 
     $ git status -s
@@ -514,14 +514,14 @@ 
    
 [master 8d585ea] Merge branch 'fix_readme'
 
    
 
-                      
    Et nous avons alors résolu avec succès notre conflit de fusion et validé
-                        le résultat.
    
+                      
    Et nous avons alors résolu avec succès notre conflit de fusion et créé
+                        un commit avec le résultat.
    
 
                       
    
                         Pour résumer, vous utilisez git merge pour combiner
                         un autre contexte de branche dans votre branche courante. Cela va
                         automatiquement décider comment combiner au mieux les différents instantanés
-                        en un nouvel instantané avec le travail unique à chacune des branches.
+                        en un nouvel instantané avec le travail propre de chaque.

    @@ -534,30 +534,30 @@

    livre git log - affiche l'historique des validations d'une branche + affiche l'historique des commits d'une branche

    -

    Jusqu'à présent nous avons validé des instantanés de votre projet et basculé +

    Jusqu'à présent nous créé des commits des instantanés de votre projet et basculé entre différents contextes isolés, mais comment faire si nous avons oublié comment nous en sommes arrivés à un certain point ? Ou si nous voulons savoir à quel point une branche diffère d'une autre ? Git fournit un outil - qui affiche tous les messages de validations qui vous ont amené jusqu'à - votre instantané courant, appelé git log.

    + qui affiche tous les messages de commits qui vous ont amené jusqu'à + votre commit courant, appelé git log.

    Pour comprendre la commande d'historique, vous devez connaître quelles informations sont stockées quand vous exécutez la commande git commit pour enregistrer un instantané. En plus de la référence - des fichiers et du message de validation et des informations sur l'auteur - de la validation, Git stocke également la validation sur laquelle vous avez + des fichiers et du message de commit et des informations sur l'auteur + du commit, Git stocke également le commit sur laquelle vous avez basé votre instantané. C'est-à-dire que, si vous clonez un projet, quel est l'instantané que vous avez modifié pour obtenir l'instantané que vous - enregistrez ? C'est utile pour connaître le contexte dans quelle mesure + avez enregistré ? C'est utile pour savoir comment le projet est arrivé à cet état et permet à Git de savoir qui a changé quoi. Si Git a l'instantané que vous avez sauvegardé et celui sur lequel vous vous êtes basé, alors il peut automatiquement savoir ce que vous avez changé. - La validation sur laquelle une autre validation est basée est appelée le + Le commit sur lequel un autre commit est basé est appelé le « parent ».

    @@ -565,7 +565,7 @@

    vous pouvez exécuter git log quand vous êtes dans cette branche. Par exemple, si vous exécutez git log dans le projet Hello World sur lequel nous avons travaillé dans cette section, nous allons voir tous les - messages des validations faites. + messages des commits créés. 

    @@ -616,7 +616,7 @@

    Cela nous informe que c'est l'historique du développement de ce projet. - Si les messages de validations sont descriptifs, cela peut nous informer + Si les messages de commit sont descriptifs, cela peut nous informer sur les changements apportés ou qui ont influencé l'état de l'instantané et donc ce qu'il contient.

    @@ -639,7 +639,7 @@

    * 17f4acf first commit -

    Nous pouvons maintenant voir quand le travail a divergé et puis a +

    Nous pouvons alors voir quand le travail a divergé et puis a été fusionné. C'est très pratique pour voir ce qui s'est passé ou quels changements ont été appliqués, mais c'est aussi extrêmement utile pour gérer vos branches. Créons une nouvelle branche, effectuons @@ -694,15 +694,15 @@

    1 files changed, 2 insertions(+), 2 deletions(-) -

    Alors, maintenant imaginons que nous ne travaillons pas sur le projet - pendant quelques temps, nous avons autre chose à faire. Quand nous +

    Imaginons alors que nous ne travaillons pas sur le projet + pendant quelques temps, ayant autre chose à faire. Quand nous y revenons nous voulons en savoir plus sur la branche « erlang » et où nous nous en sommes arrêtés sur la branche master. Juste en regardant le nom de la branche, nous ne pouvons savoir que nous avons fait des modifications en Haskell dans celle-ci, mais en utilisant git log nous pouvons facilement le savoir. Si vous donnez à Git un nom de branche, cela va vous afficher - uniquement les validations qui sont « accessibles » dans l'historique de cette - branche, c'est-à-dire les validations qui ont influencé l'instantané + uniquement les commits qui sont « accessibles » dans l'historique de cette + branche, c'est-à-dire les commits qui ont influencé l'instantané final.

    @@ -721,7 +721,7 @@ 
    
                                   
    De cette manière, c'est très simple de voir que nous avons du code Haskell
                                     inclus dans la branche (mis en surbrillance dans la sortie).
                                     Ce qui est encore plus cool est que nous pouvons facilement dire à Git
-                                    que nous sommes seulement intéressés par les validations qui sont
+                                    que nous sommes seulement intéressés par les commits qui sont
                                     accessibles dans une branche mais non accessibles dans une autre, en d'autres
                                     termes quelles validations sont uniques à une branche par rapport à une autre.
                                   
    
@@ -747,16 +747,16 @@

    Cela nous donne un outil de gestion de branche simple et pratique. - Cela nous permet de facilement voir quelles validations sont uniques - dans quelles branches afin de savoir ce qu'il nous manque et ce que - nous fusionnerions si nous faisions la fusion. + Cela nous permet de facilement voir quels commits sont uniques + à quelles branches afin de savoir ce qu'il nous manque et ce que + nous fusionnerions en cas de fusion.

    Pour résumer, vous pouvez utiliser git log pour lister - l'historique de validation ou lister les changements faits par d'autres - qui ont mené l'instantané jusqu'à l'extrêmité de la branche. Cela vous permet - de voir comment le projet dans ce contexte est arrivé à l'état dans lequel il + l'historique des commits ou lister les changements faits par d'autres + qui ont mené l'instantané jusqu'à la pointe de la branche. Cela vous permet + voir comment dans un contexte le projet est arrivé à l'état dans lequel il est actuellement.

    @@ -777,21 +777,21 @@

    Si vous arrivez à un moment qui est important et vous voulez définitivement - vous souvenir de cet instantané de validation spécifiquement, vous pouvez + vous souvenir de ce commit spécifique, vous pouvez l'étiqueter avec git tag. La commande tag - va basiquement mettre un signet permanent sur une validation spécifique - afin de pouvoir l'utiliser pour le comparer à d'autres validations dans - le futur. C'est souvent utilisé lorsque vous publier une version ou vous + va simplement mettre un signet permanent sur un commit spécifique + afin de pouvoir l'utiliser pour le comparer à d'autres commits dans + le futur. C'est souvent utilisé lorsque vous publiez une version ou vous déployez quelque chose.

    Disons que vous vouliez publier notre projet Hello World en tant - que version « 1.0 ». Nous pouvons étiqueter la dernière validation + que version « 1.0 ». Nous pouvons étiqueter le dernier commit (HEAD) comme « v1.0 » en exécutant git tag -a v1.0. Le -a signifie « fait une étiquette annotée », qui permet de lui ajouter un message d'étiquette, ce que vous voudrez quasiment toujours faire. L'exécuter sans le -a fonctionne aussi, - mais cela n'enregistre pas quand cela a été étiqueté, qui l'a étiqueté, + mais cela n'enregistre pas la date, qui l'a étiqueté, ou ne vous laisse pas ajouter un message d'étiquette. Il est recommandé de toujours créer des étiquettes annotées.

    @@ -799,12 +799,12 @@

    $ git tag -a v1.0 -

    Quand vous exécutez la ocmmande git tag -a, Git +

    Quand vous exécutez la commande git tag -a, Git va ouvrir votre éditeur et vous laisser écrire un message d'étiquette, - tout comme vous écrieriez un message de validation.

    + tout comme vous écririez un message de validation.

    -

    Maintenant, notez que quand vous exécutez git log --decorate, - nous pouvons y voir nos étiquettes.

    +

    Notez alors que quand vous exécutez git log --decorate, + nous pouvons voir nos étiquettes.

     $ git log --oneline --decorate --graph
@@ -822,18 +822,18 @@ 
    
 * 17f4acf first commit
    -

    Si nous faisons des validations supplémentaires, l'étiquette va rester - sur cette validation, nous avons alors cet instantané spécifique étiqueté +

    Si nous faisons des commits supplémentaires, l'étiquette va rester + sur cet commit, nous avons alors cet instantané spécifique étiqueté indéfiniment et nous pourrons toujours comparer de futurs instantanés à celui-ci.

    -

    Nous ne sommes pas limiter à étiqueter la validation sur laquelle nous sommes, - néanmoins. Si nous avons oublié d'étiqueter une validation que nous avons - publiée, nous pouvons rétroactivement l'étiqueter en exécutant la même - commande, mais avec le SHA de la validation à la fin. Par exemple, disons - que nous avons publié la validation 558151a (de plusieurs - validations en arrière) mais avons oublié de l'étiqueter à ce moment-là. - Nous pouvons l'étiqueter maintenant :

    +

    Nous ne sommes pas limités à étiqueter le commit sur lequel nous sommes, + néanmoins. Si nous avons oublié d'étiqueter un commit que nous avons + publiéxe, nous pouvons rétroactivement l'étiqueter en exécutant la même + commande, mais avec le SHA du commit à la fin. Par exemple, disons + que nous avons publié le commit 558151a (de plusieurs + commits en arrière) mais avons oublié de l'étiqueter à ce moment-là. + Nous pouvons alors l'étiqueter :

     $ git tag -a v0.9 558151a
@@ -852,11 +852,11 @@ 
    
 * 17f4acf first commit
    -

    Les étiquettes pointant sur des objet suivis par les extrêmités +

    Les étiquettes pointant sur des objets suivis par les pointes des branches seront automatiquement téléchargées quand vous utilisez la commande fetch sur un dépôt distant. Néanmoins, - les étiquettes qui ne sont pas accessibles depuis les extrêmités - de sbranches seront ignorées. Si vous voulez être sûr que + les étiquettes qui ne sont pas accessibles depuis les pointes + des branches seront ignorées. Si vous voulez être sûr que toutes les étiquettes sont toujours incluses, vous devez inclure l'option --tags.

    @@ -885,8 +885,8 @@

    Pou résumer, vous utilisez git tag pour marquer - une validation ou un point dans votre dépôt comme important. - Cela vous permet de faire référence à cette validation avec + un commit ou un point dans votre dépôt comme important. + Cela vous permet de faire référence à ce commit avec quelque chose de plus mémorable qu'un SHA.

    From da9b22af864cbc49637225c8fb9c43e2b60d3732 Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Sun, 28 Feb 2016 16:18:28 +0100 Subject: [PATCH 21/22] FR: fr/remotes/index.html review --- fr/remotes/index.html | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/fr/remotes/index.html b/fr/remotes/index.html index 676a753..e52269e 100644 --- a/fr/remotes/index.html +++ b/fr/remotes/index.html @@ -17,8 +17,8 @@

    vous devez mettre toutes ces données sur un serveur auquel les autres ont accès. Git rend cela possible en synchronisant vos données avec un autre dépôt. Il n'y a pas de réelle différence entre un serveur et un - client—un dépôt Git est un dépôt Git et vous pouvez les synchroniser - indifféremment entre eux facilement. + client—un dépôt Git est un dépôt Git et vous pouvez synchroniser + des dépôts indifféremment entre eux facilement.

    Dès que vous avez un dépôt Git, que ce soit un que vous hébergez sur votre @@ -30,7 +30,7 @@

    Vous pouvez le faire quand vous êtes en ligne, cela n'a pas à être fait en même temps qu'un commit ou tout autre commande. Généralement - vous ferez un certains nombres de validations localement, puis vous récupérerez + vous ferez un certains nombres de commits localement, puis vous récupérerez les données depuis le dépôt partagé distant à partir duquel vous avez cloné le projet pour être à jour, puis vous pousserez vos modifications en ligne.

    @@ -86,7 +86,7 @@

    origin git@github.com:github/git-reference.git (push) -

    Vous voyez l'URL ici en double car Git permet d'avoir des URLS +

    Vous voyez l'URL ici en double car Git permet d'avoir des URLs différentes pour pousser et récupérer pour chaque dépôt au cas où vous vouliez utiliser des protocoles différents en lecture et en écriture.

    @@ -123,7 +123,7 @@

    distants est arbitraire—tout comme « master » n'a aucune signification spéciale mais est très largement utilisé car git init le configure par défaut, « origin » est souvent utilisé comme nom de dépôt distant car - git clone le configure par défaut comme URL source de clonage. Dans + git clone le configure par défaut comme URL source du clonage. Dans notre cas nous allons appeler ce dépôt distant « github », mais vous pourriez le nommer comme bon vous semblerait.

    @@ -289,18 +289,18 @@

    en local tout donnée non présente en local et vous donnant des marqueurs sur où chaque branche sur ce dépôt distant en était au momemt de la synchronisation. Celles-ci sont appelées « branches distantes » et sont identiques aux branches locales - mis à part que Git ne vous autorisera pas de les extraire—par contre, vous pouvez + mis à part que Git ne vous autorisera pas d'y faire un checkout—par contre, vous pouvez fusionner avec, les comparer à d'autres branches, exécuter des journaux d'historique dessus, etc. Vous faites toutes ces opérations en local une fois votre synchronisation faite.

    -

    La seconde commande qui va récupérer en local des données et la commande - git pull. Cette commande va concrètement exécuter git fetch +

    La seconde commande qui va récupérer en local des données est la commande + git pull. Cette commande va concrètement exécuter un git fetch immédiatemment suivi d'un git merge de la branche de ce dépôt distant qui est suivie par toute branche courante dans laquelle vous êtes. Exécuter les commandes fetch et merge séparément est source de moins de magie et - et moins de problèmes, mais si vous aimez le principe de pull, + de moins de problèmes, mais si vous aimez le principe de pull, vous pouvez le retrouver de manière plus détaillée dans la documentation officielle.

    @@ -341,9 +341,9 @@

    distant devient une branche appelée « github/master » en local. De cette manière vous pouvez fusionner la branche « master » de ce dépôt distant dans la branche locale « master » en exécutant git merge github/master. Ou vous pouvez voir - quelles sont les nouvelles validations en exécutant git log github/master ^master. + quelles sont les nouveaux commits en exécutant git log github/master ^master. Si votre dépôt distant est nommé « origin » il sera plutôt nommé origin/master. - Quasiment tout commande utilisable sur les branches locales est utilisable également + Quasiment toute commande utilisable sur les branches locales est utilisable également sur les branches distantes.

    @@ -374,7 +374,7 @@

    -

    Pour partager vos sympathiques validations avec d'autres, vous avez besoin de pousser +

    Pour partager vos sympathiques commits avec des tiers, vous avez besoin de pousser vos modifications vers un dépôt distant. Pour cela, vous exécutez git push [alias] [branche] qui va tenter de faire de votre [branche] une nouvelle [branche] sur le dépôt distant [alias]. Essayons de le faire en commençant @@ -392,7 +392,7 @@

    Plutôt simple. Désormais si quelqu'un clone ce dépôt il va obtenir exactement - toutes ses validations et tout son historique.

    + tous ses commits et tout son historique.

    Comment faire si vous avez une branche spécifique comme la branche « erlang » créée précédemment et que vous vouliez just partager celle-ci ? Vous pouvez @@ -413,7 +413,7 @@

    une branche « erlang » qu'elle pourra étudier et fusionner. Vous pouvez pousser toute branche de cette manière vers n'importe quel dépôt distant auquel vous avez accès en écriture. Si votre branche est déjà sur le serveur, - Git tentera de la mettre à jour, si elle n'est pas présente, Git l'ajoutera.

    + Git tentera de la mettre à jour. Si elle n'est pas présente, Git l'ajoutera.

    Le dernier problème courant que vous risquez de rencontrer en poussant vers des branches distantes est dans le cas où quelqu'un pousse en même temps. From cd3e7744ac64b51900d6ed67bc0a50745b44274c Mon Sep 17 00:00:00 2001 From: Benoit Benedetti Date: Sun, 28 Feb 2016 16:43:26 +0100 Subject: [PATCH 22/22] FR: fr/inspect/index.html review --- fr/inspect/index.html | 118 +++++++++++++++++++++--------------------- 1 file changed, 59 insertions(+), 59 deletions(-) diff --git a/fr/inspect/index.html b/fr/inspect/index.html index 3308fa5..508c0ca 100644 --- a/fr/inspect/index.html +++ b/fr/inspect/index.html @@ -12,7 +12,7 @@

    Vous avez désormais plusieurs branches dont vous vous servez pour des - besoins éphémères, des fonctionnalités durables et autres. Comment + besoins temporaires, des fonctionnalités durables et autres. Comment vous y retrouver parmi celles-ci ? Git a différents outils pour vous aider à savoir où un travail donné a eu lieu, quelles sont les différences entre deux branches et bien d'autres choses. @@ -20,7 +20,7 @@

    Pour résumer, vous utilisez git log pour retrouver des - validations spécifiques dans l'historique de votre projet—par auteur, date, + commits spécifiques dans l'historique de votre projet—par auteur, date, contenu et historique. Vous pouvez utiliser git diff pour comparer deux points différents dans votre historique—habituellement pour voir de quelle manière deux branches diffèrent ou ce qui a changé entre une version de votre @@ -41,28 +41,28 @@

    Nous avons déjà vu comment utiliser git log pour comparer - des branches, en visualisant les validations d'une branche. (Si vous ne vous + des branches, en visualisant les commits d'une branche (si vous ne vous en souvenez pas, cela ressemble à : git log brancheA ^brancheB). - Cependant, vous pouvez utiliser git log pour rechercher une - validation spécifique. Ici nous allons nous intéresser à certaines options + Cependant, vous pouvez utiliser git log pour rechercher un + commit spécifique. Ici nous allons nous intéresser à certaines options communément utilisées par git log, mais il en existe de très nombreuses. Reportez-vous à la documentation officielle pour la liste complète.

    git log --author - recherche uniquement les validations d'un auteur en particulier + recherche uniquement les commits d'un auteur en particulier

    - Pour filtrer votre historique des validations suivant seulement celles effectuées + Pour filtrer l'historique de vos commits suivant seulement ceux effectués par un auteur en particulier, vous pouvez utiliser l'option --author. - Par exemple, disons que nous recherchons les validations du code source de Git - qui ont été effectuées par Linus. Nous exécuterions quelque chose comme + Par exemple, disons que nous recherchons les commits du code source de Git + qui ont été effectués par Linus. Nous exécuterions quelque chose comme git log --author=Linus. La recherche est sensible à la casse et recherchera aussi l'adresse email. L'exemple suivant utilise l'option - -[nombre], qui limite les résultats aux [nombre] dernières - validations. + -[nombre], qui limite les résultats aux [nombre] derniers + commits. 

    @@ -76,16 +76,16 @@ 
    
 
     
    
       git log --since --before
-      filtre les validations suivant la date de validation
+      filtre les commits suivant leur date
     
    
 
     
    
-      Si vous voulez spécifier un intervalle de temps pour filtrer vos validations,
+      Si vous voulez spécifier un intervalle de temps pour filtrer vos commits,
       vous pouvez utiliser plusieurs options comme  --since
-      et --before, ou vou spouvez aussi utiliser --until
-      et --after. Par exemple, pour voir toutes les validations du projet
+      et --before, ou vous pouvez aussi utiliser --until
+      et --after. Par exemple, pour voir tous les commits du projet
       Git d'il y a trois semaines mais après le 18 Avril, vous pourriez exécuter ceci
-      (Nous allons aussi utiliser --no-merges pour ignorer les validations
+      (nous allons aussi utiliser --no-merges pour ignorer les commits
       de fusion) :
     
    
 
@@ -104,15 +104,15 @@ 
    
 
     
    
       git log --grep
-      filtre les validations suivant les messages de validation
+      filtre les commits suivant leur message
     
    
 
     
    
-      Vous désireriez peut-être également rechercher les validations avec une certaine
-      phrase dans le message de validation. Utilisez --grep pour cela.
-      Disons qu'il y a une validation qui portait sur la variable d'environnement P4EDITOR
-      et que vous vouliez vous remémorer à quoi ressemblaient les modificiations—vous
-      pourriez retrouver cette validation avec --grep.
+      Vous désireriez peut-être également rechercher les commits avec une certaine
+      phrase comme message de commit. Utilisez --grep pour cela.
+      Disons qu'il y ait un commit qui portait sur la variable d'environnement P4EDITOR
+      et que vous vouliez vous remémorer à quoi ressemblaient ses modificiations—vous
+      pourriez retrouver cet commit avec --grep.
     
    
 
 
    @@ -134,14 +134,14 @@ 
    
     
    
       Git va faire un OU logique de tous les arguments --grep et
       --author. Si vous voulez utiliser --grep et
-      --author pour voir toutes les validations qui ont été créées
+      --author pour voir tous les commits qui ont été crééxes
       par quelqu'un et ont un contenu de message spécifique, vous devez utiliser
       l'option --all-match. Dans les exemples nous allons utiliser
-      l'option --format, afin de voir qui est l'auteur de chaque validation.
+      l'option --format, afin de voir qui est l'auteur de chaque commit.
     
    
 
-    
    Si nous recherchons les validations dont le message contient « p4 depo »,
-      nous obtenons ces trois validations :
    
+    
    Si nous recherchons les commits dont le message contient « p4 depo »,
+      nous obtenons ces trois commits :
    
 
 
     $ git log --grep="p4 depo" --format="%h %an %s"
@@ -151,8 +151,8 @@ 
    
 
    
 
       
    Si nous ajoutons l'argument --author=Hausmann,
-        au lieu de filtrer les validations de Simon, il va plutôt nous montrer
-        toutes les validations par Simon ou dont le message contient « p4 depo".
    
+        au lieu de filtrer les commits de Simon, il va plutôt nous montrer
+        toutes les commtis de Simon ou dont le message contient « p4 depo ».
    
 
 
     $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
@@ -172,7 +172,7 @@ 
    
 
    
 
         
    Néanmoins, ajouter --all-match va vous retourner les résultats
-          que vous attendez :
    
+          que vous attendiez :
    
 
 
     $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match
@@ -185,12 +185,12 @@ 
    
           
    
 
           
    
-            Que faire si vos messages de validations sont vraiment mauvais ? Ou si
+            Que faire si vos messages de commits sont vraiment mauvais ? Ou si
             vous recherchez quand une fonction a été rajoutée, ou quand des
             variables ont commencé à être utilisées ? Vous pouvez aussi dire à Git
-            de rechercher parmi les modifications de chaque validation pour une certaine
+            de rechercher parmi les modifications de chaque commit pour une certaine
             chaîne de caractères. Par exemple, si nous voulions trouver quelles
-            validations ont modifié tout ce qui ressemble au nom de function
+            commits ont modifié tout ce qui ressemble au nom de function
             « userformat_find_requirements', nous exécuterions ceci (notez qu'il
             n'y a pas de « = » entre le « -S » et ce que vous recherchez) :
           
    
@@ -217,19 +217,19 @@ 
    
 
           
    
             git log -p
-            affiche le correctif introduit par chaque validation
+            affiche le correctif introduit par chaque commit
           
    
 
           
    
-            Chaque validation est un instantané de votre projet, mais étant donné que
-            chaque validation sait sur quel instantané elle est basée, Git peut toujours
+            Chaque commit est un instantané de votre projet, mais étant donné que
+            chaque commit connaît l'instantané sur lequel il est basé, Git peut toujours
             calculer la différence et vous l'afficher sous forme de correctif. Cela
-            signifie que pour chaque validation vous pouvez obtenir le correctif que
-            cette validation a introduit dans le projet. Vous pouvez le faire soit
-            en exécutant git show [SHA] avec un SHA spécifique de validation,
+            signifie que pour chaque commit vous pouvez obtenir le correctif que
+            ce commit a introduit dans le projet. Vous pouvez le faire soit
+            en exécutant git show [SHA] avec un SHA spécifique de commit,
             ou vous pouvez utiliser git log -p, qui dit à Git de mettre le
-            correctif après chaque validation. C'est un très bon moyen de résumer ce
-            qui est arrivé sur une branche ou entre validations.
+            correctif après chaque commit. C'est un très bon moyen de résumer ce
+            qui est arrivé sur une branche ou entre des commits.
           
    
 
 
    @@ -274,11 +274,11 @@ 
    
 
    
 
           
    C'est un très bon moyen de résumer les changements ou passer en revue
-            une série de validations avant de les fusionner ou de publier quoi que ce soit.
    
+            une série de commits avant de les fusionner ou de publier quoi que ce soit.
    
 
           
    
             git log --stat
-            affiche un résumé des modifications introduites par chaque validation
+            affiche un résumé des modifications introduites par chaque commit
           
    
 
           
    Si vous trouvez l'option -p trop verbeuse, vous pouvez résumer
@@ -307,7 +307,7 @@ 
    
 
    
 
             
    Basiquement les mêmes informations, mais plus succintement—vous pouvez
-              toujours les diférences et quelles fichiers ont été modifiés.
    
+              toujours voir les différences et queles fichiers ont été modifiés.

    @@ -324,17 +324,17 @@

    -

    Enfin, pour voir les changements absolus entre deux instantanés de validations, - vous pouvez utiliser la commande git diff. Ceci est très utilisé +

    Enfin, pour voir les changements absolus entre deux instantanés, + vous pouvez utiliser la commande git diff. C'est utilisé principalement dans deux cas—voir en quoi deux branches diffèrent l'une de l'autre et voir ce qui a changé depuis la publication d'une version - ou tout autre ancien moment donné passé dans l'historique. + ou tout autre moment donné passé dans l'historique. Voyons chacune de ces situations.

    Pour voir ce qui a changé depuis la dernière publication, vous pouvez simplement exécuter git diff [version] (ou tout autre étiquette attribuée à la publication). Par exemple, si vous voulez voir ce qui a changé - dans votre projet depuis la version v0.9, nous pouvons exécuter + dans votre projet depuis la version v0.9, vous pouvez exécuter git diff v0.9.

    @@ -376,17 +376,17 @@

    2 files changed, 3 insertions(+), 3 deletions(-) -

    Pour comparer deux branches divergentes, néanmoins, vous pouvez exécucter +

    Pour comparer deux branches divergentes, néanmoins, vous pouvez exécuter quelque chose de similaire à git diff branchA branchB mais le problème est que cela va faire exactement ce que vous lui demandez—cela va concrètement vous fournir le correctif qui transformerai l'instantané - à l'extrémité de la branche brancheA en l'instantané de l'extrémité de la + à la pointe de la branche brancheA en l'instantané de la pointe de la branche brancheB. Cela signifie que si deux branches ont divergé—elles ont pris des directions différentes—cela va occulter toutes les modifications introduites dans brancheA puis ajouter tout ce qui a été introduit dans brancheB. Ce n'est probablement pas ce que vous voulez—vous voulez les changements ajoutés à brancheB qui ne sont pas dans brancheA, vous voulez donc vraiment les différences - entre là où les deux branches ont divergé et l'extrémité de brancheB. Donc, + là où les deux branches ont divergé et la pointe de brancheB. Donc, si notre historique ressemble à ça :

    @@ -413,10 +413,10 @@ 
    
 
                   
    Vous voyez que cela a ajouté les fichiers erlang et haskell, qui est ce
                     que nous avons fait dans cette branche, mais la sortie revient aussi sur les
-                    changements du fichier ruby que nous avons effetués dans la branche master.
+                    changements du fichier ruby que nous avons effectués dans la branche master.
                     Ce que nous voulons vraiment voir sont juste les changements qui ont été faits
                     dans la branche « erlang » (l'ajout des deux fichiers). Nous pouvons obtenir le
-                    résultat attendu en faisant la différence entre la validation commune de laquelle
+                    résultat attendu en faisant la différence entre le commit commun depuis lequel
                     elles ont divergé :
    
 
 
    @@ -426,13 +426,13 @@ 
    
  2 files changed, 9 insertions(+), 0 deletions(-)
 
    
 
-                    
    C'est ce que nous recherchons, mais nous ne désirons pas à avoir à nous
-                      souvenir de quelle validation les deux branches ont divergé à chaque fois.
+                    
    C'est ce que nous recherchons, mais nous ne désirons pas avoir à nous
+                      souvenir à chaque fois depuis quel commit les deux branches ont divergé.
                       Heureusement, Git a un raccourci pour ça. Si vous exécutez
                       git diff master...erlang (avec trois points entre les noms de
-                      branches), Git va automatiquement savoir quelle est la validation commune
-                      (aussi connue sous le nom de « base de fusion") entre les deux validations et
-                      afficher les modifications en se basant sur celle-ci.
    
+                      branches), Git va automatiquement savoir quel est le commit commun
+                      (aussi connu sous le nom de « base de fusion ») entre les deux commits et
+                      afficher les modifications en se basant sur celui-ci.
    
 
 
     $ git diff --stat master erlang
@@ -452,7 +452,7 @@ 
    
                       
    
 
                       
    En guise de bonus, vous pouvez aussi faire calculer manuellement par Git quelle
-                        serait la base de fusion (la première validation ancêtre commune) entre deux validations
+                        serait la base de fusion (le premier commit parent commun) entre deux commits
                         avec la commande git merge-base :
    
 
 
    @@ -484,5 +484,5 @@

    -

    Et c'est la fin ! Pour plus d'informations, essayez de lire le +

    Et c'est la fin ! Pour plus d'informations, veuillez lire le Livre Pro Git.