Выводы:

1. Вы разрабатываете большой и длительный проект.
2. Большинство работы происходит в текстовых файлах.
3. Вы часто вносите изменения и, бывает, откатываетесь назад.
4. Вам нужно запоминать некоторые состояния (например, гарантированно стабильно работающие, или окончательные).
5. Несколько человек работает одновременно над одним проектом.
6. Вы хотите проводить ревизию изменений другого участника.
7. Вы или другие работаете распределенно и вам нужно облачное хранилище
8. Как Timeshift в Linux.
9. Вы хотите отслеживать, кто вносит какие изменения.
10. Могут происходить конфликты версий

Выводы:

1. История прошлых версий файла/файлов.
2. В простых случаях - рабочий вариант.
3. Быстро становится неуправляемой.
4. Если работает несколько человек - адище.
5. Конфликты версий приходится разрешать в ручном режиме.
6. Занимает много места.
7. Нет индексации, статистики, blame, синхронизации и прочих плюшек.

Выводы:

1. Subversion, Mercurial, Team Foundation Server.
2. Git - сегодня самая популярная.
3. Была создана Линусом Торвальдсом, когда его достали человеки.
4. Создана в первую очередь для программистов.
5. Знать git - сегодня это обязательно для любого айтишника.

Выводы:

1. Ничего не удаляется. Информация не потеряется.
2. Нужно решить, как часто делать коммиты.
3. Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными — после неё.
4. Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
5. Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
6. Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.

Выводы:

1. Рабочая директория - папка, в которой хранятся все файлы проекта и в которой работает СКВ.
2. Отслеживание файла - файлы в рабочей директории могут быть добавлены под СКВ или нет. Это сделано для того, чтобы не отслеживать часто меняющиеся, но неважные для рабочего процесса файлы, например: объектные файлы, настройки сборщика и IDE, временные файлы, кэш и так далее.
3. **Состояние **- снимок рабочей директории в определенный момент времени.
4. Репозиторий - служебное хранилище СКВ, в котором хранится информация о всех зафиксированных состояниях рабочей директории. Обычно является скрытой подпапкой в рабочей директории, но не входит в нее.
5. Коммит - фиксация изменений в новое состояние.
6. История - упорядоченная последовательность коммитов конкретного проекта начиная от исходного.
7. Удаленный репозиторий - другой репозиторий, часто расположенный на другой машине, с которым можно наладить взаимодействие (синхронизацию). Используется для организации распределенной работы над проектом.
8. Клонирование - создание локальной копии удаленного репозитория. Может происходить по протоколу ssh, HTTPS или просто копи{: .align-center style=”width: 800px;”}рованием архива.
9. Апстрим - обычное название репозитория, служащего исходным для текущего. Обычно обозначается origin.

Выводы:

1. Для работы нужно установить клиент git. Обычно это свободные и бесплатные программы.
2. Существуют консольные и графические клиенты.
3. Существуют под все стандартные платформы.
4. В Linux консольный клиент - чаще всего установлен в дистрибутиве по умолчанию.
5. Самая распространенная программа под Windows - git-scm.
6. После установки нужно произвести первоначальную настройку - ввести имя пользователя и e-mail. Это требуется только для идентификации пользователя. Это не регистрация.

Выводы:

1. Установить и настроить клиент git
2. Создать репозиторий в папке с проектом
3. Добавить необходимые файлы под СКВ
4. Сделать первоначальный коммит
5. Сделать логически завершенный участок работы
6. Сделать новый коммит с поясняющим сообщением
7. Повторить сколько нужно
8. Если что-то сломалось, вы всегда сможете вернуться на любое состояние.

Выводы:

1. Связный список - у состояния есть родитель.
2. Вычисляет патч между состоянием и его родителем.
3. Работает строго построчно.

Выводы:

1. Команда git log выводит описание последних коммитов.
2. Обратите внимание, что коммиты идентифицируются хешем. Вы можете использовать этот хэш как ссылку на коммит. Необязательно использовать весь хеш, только уникальную часть.
3. при каждом коммите фиксируется дата, время, пользователь, совершивший коммит, сообщение, ссылка на родителя, хеш коммита.

Выводы:

1. Команда git checkout приводит состояние рабочей директории в соответствие с выбранным коммитом.
2. Если в это время какие-то файлы были изменены, изменения потеряются.
3. Можно возвращать не всю рабочую директорию, а только определенные файлы.
4. Всегда можно воспользоваться встроенной справкой по командам.

Выводы:

1. Команда git diff показывает изменения каждого файла по сравнению с содержанием индекса или, при указании, с любым коммитом.
2. Команда показывает, какой текст был удален, а какой - добавлен.
3. Очень полезная команда для просмотра изменений.
4. Эта команда работает построчно. Если строка изменена, то это будет отображаться как удаление старой версии и вставка новой.
5. Существует множество графических реализаций данного функционала

Выводы:

1. В Git различают три области: историю зафиксированных состояний, текущее состояние рабочей директории и индекс.
2. Рабочая директория - это то, что мы видим в окне проводника. Мы работаем с файлами в ней, можем их редактировать любыми программами как обычно.
3. Индекс - это набор файлов рабочей директории, которые отслеживаются СКВ. Когда мы делаем коммит, содержимое индекса записывается в историю состояний.
4. Если мы создадим файл в рабочей директории, он не будет отслеживаться СКВ. Это сделано для того, чтобы не вычищать постоянно мусор из служебный файлов.
5. Файл можно добавить под СКВ командой git add. в дальнейшем будем говорить только о файлах, отслеживаемых СКВ.
6. Если мы изменили файл в рабочей директории, он становится модифицированным по сравнению с последним коммитом.
7. Когда мы делаем коммит, мы записываем новое состояние и все файлы опять становятся неизмененными.
8. Во многих графических средах состояние файла отображается цветом для удобства.

Выводы:

1. Нативно, гит имеет командный интерфейс. Даже если вы планируете использовать только графические клиенты или IDE с интеграцией, полезно знать основные команды и их применение.
2. Команда git init инициализирует пустой репозиторий в текущей папке.
3. Команда git add добавляет файлы в индекс.
4. Команда git commit фиксирует изменения. При этом в командной строке откроется редактор по умолчанию, чтобы вы могли записать сообщение коммита. Рекомендуется использовать форму git commit -m “Описание изменений”.
5. Можно сделать коммит и добавить все новые файлы автоматически с помощью git commit -a
6. Коммиту можно назначить метку для упрощения ориентации по истории.

Выводы:

1. Ветвление происходит, когда мы произвели два разных изменения, основываясь на одном и том же состоянии.
2. Часто происходит при командной работе.
3. Кажется, что это что-то плохое.
4. Git позволяет работать с ветками комфортно и, при необходимости, объединять их.
5. Ветвление - это способ изолировать одни изменения от других. Например, разработка одной фичи независимо от хода работ над другой.

Выводы:

1. Ветки - это специальные указатели на коммиты, которые перемещаются с каждым новым коммитом.
2. Создать новую ветку можно командой git branch <name>
3. Команда git branch выводит все ветки.
4. Ветка по умолчанию по соглашению называется master.
5. Git хранит специальный указатель HEAD - он показывает, на какой ветке вы сейчас находитесь
6. Чтобы перейти на существующую ветку, вам надо выполнить команду git checkout
7. Ветка, на которую указывает HEAD, движется вперёд с каждым коммитом.
8. Теперь коммиты, которые мы будем делать, будут относиться к новой ветке.

Выводы:

1. В любой момент можно перейти в другую ветку и начать коммитить в нее.
2. При переходе в другую ветку состояние рабочей директории приводится в соответствие с состоянием последнего коммита в этой ветке. Поэтому все изменения будут основываться на том состоянии.
3. Переход между ветками откатывает изменения, которые вы делали в другой ветке, но не удаляет их. Все фиксированные изменения сохраняются в истории веток.
4. При использовании веток история коммитов уже не будет линейной.

Выводы:

1. Две ветки можно объединить (слить). Это значит, что мы применяем к файлам изменения, которые произошли и в одной ветке и во второй.
2. Команда git merge <branch> сливает указанную ветку в текущую. Это значит, что создастся новый коммит в текущей ветке, учитывающий изменения в указанной.
3. Коммиты слияния имеют двух родителей.
4. Git автоматически определяет наилучшего общего предка для слияния веток.
5. После слияния ветка не уничтожается и над ней можно продолжать работать.

Выводы:

1. Если вы изменили одну и ту же часть файла по-разному в двух ветках, которые собираетесь слить, Git не сможет сделать это чисто. Такая ситуация называется конфликтом слияния.
2. В таком случае, git приостанавливает слияние до тех пор, пока вы не разрешите конфликт.
3. Посмотреть, какие файлы не прошли слияние можно командой git status.
4. Содержимое спорных файлов в рабочей директории будет отражать оба конфликтующих варианта текста.
5. Чтобы разрешить конфликт, вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению.
6. После этого необходимо выполнить добавление этих файлов к индексу и коммит для завершения слияния веток.

Выводы:

1. При командной разработке приходится синхронизировать работу нескольких программистов в одном месте.
2. Даже одному разработчику иногда приходится работать и вносить изменения в проект из разных мест.
3. Для этого в системах контроля версий предусмотрена возможность связать локальный репозиторий с другим - удаленным.
4. При связывании репозиториев возникает возможность отправить изменения, сделанные в локальном репозитории в удаленный и наоборот - скачать изменения из удаленного репозитория в локальный.
5. Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить команду git remote. Она перечисляет список имён-сокращений для всех уже указанных удалённых дескрипторов. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали.

Выводы:

1. Распределенная модель git позволяет гибко взаимодействовать разработчикам в командном проекте.
2. В централизованных системах все разработчики являются узлами сети, более или менее одинаково работающими на центральном хабе.
3. Это означает, что если два разработчика склонируют репозиторий и каждый внесет изменения, то первый из них сможет отправить свои изменения в репозиторий без проблем. Второй разработчик должен слить изменения, сделанные первым разработчиком, чтобы избежать их перезаписи во время отправки на сервер.
4. Однако, в Git’е каждый разработчик потенциально является и узлом, и хабом. То есть каждый разработчик может как вносить код в другие репозитории, так и содержать публичный репозиторий, на основе которого работают другие разработчики, и в который они вносят свои изменения.

Выводы:

1. Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться,** выполните git remote add [сокращение] [url]**
2. Теперь вы можете использовать в командной строке имя pb вместо полного URL.
3. Если вы хотите извлечь (fetch) всю информацию, которая есть в удаленном репозитории, но нет в вашем, вы можете выполнить git fetch pb.
4. Ветка master удаленного репозитория теперь доступна локально как pb/master. Вы можете слить (merge) её в одну из своих веток или перейти на эту ветку, если хотите её проверить.

Выводы:

1. Для получения копии существующего Git-репозитория, например, проекта, в который вы хотите внести свой вклад, необходимо использовать команду git clone.
2. Вместо того, чтобы просто получить рабочую копию, Git получает копию практически всех данных, которые есть на сервере.
3. Эта команда создаёт директорию “libgit2”, инициализирует в ней поддиректорию .git, скачивает все данные для этого репозитория и создаёт (checks out) рабочую копию последней версии. Если вы зайдёте в новую директорию libgit2, то увидите в ней файлы проекта, готовые для работы или использования.
4. В Git реализовано несколько транспортных протоколов, которые вы можете использовать. В предыдущем примере использовался протокол https://, вы также можете встретить git:// или user@server:path/to/repo.git, использующий протокол передачи SSH.

Выводы:

1. Для получения изменений используется команда git fetch.
2. Чтобы автоматически слить изменения, используется команда git pull.
3. Если необходимо, при выполнении git pull могут создаваться коммиты слияния.

Выводы:

1. Для отправки своих изменений на сервер применяют команду git push.
2. Эта команда не будет производить автоматических слияний.
3. Если на сервере что-то изменилось, ваш git push будет отклонен.
4. В таком случае, нужно выполнить git pull и затем опять git push.

Выводы:

1. Гитхаб это крупнейшее хранилище Git репозиториев, а также центр сотрудничества для миллионов разработчиков и проектов.
2. Огромный процент репозиториев хранится на Гитхабе.
3. Многие проекты с открытым исходным кодом используют его ради Git хостинга, баг-трекера, рецензирования кода и других вещей.
4. Гитхаб даже используется для отслеживания динамики популярности языков программирования.

Выводы:

1. Первым делом нужно создать беcплатную учетную запись.
2. В панели управления справа нажмите кнопку “New repository”.
3. Всё, что в действительности нужно сделать, так это указать название проекта, все остальные поля опциональны.
4. Теперь ваш проект хостится на GitHub и вы можете предоставить ссылку на него любому желающему.
5. Все проекты на GitHub доступны как по HTTP https://github.com/<пользователь>/<имя_проекта>, так по SSH.
6. Git производит контроль доступа на основании учётных данных пользователя, осуществляющего подключение.

Выводы:

1. Форки нужны для внесения изменений в чужие репозитории.
2. Форк - это ваша собственная копия проекта со всеми коммитами и историей.
3. При создании форка автоматически проставляется ссылка на изначальный репозиторий.
4. Автор репозитория может увидеть, кто его форкнул.

Выводы:

1. При работе над форком чужого репозитория возникает необходимость отправить свои изменения в апстрим.
2. Напрямую писать в репозиторий может только его автор или члены команды разработчика проекта, то есть его владельцы.
3. Это сделано для разграничения прав доступа в репозитории.
4. Поэтому, вы не сможете напрямую выполнить push в чужой репозиторий.
5. Вместо этого вы отправляете pull request - запрос на внесение изменений.
6. Этот запрос становится виден автору оригинального репозитория. Он может просмотреть вашу работу и затем либо принять его, либо отклонить.
7. Пулл реквесты на гитхабе оформляются как публичные посты, где все участники могут оставлять свои комментарии.

Выводы:

1. Методология работы с git
2. Стандартизировать рабочий процесс с использованием веток
3. Вводит некоторые полезные и распространенные понятия
4. Регламентирует правила слияния веток
5. Сводит к минимуму риск выложить нестабильный код в мастер
6. Хорошо использовать с непрерывной интеграцией
7. Есть инструментальные решения.

Выводы:

1. У нас есть две основные ветки: master и develop.
2. В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.
3. Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.
4. Ветка release используется для подготовки к новому релизу проекта.
5. Ветка hotfix служит для срочного исправления багов, найденных, например, на продакте.
6. Основа работы с гитфлоу - хранить в мастере только релизный код. Там не допускается рабочий процесс, потенциально приводящий к ошибкам.

Выводы:

1. После создания репозитория создается ветка develop. Она является основной рабочей.
2. Начинается работа на ветке develop.
3. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
4. Закончив работу на feature-ветке, вы сливаете ее с develop.
5. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
6. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop.

Выводы:

1. Ветвь master создаётся при инициализации репозитория, что должно быть знакомо каждому пользователю Git.
2. Параллельно ей также мы создаём ветку для разработки под названием develop.
3. Мы считаем ветку origin/master главной. То есть, исходный код в ней должен находиться в состоянии production-ready в любой произвольный момент времени.
4. Ветвь origin/develop мы считаем главной ветвью для разработки.
5. Эту ветку также можно назвать «интеграционной».
6. Когда исходный код в ветви develop готов к релизу, все изменения должны быть влиты в ветвь master и помечены тегом с номером релиза.

Выводы:

1. Ветви feature используются для разработки новых функций, которые должны появиться в текущем или будущем релизах.
2. Смысл существования ветви feature состоит в том, что она живёт так долго, сколько продолжается разработка данной фичи.
3. Когда работа в ветви завершена, последняя вливается обратно в главную ветвь разработки или же удаляется.

Выводы:

1. Ветви release используются для подготовки к выпуску новых версий продукта.
2. Они позволяют расставить финальные точки над i перед выпуском новой версии.
3. Кроме того, в них можно добавлять минорные исправления, а также подготавливать метаданные для очередного релиза .
4. Очередной релиз получает свой номер версии только в тот момент, когда для него создаётся новая ветвь, но ни в коем случае не раньше.

Выводы:

1. Ветви hotfix создаются из главной (master) ветви.
2. Они нужны для срочного внесения критичных исправлений в текущий релиз, если новый релиз еще не готов.