Системы контроля версий. Git.

Система контроля версий (Version control system)

это система, которая предназначена для хранения файлов, позволяет менять их, с возможностью возврата к любой из предыдущих версий.

В IT-компаниях такие системы применяются для хранения
кода проекта и документации.

Классификация систем контроля версий

1.Централизованные системы;
2.Распределенные системы.

Централизованные системы

(Классификация систем контроля версий)

- Есть отдельный выделенный сервер, который хранит в себе репозиторий – хранилище файлов, с которыми работает система контроля версий.
- Остальные пользователи забирают себе копию файлов (working copy), работают с ними и могут вносить свои изменения в этот глобальный репозиторий.
К ним относят SVN, TFS.

Распределенные системы

(Классификация систем контроля версий)

- Нет единого выделенного сервера;
- Каждый пользователь может создать полную копию репозитория, а другие пользователи могут подключаться уже к этой копии, создавать свои копии и т.д.
К ним относят: Git, Mercurial.

Графическая система

(SVN)

- Известная графическая система – TortoiseSVN;
- Выполнен в виде расширения контекстного меню проводника.

Основные операции SVN

1. Checkout;
2. Commit;
3. Update.

Операция
Checkout

(SVN)

Выкачивание себе рабочей копии репозитория, чтобы работать с ней, выполняется только первый раз.

Операция
Commit

(SVN)

Перенос своих изменений из рабочей копии в репозиторий.

Операция
Update

(SVN)

Перенос изменений из репозитория в свою рабочую копию. То есть забираем изменения, сделанные другими людьми.

Git

Очень распространенная распределенная система. В основном это консольная утилита, но есть и графические интерфейсы. Среды разработки тоже предоставляют свои удобные средства для работы с Git.

Операции Git

1. Клонирование (clone);
2. Add/remove;
3. Коммит - commit;
4. Push;
5. Pull.

Операция
Клонирование (clone)

(Git)

Создание локального репозитория, как копии от удаленного репозитория.

Операция
Add/remove

(Git)

Удаление/добавление файлов под контроль Git. Нужно делать при добавлении в проект новых файлов и при
удалении файлов из проекта.

Операция
Коммит - commit

(Git)

Формирование набора изменений. Выбранные изменения попадают в набор изменений (он тоже называется commit), но пока не вносятся в репозиторий. Чтобы внести изменения в удаленный репозиторий, нужно выполнить команду push.

Операция
Push

(Git)

Вносит последние коммиты в удаленный репозиторий. После этого эти изменения доступны другим.

Операция
Pull

(Git)

Получение изменений из удаленного репозитория в свой локальный репозиторий.

Для переноса изменений из своего репозитория в
удаленный.

(Git)

1. add – добавление файлов в индекс для последующего коммита;
2. commit – фиксация набора изменений (коммит);
3. push – отправка коммитов в удаленный репозиторий.

Github

(Git)

Это крупный бесплатный веб-сервис для хранения Git-репозиториев/ Там можно бесплатно создавать свои репозитории. Для управления им предоставляется удобный веб интерфейс, а также Windows приложение. Очень популярен для некоммерческих и open-source проектов. Бесплатно можно создавать как публичные репозитории (доступны для просмотра всем), так и приватные.

Bitbucket

(Git)

В целом то же самое, что Github. Здесь также можно бесплатно завести приватный репозиторий, доступом к которому вы можете управлять.

Краткое описание процесса работы с Git.

Если несколько разработчиков, то периодически делаем Pull – забираем последние изменения из репозитория. Когда сами меняем код, то делаем Add для новых файлов, набираем изменения в коммиты (команда Commit), а потом делаем Push (коммиты отправляются в репозиторий). Иногда накапливают несколько коммитов, а потом отправляют их на сервер. К каждому коммиту надо писать краткий, но понятный и точный комментарий – что именно изменилось.

Файл .gitignore
Часть 1

(Git)

- В Git репозиторий можно добавлять специальный файл с именем .gitignore;
- В этом файле указываются файлы, которые должны игнорироваться git’ом;
- Например, это результаты компиляции, разные временные файлы среды разработки и т.д.
- Эти файлы не нужны в репозитории, потому что эти файлы не важны, но занимают место.

Файл .gitignore
Часть 2

(Git)

В файле можно писать записи которые указывают конкретные пути к файлам или папкам, либо использовать специальные последовательности * и др.
Действие файла .gitignore распространяется на папку, в которой он находится, и на все вложенные папки.

Ветка
(branch)

(Git)

это указатель на некоторый коммит. Когда мы создаем репозиторий, там сразу создается 1 ветка с именем master.

Cлияния
(merge)

(Git)

при работе в одной из веток нужно перенести изменения в другую ветку и изменения из обоих веток объединяются. Имеются следующие способы слияний:
1. fast-forward;
2. three way merge.

Популярные модели работы с Git

1. Centralized Workflow (централизованный процесс);
2. Feature Branch Workflow (процесс с Feature ветками);
3. Gitflow Workflow.

Модель
Centralized Workflow

(Git)

- Все пользователи работают только с одной веткой – master;
- Все выкачивают себе копию кода, работают с ней, и потом сразу же вносят изменения в центральный репозиторий т.е. работа ведется так же, как с централизованными VCS;
- Подходит только для очень маленьких
команд и простых проектов.

Модель
Feature Branch Workflow
Часть 1

(Git)

- Есть постоянная ветка master - в ней находится актуальная стабильная версия кода;
- Для каждой задачи разработчик заводит отдельную ветку (так называемую feature ветку) и работает в ней;
- Когда задача завершена, разработчик делает merge (слияние) своей ветки в master;
- Обычно это делается не напрямую, а через pull request;
- После этого feature ветку удаляют, т.к. она больше не нужна.

Модель
Feature Branch Workflow
Часть 2

(Git)

Часто для безопасности почти у всех разработчиков забирают права делать merge в master. Разработчик, когда завершил задачу, создает pull request – запрос на merge в master. При этом некоторому ответственному за это человеку приходит уведомление, что разработчик хочет сделать merge ветки в master.

Модель
Feature Branch Workflow
Часть 3

(Git)

Ответственный человек может провести review кода, написать комментарии и т.д., и отклонить pull request. Либо может утвердить его, тогда выполнится merge т.е. pull request позволяет организовать процесс code review и проконтролировать что именно попадает в master.

Модель
Feature Branch Workflow
Часть 4

(Git)

Эта модель хорошо подходит для маленьких и средних по
размеру команд. При этом модель довольно простая, в ней нет излишней
сложности.

Модель
Gitflow Worklow
Часть 1

(Git)

Gitflow – это популярная модель использования веток в Git.
Gitflow включает в себя концепции из Feature Branch Workflow и добавляет новые.

Модель
Gitflow Worklow
Часть 2

(Git)

- В проекте заводятся две постоянные ветки – master и develop.
- master – содержит стабильную версию проекта. Эта ветка всегда должна быть готова к выкладыванию на production.
- develop – в этой ветке самая новая версия проекта. Эта версия может быть нестабильна – могут быть баги, фичи могут быть недоделаны.

Модель
Gitflow Worklow
Часть 3

(Git)

При работе по gitflow бывают следующие ситуации:
- Нужно срочно сделать исправление (hotfix) и выложить на production;
- Нужно просто сделать фичу, протестировать, а потом выложить на production.

Модель
Gitflow Worklow
Срочные задачи:
Часть 1.

(Git)

- От master делается отдельная временная ветка, исправление/доработка делается в ней.
- Такой ветке часто дают название по номеру задачи в багтрекере, например, feature121 или bug234.
- В эту ветку постоянно забираются изменения из master – другие разработчики тоже работают над своими задачами.

Модель
Gitflow Worklow
Срочные задачи:
Часть 2.

(Git)

- Когда всё готово и протестировано, изменения переносятся в master – делается merge (слияние).
- Всё, эти изменения рано или поздно будут выложены на production.
- После этого нужно перенести эти изменения и в ветку develop. Там тоже нужно будет выполнить merge.
- После этого временную ветку удаляют.

Модель
Gitflow Worklow
Несрочные задачи:

(Git)

- От develop делается отдельная временная ветка, исправление/доработка делается в ней
- В эту ветку постоянно забираются изменения из develop другие разработчики тоже работают над своими задачами
- Когда всё готово и протестировано, изменения переносятся в develop – делается merge (слияние)
- Когда-нибудь эти изменения будут протестированы, и будет выполнен merge develop в master, а потом изменения попадут и на production.

Багтрекеры (или системы управления задачами)

– ещё один важнейший инструмент командной работы. Обычно представляют собой сайт, в котором заводятся задачи по проекту.
Известные багтрекеры:
- JIRA;
- Redmine;
- TFS;
- YouTrack.

У задачи обязательно есть:

(Багтрекеры)

1. Уникальный номер (ID);
2. Тип;
3. Название;
4. Описание;
5. Автор задачи;
6. Ответственный;
7. Статус;
8. Вложения;
9. Связи с другими задачами;
10. Теги.

Уникальный номер (ID)

(Задача содержит. Багтрекеры)

обычно целое число

Тип

(Задача содержит. Багтрекеры)

task или bug. Также можно создавать свои типы задач

Название

(Задача содержит. Багтрекеры)

должно быть чётким и как можно более коротким

Описание

(Задача содержит. Багтрекеры)

полное описание задачи. Должно содержать всё необходимое для правильного понимания и выполнения задачи

Автор задачи

(Задача содержит. Багтрекеры)

кто её создал

Ответственный

(Задача содержит. Багтрекеры)

на кого назначена задача. Ответственный может меняться в ходе работы над задачей

Статус

(Задача содержит. Багтрекеры)

команда сама придумывает какие статусы могут быть у задач, каков их смысл и когда следует их менять.
Может быть такой набор статусов: New, In Progress, Ready To Review, Review, Ready To Test, In Test, Done.

Вложения

(Задача содержит. Багтрекеры)

Любые файлы

Связи с другими задачами

(Задача содержит. Багтрекеры)

Например, отношение Дубликат, Родитель-Потомок и т.д.

Теги

(Задача содержит. Багтрекеры)

Теги команда придумывает сама и может помечать ими задачи. Например, может быть тег Deployed to prod, который означает, что эта задача выложена на
production.

установить имя, которое будет прикрепляться к коммиту

(Команды конфигурации)
(Git через консоль)

git config --global user.name "[name]"

(Команда пишется в одну строку.)

установить email, который будет прикрепляться к коммиту

(Команды конфигурации)
(Git через консоль)

git config --global user.email "[email address]"

(Команда пишется в одну строку.)

включить полезную подсветку командной строки

(Команды конфигурации)
(Git через консоль)

git config --global color.ui auto

(Команда пишется в одну строку.)

обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений

(Команды конфигурации)
(Git через консоль)

git config --global push.default current

(Команда пишется в одну строку.)

установить редактор для редактирования сообщений коммита

(Команды конфигурации)(Git через консоль)

git config --global core.editor [editor]

(Команда пишется в одну строку.)

установить программу для разрешения конфликтов при слиянии

(Команды конфигурации)
(Git через консоль)

git config --global diff.tool [tool]

(Команда пишется в одну строку.)

проверить текущие настройки в Git

(Команды конфигурации)
(Git через консоль)

git config --list

создать новый локальный репозиторий с заданным именем

(Создание репозитория)
(Git через консоль)

git init [project-name]

загрузить проект и его полную историю изменений

(Создание репозитория)
(Git через консоль)

git clone [url]

полный список изменений файлов, ожидающих коммита

(Работа с изменениями)
(Git через консоль)

git status

краткий вид изменений

(Работа с изменениями)
(Git через консоль)

git status -s

показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged)

(Работа с изменениями)
(Git через консоль)

git diff

сделать указанный файл готовым для коммита

(Работа с изменениями)
(Git через консоль)

git add [file]

сделать все измененные файлы готовыми для коммита

(Работа с изменениями)
(Git через консоль)

git add .

добавить только файлы, соответствующие указанному выражению

(Работа с изменениями)
(Git через консоль)

git add '*.txt'

позволяет выбрать какие изменения из файла добавятся в коммит

(Работа с изменениями)
(Git через консоль)

git add --patch filename

(Команда пишется в одну строку.)

показать что было добавленно в индекс с помощью git add, но еще не было закоммиченно

(Работа с изменениями)
(Git через консоль)

git diff --staged

показать что изменилось с последнего коммита

(Работа с изменениями)
(Git через консоль)

git diff HEAD

показать что изменилось с предпоследнего коммита

(Работа с изменениями)
(Git через консоль)

git diff HEAD^

сравнить текущую ветку с заданной

(Работа с изменениями)
(Git через консоль)

git diff [branch]

то же самое, что и diff, но показывает изменения в заданной difftool

(Работа с изменениями)
(Git через консоль)

git difftool -d

показать изменения, сделанные в текущей ветке

(Работа с изменениями)
(Git через консоль)

git difftool -d master..

показать статистику какие файлы были изменены и как

(Работа с изменениями)
(Git через консоль)

git diff --stat

убрать файлы из индекса коммита (изменения не теряются)

(Работа с изменениями)
(Git через консоль)

git reset [file]

записать изменения в репозиторий. для написания сообщения откроется назначенный редактор

(Работа с изменениями)
(Git через консоль)

git commit

записать изменения с заданным сообщением

(Работа с изменениями)
(Git через консоль)

git commit -m "[descriptive message]"

(Команда пишется в одну строку.)

добавить изменения к последнему коммиту

(Работа с изменениями)
(Git через консоль)

git commit --amend

список всех локальных веток в текущей директории

(Работа с ветками)
(Git через консоль)

git branch

создать новую ветку

(Работа с ветками)
(Git через консоль)

git branch [branch-name]

(Команда пишется в одну строку.)

переключиться на указанную ветку и обновить рабочую директорию

(Работа с ветками)
(Git через консоль)

git checkout [branch-name]

(Команда пишется в одну строку.)

создать и переключиться на удаленную ветку

(Работа с ветками)
(Git через консоль)

git checkout -b [name_branch]

(Команда пишется в одну строку.)

вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита

(Работа с ветками)
(Git через консоль)

git checkout [filename]

(Команда пишется в одну строку.)

соединить изменения в текущей ветке с изменениями из заданной

(Работа с ветками)
(Git через консоль)

git merge [branch]

соединить ветки без режима “fast forwarding”

(Работа с ветками)
(Git через консоль)

git merge --no-ff [branch]

(Команда пишется в одну строку.)

посмотреть полный список локальных и удаленных веток

(Работа с ветками)
(Git через консоль)

git branch -a

удалить заданную ветку

(Работа с ветками)
(Git через консоль)

git branch -d [branch]

принудительно удалить заданную ветку, игнорируя ошибки

(Работа с ветками)
(Git через консоль)

git branch -D [branch]

переименовать ветку

(Работа с ветками)
(Git через консоль)

git branch -m [oldname] [newname]

(Команда пишется в одну строку.)

удалить файл из рабочей директории и добавить в индекс информацию об удалении

(Работа с файлами)
(Git через консоль)

git rm [file]

удалить файл из репозитория, но сохранить его локально

(Работа с файлами)
(Git через консоль)

git rm --cached [file]

изменить имя файла и добавить в индекс коммита

(Работа с файлами)
(Git через консоль)

git mv [file-original] [file-renamed]

(Команда пишется в одну строку.)

список всех игнорируемых файлов

(Отслеживание файлов)
(Git через консоль)

git ls-files --other --ignored --exclude-standard

(Команда пишется в одну строку.)

положить во временное хранилище все отслеживаемые файлы

(Создание фрагментов)
(Git через консоль)

git stash

восстановить последние файлы, положенные во временное хранилище

(Создание фрагментов)
(Git через консоль)

git stash pop

список всех сохраненных изменений во временном хранилище

(Создание фрагментов)
(Git через консоль)

git stash list

удалить последние файлы, положенные во временное хранилище

(Создание фрагментов)
(Git через консоль)

git stash drop

список изменения текущей ветки

(Просмотр истории)
(Git через консоль)

git log

список изменения текущего файла, включая переименования

(Просмотр истории)
(Git через консоль)

git log --follow [file]

изменение вида отображения истории изменений

(Просмотр истории)
(Git через консоль)

git log --pretty=format:"%h %s" --graph

(Команда пишется в одну строку.)

посмотреть над чем работал заданный пользователь последнюю неделю

(Просмотр истории)
(Git через консоль)

git log --author='Name' --after={1.week.ago} --pretty=oneline --abbrev-commit

(Команда пишется в одну строку.)

посмотреть историю изменений только для текущей ветки

(Просмотр истории)
(Git через консоль)

git log --no-merges master..

(Команда пишется в одну строку.)

посмотреть различия между двумя заданными ветками

(Просмотр истории)
(Git через консоль)

git diff [file-branch]..[second-branch]

(Команда пишется в одну строку.)

показать метадату и изменения в заданном коммите

(Просмотр истории)
(Git через консоль)

git show [commit]

посмотреть на файл в другой ветке, не переключаясь на неё

(Просмотр истории)
(Git через консоль)

git show [branch]:[file]

(Команда пишется в одну строку.)

убрать изменения из индекса коммита, сами изменения останутся

(Отмена коммитов)
(Git через консоль)

git reset

отменить все коммиты после указанного коммита, изменения будут сохранены локально

(Отмена коммитов)
(Git через консоль)

git reset [commit/tag]

принудительно вернутся к указанному коммиту, не сохраняя историю и изменения

(Отмена коммитов)
(Git через консоль)

git reset --hard [commit]

(Команда пишется в одну строку.)

загрузить всю историю с заданного удаленного репозитория

(Синхронизация изменений)
(Git через консоль)

git fetch [bookmark]

слить изменения локальной ветки и заданной удаленной

(Синхронизация изменений)
(Git через консоль)

git merge [bookmark]/[branch]

(Команда пишется в одну строку.)

запушить текущую ветку в удаленную ветку

(Синхр. изменений)
(Git через консоль)

git push

запушить ветку в указанный репозиторий и удаленную ветку

(Синхронизация изменений)
(Git через консоль)

git push [remote] [branch]

(Команда пишется в одну строку.)

в удаленном репозитории удалить заданную ветку

(Синхр. изменений)
(Git через консоль)

git push [bookmark] :[branch]

(Команда пишется в одну строку.)

если удаленная ветка не установлена как отслеживаемая, то сделать ее такой

(Синхронизация изменений)
(Git через консоль)

git push -u origin master

(Команда пишется в одну строку.)

загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой

(Синхронизация изменений)
(Git через консоль)

git pull

указать конкретную удаленную ветку для слияния

(Синхронизация изменений)
(Git через консоль)

git pull [remote][branch]

(Команда пишется в одну строку.)

посмотреть список доступных удаленных репозиториев

(Синхронизация изменений)
(Git через консоль)

git remote

посмотреть детальный список доступных удаленных репозиториев

(Синхронизация изменений)
(Git через консоль)

git remote -v

добавить новый удаленный репозиторий

(Синхр. изменений)
(Git через консоль)

git remote add [remote][url]

(Команда пишется в одну строку.)