Skip to content

Commit

Permalink
[fi] Translated Chapter 2.4
Browse files Browse the repository at this point in the history
  • Loading branch information
jukkah committed Aug 10, 2013
1 parent 336dd54 commit 93983e6
Showing 1 changed file with 18 additions and 18 deletions.
36 changes: 18 additions & 18 deletions fi/02-git-basics/01-chapter2.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -672,31 +672,31 @@ Kuva 2-2. Gitk -historian visualisoija.

Voit nähdä pysyvien muutosten historian ikkunan ylemmässä puoliskossa yhdessä kivan syntyperäkaavion kanssa. Vertailuohjelma ikkunan alemmassa puoliskossa näyttää sinulle napsauttamassasi pysyvässä muutoksessa esitellyt muutokset.

## Undoing Things ##
## Asioiden kumoaminen ##

At any stage, you may want to undo something. Here, we’ll review a few basic tools for undoing changes that you’ve made. Be careful, because you can’t always revert some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong.
Saatat haluta kumota jotain missä tahansa työvaiheessa. Esittelemme tässä muutaman perustyökalun tekemiesi muutosten kumoamiseen. Ole huolellinen, koska et voi aina peruuttaa joitakin näistä kumoamisista. Tämä on yksi muutamasta alueesta Gitissä, joissa voit menettää jonkin verran työtä, jos teet sen väärin.

### Changing Your Last Commit ###
### Viimeisimmän pysyvän muutoksen muuttaminen ###

One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the `--amend` option:
Yksi yleinen kumoaminen tapahtuu, kun teet pysyvän muutoksen liian aikaisin ja mahdollisesti unohdat lisätä joitakin tiedostoja tai sähläät pysyvän muutoksen viestin kanssa. Jos haluat yrittää pysyvää muutosta uudestaan, voit tehdä pysyvän muutoksen `--amend`-optiolla:

$ git commit --amend

This command takes your staging area and uses it for the commit. If you’ve made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same and all you’ll change is your commit message.
Tämä komento ottaa lavastusalueesi ja käyttää sitä pysyvään muutokseen. Jos et ole tehnyt muutoksia viimeisimmän pysyvän muutoksesi jälkeen (esimerkiksi, jos ajat tämän komennon heti edellisen pysyvän muutoksesi jälkeen), tilannekuvasi näyttää tarkalleen samalta ja kaikki, mitä muutat, on pysyvän muutoksesi viesti.

The same commit-message editor fires up, but it already contains the message of your previous commit. You can edit the message the same as always, but it overwrites your previous commit.
Sama pysyvän muutoksen viestin editori aktivoituu, mutta se sisältää jo viestin edellisestä pysyvästä muutoksesta. Voit muokata viestiä samoin kuin aina, mutta se korvaa edellisen pysyvän muutoksesi.

As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this:
Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi lavastaa muutokset tiedostossa, jonka haluat lisätä tähän pysyvään muutokseen, voit tehdä jotakuinkin seuraavasti:

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git add unohtunut_tiedosto
$ git commit --amend

After these three commands, you end up with a single commit — the second commit replaces the results of the first.
Näiden kolmen komennon jälkeen päädyt yhteen pysyvään muutokseen — toinen pysyvä muutos korvaa ensimmäisen.

### Unstaging a Staged File ###
### Lavastetun tiedoston lavastuksen purkaminen ###

The next two sections demonstrate how to wrangle your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let’s say you’ve changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. How can you unstage one of the two? The `git status` command reminds you:
Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia lavastusalueellasi ja työskentelyhakemistossasi. Mukava osa on, että komento, jota käytät selvittääksesi näiden kahden alueen tilan, muistuttaa sinua myös, kuinka peruuttaa muutokset niihin. Sanokaamme, esimerkiksi, että olet muuttanut kahta tiedostoa ja haluat tehdä niistä kaksi erillistä pysyvää muutosta, mutta kirjoitit vahingossa `git add *` ja lavastit ne molemmat. Kuinka voit purkaa toisen lavastuksen? `Git status` -komento muistuttaa sinua:

$ git add .
$ git status
Expand All @@ -708,7 +708,7 @@ The next two sections demonstrate how to wrangle your staging area and working d
# modified: benchmarks.rb
#

Right below the “Changes to be committed” text, it says "use `git reset HEAD <file>...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file:
Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD <file>...` to unstage". Joten, käyttäkäämme tätä neuvoa purkaaksemme `benchmarks.rb`-tiedoston lavastuksen:

$ git reset HEAD benchmarks.rb
benchmarks.rb: locally modified
Expand All @@ -726,11 +726,11 @@ Right below the “Changes to be committed” text, it says "use `git reset HEAD
# modified: benchmarks.rb
#

The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged.
Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muokattu mutta lavastamaton jälleen.

### Unmodifying a Modified File ###
### Muutetun tiedoston muutosten kumoaminen ###

What if you realize that you don’t want to keep your changes to the `benchmarks.rb` file? How can you easily unmodify itrevert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, `git status` tells you how to do that, too. In the last example output, the unstaged area looks like this:
Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutoksetpalauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Jälkimmäisessä esimerkkitulosteessa lavastamaton alue näyttää tältä:

# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
Expand All @@ -739,7 +739,7 @@ What if you realize that you don’t want to keep your changes to the `benchmark
# modified: benchmarks.rb
#

It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do thisif you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says:
Se kertoo sinulle melko selvästi, kuinka hylätä tekemäsi muutokset (ainakin Gitin uudemmat versiot, 1.6.1 ja uudemmat, tekevät tämänjos sinulla on vanhempi versio, suosittelemme lämpimästi sen päivittämistä saadaksesi joitakin näistä mukavammista käytettävyysominaisuuksista). Tehkäämme kuten se sanoo:

$ git checkout -- benchmarks.rb
$ git status
Expand All @@ -750,9 +750,9 @@ It tells you pretty explicitly how to discard the changes you’ve made (at leas
# modified: README.txt
#

You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go.
Voit nähdä, että muutokset on peruutettu. Sinun tulisi myös ymmärtää, että tämä on vaarallinen komento: kaikki tähän tiedostoon tekemäsi muutokset ovat mennyttä — kopioit juuri toisen tiedoston sen päälle. Älä koskaan käytä tätä komentoa ellet ehdottomasti tiedä, ettet halua säilyttää tiedostoa. Jos sinun täytyy ainoastaan saada se pois tieltä, käymme läpi kätkemisen ja haarautumisen seuraavassa luvussa; ne ovat usein parempia tapoja toimia.

Remember, anything that is committed in Git can almost always be recovered. Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see *Chapter 9* for data recovery). However, anything you lose that was never committed is likely never to be seen again.
Muista, että kaikki, mistä on tehty pysyvä muutos Gitiin, voidaan melkein aina palauttaa. Jopa poistetuissa haaroissa olleet tai `--amend`-optiolla ylikirjoitetut pysyvät muutokset voidaan palauttaa (katso *Luku 9* datan palauttamiseksi). Kuitenkin, mitään, minkä hävität ja mistä ei ole tehty pysyvää muutosta, ei nähdä todennäköisesti koskaan uudelleen.

## Working with Remotes ##

Expand Down

0 comments on commit 93983e6

Please sign in to comment.