При разработке любого крупного проекта вы столкнетесь с необходимостью версионирования и надзора за изменениями в исходном коде. С этими задачами вам поможет система контроля версий.
Но для начала откатимся немного дальше, к версионированию и в целом к порядку работы с любыми документами, а не только с кодом. Вам следует всегда следить за изменением в ходе вашей работы — это позволит организовать работу и “проводить эксперименты”, не опасаясь того, что ваша работа будет затерта и потеряна в бесконечном потоке изменений.
Размечайте важные изменения и это поможет вам в повседневной работе.
Теперь давайте немного поговорим о “математике”, которая может помочь вам в познании версионирования и распределенных систем в целом.
Пусть перед вами стоит задача рассортировать объекты по времени их создания. Какой бы простой этой задача не казалось давайте подумаем какие подводные камни могут всплыть?
Ответ простой — время. Само по себе действие “выставления временной метки” является огромной и очень сложной задачей, для решения которой Google потратил не один год разработки. И сейчас мы не будем подробно обсуждать как решать задачу, а только немного поговорим о том, какие вопросы могут перед нами стоять и о чем стоит помнить.
Основным примитивом для упорядочивания являются логические часы в разной имплементации. Для нашего курса и базового понимания будет достаточно представить машинку выдающую талончики с подряд идущими номерами. Наличие единого узла отказа ставит под сомнение всю нашу систему и ее отказоустойчивость, но здесь я предложу заинтересовавшимся поизучать как в целом работают “реальные” системы подобного типа.
Коммит(от англ. commitment - обязательство) — некое атомарное изменение состояния системы.
В контексте систем контроля версий коммит это зафиксированное изменение файлов, которое будет применяться в дальнейшем. Важно понимать, что порядок изменения внутри коммита не гарантирован и не должен быть важен. Относитесь к коммиту, как к одномоментной операции.
И как бы коммиты не были удобны в понимании и работе с ними, всегда, в любой системы с коммитами и их применением вы столкнетесь с конфликтами. Будь это два “одновременно” пришедших изменения для базы данных. Или два параллельных действия над одним и тем же файлом в репозитории, вы всегда должны держать в голове потенциальную невозможность применения вашего файла.
В традиционных системах контроля версий(без экстремальных действий) из двух конфликтующих коммитов “побеждает” тот, который смог первым записать себя в список изменений.
Для разнообразных систем существует много возможных решений конфликтов. И об этом(как и о большинстве тем выше) вам куда подробнее и понятнее расскажут на курсах про распределенные системы(которые я крайне рекомендую выбирать).
Перед тем как увидеть и обсудить слона в комнате GIT обсудим известные аналоги.
Централизованная система контроля версий, которая локально хранит небольшой локальный слепок реального репозитория. Из его централизованности следует плюсы и минусы