Permalink
Browse files

Fix enumerated lists markdown 2

It's a follow-up to commit 64736f4.
  • Loading branch information...
1 parent 56b652a commit 908c65d88df35b5bef1b17bf83ef0e3eedfc5d91 @GArik GArik committed Dec 3, 2012
Showing with 296 additions and 296 deletions.
  1. +7 −7 ar/03-git-branching/01-chapter3.markdown
  2. +10 −10 ar/05-distributed-git/01-chapter5.markdown
  3. +7 −7 az/03-git-branching/01-chapter3.markdown
  4. +10 −10 az/05-distributed-git/01-chapter5.markdown
  5. +7 −7 ca/03-git-branching/01-chapter3.markdown
  6. +10 −10 ca/05-distributed-git/01-chapter5.markdown
  7. +3 −3 cs/01-introduction/01-chapter1.markdown
  8. +7 −7 cs/03-git-branching/01-chapter3.markdown
  9. +10 −10 cs/05-distributed-git/01-chapter5.markdown
  10. +7 −7 de/03-git-branching/01-chapter3.markdown
  11. +10 −10 de/05-distributed-git/01-chapter5.markdown
  12. +7 −7 en/03-git-branching/01-chapter3.markdown
  13. +10 −10 en/05-distributed-git/01-chapter5.markdown
  14. +7 −7 es-ni/03-git-branching/01-chapter3.markdown
  15. +10 −10 es-ni/05-distributed-git/01-chapter5.markdown
  16. +7 −7 es/03-git-branching/01-chapter3.markdown
  17. +10 −10 es/05-distributed-git/01-chapter5.markdown
  18. +7 −7 fr/03-git-branching/01-chapter3.markdown
  19. +7 −7 id/03-git-branching/01-chapter3.markdown
  20. +7 −7 it/03-git-branching/01-chapter3.markdown
  21. +7 −7 ja/03-git-branching/01-chapter3.markdown
  22. +10 −10 ja/05-distributed-git/01-chapter5.markdown
  23. +10 −10 mk/05-distributed-git/01-chapter5.markdown
  24. +7 −7 nl/03-git-branching/01-chapter3.markdown
  25. +10 −10 nl/05-distributed-git/01-chapter5.markdown
  26. +7 −7 no-nb/03-git-branching/01-chapter3.markdown
  27. +10 −10 no-nb/05-distributed-git/01-chapter5.markdown
  28. +7 −7 pl/03-git-branching/01-chapter3.markdown
  29. +7 −7 ru/03-git-branching/01-chapter3.markdown
  30. +10 −10 ru/05-distributed-git/01-chapter5.markdown
  31. +7 −7 th/03-git-branching/01-chapter3.markdown
  32. +10 −10 th/05-distributed-git/01-chapter5.markdown
  33. +7 −7 tr/03-git-branching/01-chapter3.markdown
  34. +10 −10 tr/05-distributed-git/01-chapter5.markdown
  35. +7 −7 zh-tw/03-git-branching/01-chapter3.markdown
  36. +10 −10 zh-tw/05-distributed-git/01-chapter5.markdown
@@ -96,16 +96,16 @@ Let’s see why you should do so.
Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
-1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.
+1. Do work on a web site.
+2. Create a branch for a new story you’re working on.
+3. Do some work in that branch.
At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
-1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.
+1. Revert back to your production branch.
+2. Create a branch to add the hotfix.
+3. After it’s tested, merge the hotfix branch, and push to production.
+4. Switch back to your original story and continue working.
### Basic Branching ###
@@ -24,12 +24,12 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma
Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2):
-1. The project maintainer pushes to their public repository.
-2. A contributor clones that repository and makes changes.
-3. The contributor pushes to their own public copy.
-4. The contributor sends the maintainer an e-mail asking them to pull changes.
-5. The maintainer adds the contributor’s repo as a remote and merges locally.
-6. The maintainer pushes merged changes to the main repository.
+1. The project maintainer pushes to their public repository.
+2. A contributor clones that repository and makes changes.
+3. The contributor pushes to their own public copy.
+4. The contributor sends the maintainer an e-mail asking them to pull changes.
+5. The maintainer adds the contributor’s repo as a remote and merges locally.
+6. The maintainer pushes merged changes to the main repository.
Insert 18333fig0502.png
Figure 5-2. Integration-manager workflow.
@@ -40,10 +40,10 @@ This is a very common workflow with sites like GitHub, where it’s easy to fork
This is a variant of a multiple-repository workflow. It’s generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. The benevolent dictator’s repository serves as the reference repository from which all the collaborators need to pull. The process works like this (see Figure 5-3):
-1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
-2. Lieutenants merge the developers’ topic branches into their master branch.
-3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
-4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
+1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
+2. Lieutenants merge the developers’ topic branches into their master branch.
+3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
+4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
Insert 18333fig0503.png
Figure 5-3. Benevolent dictator workflow.
@@ -96,16 +96,16 @@ Let’s see why you should do so.
Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
-1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.
+1. Do work on a web site.
+2. Create a branch for a new story you’re working on.
+3. Do some work in that branch.
At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
-1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.
+1. Revert back to your production branch.
+2. Create a branch to add the hotfix.
+3. After it’s tested, merge the hotfix branch, and push to production.
+4. Switch back to your original story and continue working.
### Basic Branching ###
@@ -24,12 +24,12 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma
Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2):
-1. The project maintainer pushes to their public repository.
-2. A contributor clones that repository and makes changes.
-3. The contributor pushes to their own public copy.
-4. The contributor sends the maintainer an e-mail asking them to pull changes.
-5. The maintainer adds the contributor’s repo as a remote and merges locally.
-6. The maintainer pushes merged changes to the main repository.
+1. The project maintainer pushes to their public repository.
+2. A contributor clones that repository and makes changes.
+3. The contributor pushes to their own public copy.
+4. The contributor sends the maintainer an e-mail asking them to pull changes.
+5. The maintainer adds the contributor’s repo as a remote and merges locally.
+6. The maintainer pushes merged changes to the main repository.
Insert 18333fig0502.png
Figure 5-2. Integration-manager workflow.
@@ -40,10 +40,10 @@ This is a very common workflow with sites like GitHub, where it’s easy to fork
This is a variant of a multiple-repository workflow. It’s generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. The benevolent dictator’s repository serves as the reference repository from which all the collaborators need to pull. The process works like this (see Figure 5-3):
-1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
-2. Lieutenants merge the developers’ topic branches into their master branch.
-3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
-4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
+1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
+2. Lieutenants merge the developers’ topic branches into their master branch.
+3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
+4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
Insert 18333fig0503.png
Figure 5-3. Benevolent dictator workflow.
@@ -96,16 +96,16 @@ Let’s see why you should do so.
Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
-1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.
+1. Do work on a web site.
+2. Create a branch for a new story you’re working on.
+3. Do some work in that branch.
At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
-1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.
+1. Revert back to your production branch.
+2. Create a branch to add the hotfix.
+3. After it’s tested, merge the hotfix branch, and push to production.
+4. Switch back to your original story and continue working.
### Basic Branching ###
@@ -24,12 +24,12 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma
Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2):
-1. The project maintainer pushes to their public repository.
-2. A contributor clones that repository and makes changes.
-3. The contributor pushes to their own public copy.
-4. The contributor sends the maintainer an e-mail asking them to pull changes.
-5. The maintainer adds the contributor’s repo as a remote and merges locally.
-6. The maintainer pushes merged changes to the main repository.
+1. The project maintainer pushes to their public repository.
+2. A contributor clones that repository and makes changes.
+3. The contributor pushes to their own public copy.
+4. The contributor sends the maintainer an e-mail asking them to pull changes.
+5. The maintainer adds the contributor’s repo as a remote and merges locally.
+6. The maintainer pushes merged changes to the main repository.
Insert 18333fig0502.png
Figure 5-2. Integration-manager workflow.
@@ -40,10 +40,10 @@ This is a very common workflow with sites like GitHub, where it’s easy to fork
This is a variant of a multiple-repository workflow. It’s generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. All the lieutenants have one integration manager known as the benevolent dictator. The benevolent dictator’s repository serves as the reference repository from which all the collaborators need to pull. The process works like this (see Figure 5-3):
-1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
-2. Lieutenants merge the developers’ topic branches into their master branch.
-3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
-4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
+1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
+2. Lieutenants merge the developers’ topic branches into their master branch.
+3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
+4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
Insert 18333fig0503.png
Figure 5-3. Benevolent dictator workflow.
@@ -112,9 +112,9 @@ Oblast připravených změn je jednoduchý soubor, většinou uložený v adres
Standardní pracovní postup vypadá v systému Git následovně:
-1. Změníte soubory ve svém pracovním adresáři.
-2. Soubory připravíte k uložení tak, že vložíte jejich snímky do oblasti připravených změn.
-3. Zapíšete revizi. Snímky souborů, uložené v oblasti připravených změn, se trvale uloží do adresáře Git.
+1. Změníte soubory ve svém pracovním adresáři.
+2. Soubory připravíte k uložení tak, že vložíte jejich snímky do oblasti připravených změn.
+3. Zapíšete revizi. Snímky souborů, uložené v oblasti připravených změn, se trvale uloží do adresáře Git.
Nachází-li se konkrétní verze souboru v adresáři Git, je považována za zapsanou. Pokud je modifikovaná verze přidána do oblasti připravených změn, je považována za připravenou k zapsání. A pokud byla od posledního checkoutu změněna, ale nebyla připravena k zapsání, je považována za změněnou. O těchto stavech, způsobech jak je co nejlépe využívat nebo i o tom, jak přeskočit proces připravení souborů, se dozvíte v kapitole 2.
@@ -96,16 +96,16 @@ Podívejme se, jaké výhody jim z toho plynou.
Vytvořme si jednoduchý příklad větvení a slučování s pracovním postupem, který můžete využít i v reálném životě. Budete provádět tyto kroky:
-1. Pracujete na webových stránkách.
-2. Vytvoříte větev pro novou část stránek, v níž budete pracovat.
-3. Vytvoříte práci v této větvi.
+1. Pracujete na webových stránkách.
+2. Vytvoříte větev pro novou část stránek, v níž budete pracovat.
+3. Vytvoříte práci v této větvi.
V tomto okamžiku vám zavolají, že se vyskytla jiná kritická chyba, která vyžaduje hotfix. Uděláte následující:
-1. Vrátíte se zpět na produkční větev.
-2. Vytvoříte větev pro přidání hotfixu.
-3. Po úspěšném otestování začleníte větev s hotfixem a odešlete ji do produkce.
-4. Přepnete zpět na svou původní část a pokračujete v práci.
+1. Vrátíte se zpět na produkční větev.
+2. Vytvoříte větev pro přidání hotfixu.
+3. Po úspěšném otestování začleníte větev s hotfixem a odešlete ji do produkce.
+4. Přepnete zpět na svou původní část a pokračujete v práci.
### Základní větvení ###
@@ -24,12 +24,12 @@ Tento pracovní postup může být pro mnoho lidí zajímavý, protože je to sc
Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze použít pracovní postup, kdy má každý vývojář oprávnění k zápisu do vlastního veřejného repozitáře a oprávnění pro čtení k repozitářům všech ostatních. Tento scénář často zahrnuje jeden standardní repozitář, který reprezentuje „oficiální“ projekt. Chcete-li do tohoto projektu přispívat, vytvořte vlastní veřejný klon projektu a odešlete do něj změny, které jste provedli. Poté odešlete správci hlavního projektu žádost, aby do projektu natáhl vaše změny. Váš repozitář může přidat jako vzdálený repozitář, lokálně otestovat vaše změny, začlenit je do své větve a odeslat zpět do svého repozitáře. Postup práce je následující (viz obrázek 5-2):
-1. Správce projektu odešle data do svého veřejného repozitáře.
-2. Přispěvatel naklonuje tento repozitář a provede změny.
-3. Přispěvatel odešle změny do své vlastní veřejné kopie.
-4. Přispěvatel pošle správci e-mail s žádostí, aby natáhl změny do projektu.
-5. Správce přidá repozitář přispěvatele jako vzdálený repozitář a provede lokální začlenění.
-6. Správce odešle začleněné změny do hlavního repozitáře.
+1. Správce projektu odešle data do svého veřejného repozitáře.
+2. Přispěvatel naklonuje tento repozitář a provede změny.
+3. Přispěvatel odešle změny do své vlastní veřejné kopie.
+4. Přispěvatel pošle správci e-mail s žádostí, aby natáhl změny do projektu.
+5. Správce přidá repozitář přispěvatele jako vzdálený repozitář a provede lokální začlenění.
+6. Správce odešle začleněné změny do hlavního repozitáře.
Insert 18333fig0502.png
Obrázek 5-2. Pracovní postup s integračním manažerem
@@ -40,10 +40,10 @@ Tento pracovní postup je velmi rozšířený na stránkách jako GitHub, kde je
Jedná se o variantu pracovního postupu s více repozitáři. Většinou se používá u obřích projektů se stovkami spolupracovníků. Možná nejznámějším příkladem je vývoj jádra Linuxu. Několik různých integračních manažerů odpovídá za konkrétní části repozitáře – říká se jím poručíci (lieutenants). Všichni poručíci mají jednoho integračního manažera, kterému se říká „benevolentní diktátor“. Repozitář benevolentního diktátora slouží jako referenční repozitář, z nějž všichni spolupracovníci musí stahovat data. Postup práce je následující (viz obrázek 5-3):
-1. Stálí vývojáři pracují na svých tematických větvích a přeskládávají svou práci na vrchol hlavní větve. Hlavní větev je větev diktátora.
-2. Poručíci začleňují tematické větve vývojářů do svých hlavních větví.
-3. Diktátor začleňuje hlavní větve poručíků do své hlavní větve.
-4. Diktátor odesílá svou hlavní větev do referenčního repozitáře, aby si na jeho základě mohli ostatní vývojáři přeskládat data.
+1. Stálí vývojáři pracují na svých tematických větvích a přeskládávají svou práci na vrchol hlavní větve. Hlavní větev je větev diktátora.
+2. Poručíci začleňují tematické větve vývojářů do svých hlavních větví.
+3. Diktátor začleňuje hlavní větve poručíků do své hlavní větve.
+4. Diktátor odesílá svou hlavní větev do referenčního repozitáře, aby si na jeho základě mohli ostatní vývojáři přeskládat data.
Insert 18333fig0503.png
Obrázek 5-3. Pracovní postup s benevolentním diktátorem
@@ -103,16 +103,16 @@ Lass uns mal sehen, warum du das machen solltest.
Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branching und Zusammenführen du im echten Leben verwenden kannst. Folge einfach diesen Schritten:
-1. Arbeite an einer Webseite.
-2. Erstell einen Branch für irgendeine neue Geschichte, an der du arbeitest.
-3. Arbeite in dem Branch.
+1. Arbeite an einer Webseite.
+2. Erstell einen Branch für irgendeine neue Geschichte, an der du arbeitest.
+3. Arbeite in dem Branch.
In diesem Augenblick kommt ein Anruf, dass ein kritisches Problem aufgetreten ist und sofort gelöst werden muss. Du machst folgendes:
-1. Geh zurück zu deinem "Produktiv"-Zweig.
-2. Erstelle eine Branch für den Hotfix.
-3. Nach dem Testen führst du den Hotfix-Branch mit dem "Produktiv"-Branch zusammen.
-4. Schalte wieder auf deine alte Arbeit zurück und werkel weiter.
+1. Geh zurück zu deinem "Produktiv"-Zweig.
+2. Erstelle eine Branch für den Hotfix.
+3. Nach dem Testen führst du den Hotfix-Branch mit dem "Produktiv"-Branch zusammen.
+4. Schalte wieder auf deine alte Arbeit zurück und werkel weiter.
### Branching Grundlagen ###
Oops, something went wrong.

0 comments on commit 908c65d

Please sign in to comment.