Merge pull request #12 from progit/fix_compilation_errors

fix compilation errors

Author: wencywww

book/01-introduction/sections/about-version-control.asc

@@ -20,7 +20,7 @@
 За да се справят с това неудобство, програмистите отдавна разбработиха локални VCS с прости бази данни, които съхраняваха промените по файловете, които се проследяват.
 
 .Локален контрол на версиите
-image::images/local.png[Локален контрол на версиите, диаграма]
+image::images/local.png["Локален контрол на версиите, диаграма"]
 
 Една от най-популярните подобни системи се нарича RCS и все още се разпространява с много компютри и до днес.
 https://www.gnu.org/software/rcs/[RCS] работи съхранявайки множество от пачове (разликите във файловете) в специален формат на диска и може да възстанови състоянието на файла към произволен момент добавяйки всички тези пачове.
@@ -34,7 +34,7 @@ https://www.gnu.org/software/rcs/[RCS] работи съхранявайки м
 В продължение на много години това беше стандарт за контрол на версиите.
 
 .Централизиран контрол на версиите
-image::images/centralized.png[Централизиран контрол на версиите, диаграма]
+image::images/centralized.png["Централизиран контрол на версиите, диаграма"]
 
 Този подход предлага много предимства, особено спрямо локалните VCS.
 Например, всеки участник в проекта е запознат в доста добра степен на достоверност какво друг е правил по него.
@@ -55,7 +55,7 @@ image::images/centralized.png[Централизиран контрол на в
 Всяко копие по същество е пълен архив на всички данни.
 
 .Разпределен контрол на версиите
-image::images/distributed.png[Разпределен контрол на версиите, диаграма]
+image::images/distributed.png["Разпределен контрол на версиите, диаграма"]
 
 В допълнение, много от тези системи се справят доста добре със задачата да могат да обслужват няколко отдалечени хранилища, така че можете да си сътрудничите с различни групи от разработчици едновременно, в рамките на един и същи проект.
 Това позволява да създадете няколко различни работни потока, което е невъзможно в централизираните системи като йерархични модели.

book/01-introduction/sections/help.asc

@@ -18,7 +18,7 @@ $ git help config
 ----
 
 Тези команди са полезни, защото имате достъп до тях винаги, дори когато сте офлайн.
-Ако помощните страници и тази книга не са достатъчни в специфични ситуации, можете да опитате `#git` или `#github` каналите на Freenode IRC сървъра на адрес https://freenode.net[].
+Ако помощните страници и тази книга не са достатъчни в специфични ситуации, можете да опитате `\#git` или `\#github` каналите на Freenode IRC сървъра на адрес https://freenode.net[].
 Тези канали редовно са пълни със стотици потребители напреднали с Git и нямащи нищо против да помагат.(((IRC)))
 
 В допълнение, ако не се нуждаете от пълната manpage документация, а само от кратко пояснение за опциите на конкретна команда, можете да използвате параметрите `-h` or `--help` така:

book/02-git-basics/sections/recording-changes.asc

@@ -219,15 +219,15 @@ $ cat .gitignore
 
 Правилата за маските, които можете да включвате в `.gitignore` файла са както следва:
 
-*  Празните редове и редовете започащи с `#` се игнорират.
+*  Празните редове и редовете започащи с `\#` се игнорират.
 *  Работят стандартните глобални правила за маски и те ще бъдат приложени рекурсивно по цялото работно дърво.
 *  Можете да започвате маските с (`/`) за да избегнете рекурсия.
 *  Можете да завършвате маските с (`/`) за да указвате директория.
 *  Можете да обърнете логиката на маската като я започнете с (`!`).
 
 Глобалните правила са подобни на опростени регулярни изрази, които шеловете използват.
-Звездичката (`*`) търси за нула или повече символа; `[abc]` търси за кой да е символ в скобите (в този случай a, b, или c); въпросителният знак (`?`) търси единичен символ; символи в скоби с тире между тях (`[0-9]`) търсят за произволен символ в обхвата между символите (в този случай от 0 до 9).
-Можете да използвате две звездички за да търсите в под-директории; `a/**/z` ще открие `a/z`, `a/b/z`, `a/b/c/z`, и т.н.
+Звездичката (`\*`) търси за нула или повече символа; `[abc]` търси за кой да е символ в скобите (в този случай a, b, или c); въпросителният знак (`?`) търси единичен символ; символи в скоби с тире между тях (`[0-9]`) търсят за произволен символ в обхвата между символите (в този случай от 0 до 9).
+Можете да използвате две звездички за да търсите в под-директории; `a/\*\*/z` ще открие `a/z`, `a/b/z`, `a/b/c/z`, и т.н.
 
 Ето друг примерен `.gitignore` файл:
 
@@ -563,7 +563,7 @@ $ git rm --cached README
 $ git rm log/\*.log
 ----
 
-Отбележете обратния слеш (`\`) преди звездичката `*`.
+Отбележете обратния слеш (`\`) преди звездичката `\*`.
 Това е нужно, защото Git прави своя собствена развивка на имената на файлове в допълнение към развивката, която прави шела.
 Тази команда премахва всички файлове с разширение `.log` намиращи се в директорията `log/`.
 Можете да направите и следното:

book/03-git-branching/sections/rebasing.asc

@@ -171,7 +171,7 @@ image::images/perils-of-rebasing-3.png["Някой изпраща към сър
 
 [[_merge_rebase_work]]
 .Вие сливате в същата работа отново, в нов merge commit
-image::images/perils-of-rebasing-4.png[Вие сливате в същата работа отново, в нов merge commit]
+image::images/perils-of-rebasing-4.png["Вие сливате в същата работа отново, в нов merge commit"]
 
 Ако пуснете `git log` в история като тази, ще видите два къмита с един и същи автор, дата и съобщение, което ще е доста смущаващо.
 По-нататък, ако изпратите тази история обратно към сървъра, ще запишете допълнително в него всички тези пребазирани къмити, което би объркало допълнително хората в бъдеще.

book/06-github/sections/1-setting-up-account.asc

@@ -33,12 +33,12 @@ GitHub предоставя почти всичките си функции бе
 Отворете настройките на акаунта през линка в горната дясна част на прозореца:
 
 ."`Account settings`" линк
-image::images/account-settings.png["`Account settings`" линк]
+image::images/account-settings.png[“Account settings” линк]
 
 След това, изберете "`SSH keys`" секцията отляво.
 
 ."`SSH keys`" линк
-image::images/ssh-keys.png["`SSH keys`" линк]
+image::images/ssh-keys.png[“SSH keys” линк]
 
 Оттук, натиснете бутона "`Add an SSH key`", дайте описателно име на ключа, вмъкнете съдържанието на файла ви `~/.ssh/id_rsa.pub` (или както сте го кръстили) в text area полето и натиснете "`Add key`".
 
@@ -55,7 +55,7 @@ image::images/ssh-keys.png["`SSH keys`" линк]
 Отворете секцията "`Profile`" (над SSH Keys) и натиснете "`Upload new picture`".
 
 ."`Profile`" линк
-image::images/your-profile.png["`Profile`" линк]
+image::images/your-profile.png[“Profile” линк]
 
 Ние сме избрали копие на Git логото на нашия диск и след това получаваме възможност да го изрежем.
 

book/06-github/sections/2-contributing.asc

@@ -21,7 +21,7 @@
 За да fork-нете проект, отворете страницата на съответното хранилище и натиснете "`Fork`" бутона в горната дясна част на страницата.
 
 .Бутонът "`Fork`"
-image::images/forkbutton.png[Бутонът "`Fork`"]
+image::images/forkbutton.png[Бутонът “Fork”]
 
 След няколко секунди, ще бъдете прехвърлени към новата страница на проекта, където вече ще имате права за писане.
 
@@ -61,7 +61,7 @@ GitHub е проектиран да следва специфичен модел
 Да кажем, че Tony търси определен код, който да стартира на своя програмируем микроконтролер Arduino и го е открил в GitHub хранилището на адрес https://github.com/schacon/blink[].
 
 .Проектът, в който искаме да сътрудничим
-image::images/blink-01-start.png[Проектът, в който искаме да сътрудничим]
+image::images/blink-01-start.png["Проектът, в който искаме да сътрудничим"]
 
 Кодът е ОК, единственият проблем е, че скоростта на примигване е твърде висока и решаваме да я намалим до веднъж на 3 секунди, вместо всяка секунда.
 Така че, нека променим програмата и да изпратим промяната си като предложим тя да бъде интегрирана в главния проект.
@@ -122,7 +122,7 @@ To https://github.com/tonychacon/blink
 
 Сега, ако се върнем обратно в сайта с нашето копие, ще видим че GitHub е установил, че сме публикували нов topic клон и ще ни предложи голям зелен бутон с чиято помощ да проверим промените и да създадем Pull Request към оригиналния проект.
 
-Можете също така да отворите "`Branches`" страницата на адрес `https://github.com/<user>/<project>/branches` за да намерите вашия клон и да създадете Pull Request директно оттам.
+Можете също така да отворите "`Branches`" страницата на адрес `\https://github.com/<user>/<project>/branches` за да намерите вашия клон и да създадете Pull Request директно оттам.
 
 .Pull Request бутон
 image::images/blink-02-pr.png[Pull Request бутон]
@@ -227,7 +227,7 @@ GitHub ще тества това за вас и ще ви уведомява с
 
 [[_pr_fail]]
 .Pull Request, който не се слива чисто
-image::images/pr-01-fail.png[Pull Request, който не се слива чисто]
+image::images/pr-01-fail.png["Pull Request, който не се слива чисто"]
 
 Ако видите нещо като <<_pr_fail>>, ще трябва да поправите вашия клон, така че да стане отново "зелен" и да не се налага собственикът на проекта да извършва допълнителни дейности.
 
@@ -301,8 +301,8 @@ image::images/pr-02-merge-fix.png[Pull Request-ът сега се слива ч
 
 Нека започнем с това как да направим cross-reference към друг Pull Request или Issue.
 Към всеки Pull Request или Issue се асоциира номер и тези номера са уникални в рамките на проекта.
-Например, не можете да имате Pull Request #3 _и_ Issue #3.
-Ако искате да създадете указател към всеки Pull Request или Issue от кой да е друг такъв, можете просто да въведете `#<num>` във всеки ваш коментар или описание.
+Например, не можете да имате Pull Request \#3 _и_ Issue \#3.
+Ако искате да създадете указател към всеки Pull Request или Issue от кой да е друг такъв, можете просто да въведете `\#<num>` във всеки ваш коментар или описание.
 Можете да бъдете и по-специфични, ако Pull Request-ът се намира някъде другаде; напишете `username#<num>` ако се обръщате към Issue или Pull Request във fork на хранилището, в което се намирате. Или дори `username/repo#<num>` за да укажете обект от съвсем друго хранилище.
 
 Нека погледнем един пример.

book/06-github/sections/3-maintaining.asc

@@ -9,16 +9,16 @@
 Започваме натискайки бутона "`New repository`" в дясната част на екрана или натискайки бутона `+` в горния тулбар до потребителското ни име както можем да видим в <<_new_repo_dropdown>>.
 
 .Частта "`Your repositories`"
-image::images/newrepo.png[Частта "`Your repositories`"]
+image::images/newrepo.png[Частта “Your repositories”]
 
 [[_new_repo_dropdown]]
 .Падащият списък "`New repository`"
-image::images/new-repo.png[Падащият списък "`New repository`"]
+image::images/new-repo.png[Падащият списък “New repository”]
 
 Това ни прехвърля към формата "`new repository`":
 
 .Формата "`new repository`"
-image::images/newrepoform.png[Формата "`new repository`"]
+image::images/newrepoform.png[Формата “new repository”]
 
 На практика, единственото задължително поле е това с името на проекта, всички останали са незадължителни.
 Засега просто натиснете бутона "`Create Repository`" и вече разполагате с ново хранилище в GitHub, с име `<user>/<project_name>`.
@@ -27,7 +27,7 @@ image::images/newrepoform.png[Формата "`new repository`"]
 Няма да навлизаме в детайли за това, ако имате нужда от припомняне, погледнете <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.
 
 Сега проектът ви се хоства в GitHub и можете да изпратите URL-а на всеки, с който желаете да го споделите.
-Всеки GitHub проект е достъпен през HTTPS като `https://github.com/<user>/<project_name>`, а също и през SSH като `[email protected]:<user>/<project_name>`.
+Всеки GitHub проект е достъпен през HTTPS като `\https://github.com/<user>/<project_name>`, а също и през SSH като `[email protected]:<user>/<project_name>`.
 Git може да тегли и да изпраща и по двата начина, а достъпът се контролира с правата на името и паролата на свързващия се потребител.
 
 [NOTE]

book/06-github/sections/4-managing-organization.asc

@@ -12,7 +12,7 @@
 Организация се създава лесно, просто натиснете иконата "`+`" в горната дясна част на всяка GitHub страница и изберете "`New Organization`" от менюто.
 
 .Командата "`New organization`"
-image::images/neworg.png[Командата "`New organization`"]
+image::images/neworg.png[Командата “New organization”]
 
 Първо, ще трябва да дадете име за организацията и имейл адрес за контакт с групата.
 След това, можете да поканите други потребители като съсобственици на акаунта.

book/07-git-tools/sections/interactive-staging.asc

@@ -52,7 +52,7 @@ Update>> 1,2
 Update>>
 ----
 
-Символът `*` до всеки от файловете сега индикира, че съответния файл е избран за индексиране.
+Символът `\*` до всеки от файловете сега индикира, че съответния файл е избран за индексиране.
 Ако сега натиснете Enter в промпта `Update>>` без да въвеждате друго, Git взема всички избрани файлове и ги вкарва в индекса:
 
 [source,console]

book/07-git-tools/sections/stashing-cleaning.asc

@@ -179,7 +179,7 @@ index 66d332e..8bb5674 100644
 --- a/lib/simplegit.rb
 +++ b/lib/simplegit.rb
 @@ -16,6 +16,10 @@ class SimpleGit
-         return `#{git_cmd} 2>&1`.chomp
+         return `\#{git_cmd} 2>&1`.chomp
        end
      end
 +