qq

articles/skv.md

@@ -4,8 +4,6 @@
 
 # Системы контроля версий
 
->🕮 таким символом помечены команды или действия, которые нужно выполнить в лабораторной работе или домашнем задании
-
 ## Что такое контроль версий, и зачем он нужен? 
 
 Система контроля версий (**СКВ**) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов (типичный пример: выложили версию в проду, начали работу над новыми фичами и вдруг обнаружились ошибки. Нужно не потеряв новых наработок вернуться к рабочей версии, исправить ошибки).
@@ -23,7 +21,7 @@
 Для каждого файла, зарегистрированного в системе, она хранит полную историю изменений, причём для текстовых файлов используется эффективный алгоритм дельта-компрессии, когда хранится только последняя версия и все межверсионные изменения.  
 Такие **СКВ** решали только первую проблему - избыточность данных.
 
-Современные **СКВ** можно разделить на две группы: централизованные и распределенные.
+Современные **СКВ** можно разделить на две группы: __централизованные__ и __распределенные__.
 
 ## Централизованные системы контроля версий
 
@@ -120,8 +118,7 @@ git config user.email vpupkin@example.com
 
 Если вы собираетесь начать использовать **Git** для существующего проекта, то вам необходимо перейти в каталог проекта и в командной строке ввести
 
-
->🕮 не забудьте создать пустой каталог для проекта и выполняйте все команды в нём
+>не забудьте создать пустой каталог для проекта и выполняйте все команды в нём
 
 ```
 git init
@@ -172,8 +169,6 @@ git clone https://kolei.ru/ekolesnikov/OAP mydir
 
 Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда `git status`. Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
 
->🕮
-
 ```
 git status
 On branch master
@@ -184,8 +179,6 @@ nothing to commit
 
 Предположим, вы добавили в свой проект новый файл, простой файл `README.MD`. Если этого файла раньше не было, и вы выполните `git status`, вы увидите свой неотслеживаемый файл вот так:
 
->🕮
-
 ```
 git status
 On branch master
@@ -202,16 +195,12 @@ nothing added to commit but untracked files present (use "git add" to track)
 
 Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда `git add`. Чтобы начать отслеживание файла `README.MD`, вы можете выполнить следующее:
 
->🕮
-
 ```
 git add README.MD
 ```
 
 Если вы снова выполните команду `git status`, то увидите, что файл `README.MD` теперь отслеживаемый и индексированный:
 
->🕮
-
 ```
 git status
 On branch master
@@ -227,7 +216,7 @@ Changes to be committed:
 
 Зачастую, имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых. К таким файлам обычно относятся автоматически генерируемые файлы (различные логи, результаты сборки программ и т.п.). В таком случае, вы можете создать в корне проекта файл `.gitignore` с перечислением шаблонов соответствующих таким файлам. Вот пример файла `.gitignore`:
 
->🕮 создайте файл `.gitignore` в корне проекта (там же где и файл `readme.md`)
+>создайте файл `.gitignore` в корне проекта (там же где и файл `readme.md`)
 
 ```
 *.log
@@ -300,8 +289,6 @@ git commit
 
 Можно сразу набрать свой комментарий к коммиту в командной строке вместе с командой `git commit`, указав его после параметра `-m`:
 
->🕮
-
 ```
 git commit -m "мой первый коммит"
 [master]: created 463dc4f: "мой первый коммит"
@@ -370,8 +357,6 @@ git rm \*~
 
 После того как вы создадите несколько коммитов, или же вы склонируете репозиторий с уже существующей историей коммитов, вы, при желании, можете узнать, что же происходило с этим репозиторием. Наиболее простой и в то же время мощный инструмент для этого — команда `git log`.
 
->🕮
-
 По умолчанию, `git log` выводит список коммитов созданных в данном репозитории в обратном хронологическом порядке. То есть самые последние коммиты показываются первыми.
 
 ### Работа с удалёнными репозиториями
@@ -386,7 +371,7 @@ git rm \*~
 
 Чтобы добавить новый удалённый **Git**-репозиторий под алиасом, к которому будет проще обращаться, выполните `git remote add [алиас] [url]`:
 
->🕮 Тут использовать реальную команду из репозитория
+>Тут использовать реальную команду из репозитория
 
 ```
 git remote add pb https://kolei.ru/some_repo
@@ -398,8 +383,6 @@ git remote add pb https://kolei.ru/some_repo
 
 Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
 
->🕮
-
 ```
 git fetch [имя удал. сервера]
 ```
@@ -414,8 +397,6 @@ git fetch [имя удал. сервера]
 
 Когда вы хотите поделиться своими наработками, вам необходимо отправить (_push_) их в главный репозиторий. Команда для этого действия простая: `git push [удал. сервер] [ветка]`. Чтобы отправить вашу ветку **master** на сервер **origin** (повторимся, что клонирование, как правило, настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки наработок на сервер:
 
->🕮
-
 ```
 git push origin master
 ```
@@ -595,6 +576,7 @@ git merge название_ветки
 ```
 
 > Ссылка может быть и на изображение расположенное в репозитории
+>
 >```
 >![](../img/img.png)
 >```