Какой git выбрать

7.1 Инструменты Git — Выбор ревизии

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

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

Выбор ревизии

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

Одиночные ревизии

Конечно, вы можете ссылаться на коммит по его SHA-1 хешу, но существуют более удобные для человека способы. В данном разделе описываются различные способы обращения к одному коммиту.

Сокращённый SHA-1

Git достаточно умен, чтобы понять какой коммит имеется ввиду по нескольким первым символам его хеша, если указанная часть SHA-1 имеет в длину по крайней мере четыре символа и однозначна — то есть в текущем репозитории существует только один объект с таким частичным SHA-1.

Например, предположим, чтобы найти некоторый коммит, вы выполнили команду git log и нашли коммит, в которой добавили определённую функциональность:

$ git log commit 734713bc047d87bf7eac9674765ae793478c50d3 Author: Scott Chacon Date: Fri Jan 2 18:32:33 2009 -0800 Fix refs handling, add gc auto, update tests commit d921970aadf03b3cf0e71becdaab3147ba71cdef Merge: 1c002dd. 35cfb2b. Author: Scott Chacon Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b Author: Scott Chacon Date: Thu Dec 11 14:58:32 2008 -0800 Add some blame and merge stuff

Предположим, что в нашем примере это коммит 1c002dd…. . Если вы хотите выполнить для него git show , то следующие команды эквиваленты (предполагается, что сокращения однозначны):

$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b $ git show 1c002dd4b536e7479f $ git show 1c002d

Git может вычислить уникальные сокращения для ваших значений SHA-1. Если вы передадите опцию —abbrev-commit команде git log , в выводе будут использоваться сокращённые значения, сохраняющие уникальность; по умолчанию используется семь символов, но для сохранения уникальности SHA-1 могут использоваться более длинные значения.

$ git log --abbrev-commit --pretty=oneline ca82a6d Change the version number 085bb3b Remove unnecessary test code a11bef0 Initial commit

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

Например, в ядре Linux, который является довольно большим проектом с более чем 450 тыс. коммитов и 3.6 млн. объектов, отсутствуют объекты, чьи SHA-1 совпадают более чем в 11 первых символах.

Примечание
Небольшое замечание о SHA-1

Большинство людей в этом месте начинают беспокоиться о том, что будет, если у них в репозитории случайно появятся два объекта с одинаковыми значениями SHA-1. Что тогда?

Если вы вдруг зафиксируете объект, который имеет такое же значение SHA-1, как и предыдущий объект в вашем репозитории, Git увидит этот предыдущий объект в своей базе и посчитает, что он уже был записан. Если вы позже попытаетесь переключиться на этот объект, то вы всегда будете получать данные первого объекта.

Однако, вы должны осознавать, насколько маловероятен такой сценарий. Длина SHA-1 составляет 20 байт или 160 бит. Количество случайно хешированных объектов, необходимых для достижения 50% вероятности возникновения коллизии, равно примерно 2 80 . (формула для определения вероятности возникновения коллизии p = (n(n-1)/2) * (1/2^160)) . 2 80 — это 1.2 × 10 24 , или 1 миллион миллиардов миллиардов, что в 1200 раз больше количества песчинок на земле.

Приведём пример, чтобы дать вам представление, чего будет стоить получение коллизии SHA-1. Если бы все 6.5 миллиардов человек на Земле были программистами, и ежесекундно каждый из них производил количество кода, эквивалентное всей истории ядра Linux (3.6 миллиона Git-объектов), и отправлял его в один огромный Git репозитории, то потребовалось бы около 2 лет, пока этот репозиторий накопил бы количество объектов, достаточное для 50% вероятности возникновения SHA-1 коллизии. Более вероятно, что каждый член вашей команды в одну и туже ночь будет атакован и убит волками в несвязанных друг с другом происшествиях.

Если выделить на это несколько тысяч долларов вычислительной мощности, можно будет синтезировать два файла с одним и тем же хешем, что было доказано проектом https://shattered.io/ в феврале 2017 года. Git движется к использованию SHA256 в качестве алгоритма хеширования по умолчанию, который намного более устойчив к атакам с коллизиями и имеет код, помогающий смягчить эту атаку (хотя он не может полностью её устранить).

Ссылки на ветки

Для наиболее простого способа указать коммит требуется существование ветки, указывающей на этот коммит. Тогда вы можете использовать имя ветки в любой команде Git, которая ожидает коммит или значение SHA-1. Например, если вы хотите просмотреть последний коммит в ветке, то следующие команды эквивалентны (предполагается, что ветка topic1 указывает на коммит ca82a6d ):

$ git show ca82a6dff817ec66f44342007202690a93763949 $ git show topic1

Если вы хотите узнать SHA-1 объекта, на который указывает ветка, или увидеть к чему сводятся все примеры в терминах SHA-1, то вы можете воспользоваться служебной командой Git, называемой rev-parse . Служебные команды подробно рассмотрены в главе Git изнутри; в основном, команда rev-parse существует для низкоуровневых операций и не предназначена для ежедневного использования. Однако она может быть полезна, когда вам нужно увидеть, что в действительности происходит. Теперь вы можете выполнить rev-parse для вашей ветки.

$ git rev-parse topic1 ca82a6dff817ec66f44342007202690a93763949

RefLog-сокращения

Одна из вещей, которую Git делает в фоновом режиме, является ведение журнала ссылок, в котором сохраняется то, куда указывали HEAD и ветки за последние несколько месяцев.

Для просмотра этого журнала используется команда git reflog :

$ git reflog 734713b HEAD@: commit: Fix refs handling, add gc auto, update tests d921970 HEAD@: merge phedders/rdocs: Merge made by the 'recursive' strategy. 1c002dd HEAD@: commit: Add some blame and merge stuff 1c36188 HEAD@: rebase -i (squash): updating HEAD 95df984 HEAD@: commit: # This is a combination of two commits. 1c36188 HEAD@: rebase -i (squash): updating HEAD 7e05da5 HEAD@: rebase -i (pick): updating HEAD

Каждый раз когда по каким-то причинам изменяется вершина вашей ветки, Git сохраняет информацию об этом в эту временную историю. И вы можете указывать старые коммиты, используя эти данные. Например, чтобы посмотреть, куда ссылался указатель HEAD пять шагов назад, используйте ссылку @, которую можно увидеть в выводимых данных команды reflog:

$ git show HEAD@

Этот синтаксис используется и в случае, когда требуется посмотреть, в каком состоянии пребывала ветка некоторое время назад. В частности, чтобы увидеть где была ветка master вчера, следует написать:

$ git show master@

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

Для просмотра журнала ссылок в формате, похожем на вывод git log , вы можете выполнить git log -g :

$ git log -g master commit 734713bc047d87bf7eac9674765ae793478c50d3 Reflog: master@ (Scott Chacon ) Reflog message: commit: Fix refs handling, add gc auto, update tests Author: Scott Chacon Date: Fri Jan 2 18:32:33 2009 -0800 Fix refs handling, add gc auto, update tests commit d921970aadf03b3cf0e71becdaab3147ba71cdef Reflog: master@ (Scott Chacon ) Reflog message: merge phedders/rdocs: Merge made by recursive. Author: Scott Chacon Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs'

Важно отметить, что информация в журнале ссылок строго локальная — это лог того, что вы делали в вашем репозитории. Ссылки не будут такими же в других копиях репозитория; а сразу после первоначального клонирования репозитория, у вас будет пустой журнал ссылок, так как никаких действий в вашем репозитории пока не производилось. Команда git show HEAD@ будет работать только если вы клонировали проект по крайней мере два месяца назад — если вы клонировали его пять минут назад, то не получите никаких результатов.

Воспринимайте reflog Git как историю командной строки

Если у вас есть опыт работы с UNIX или Linux, можете думать о reflog как об истории командной строки Git, которая подчеркивает, что то, что там есть, явно актуально только для вас и вашего «сеанса» и не имеет ничего общего с кем-либо ещё, кто может работать на той же машине.

Примечание
Экранирование фигурных скобок в PowerShell

При использовании PowerShell фигурные скобки, такие как < и >, являются специальными символами и должны быть экранированы. Вы можете экранировать их с помощью апострофа ` или поместить ссылку на коммит в кавычки:

$ git show HEAD@ # НЕ будет работать $ git show HEAD@` # OK $ git show "HEAD@" # OK

Ссылки на предков

Ещё один популярный способ указать коммит — это использовать его родословную. Если вы поместите ^ в конце ссылки, Git поймёт, что нужно использовать родителя этого коммита. Предположим, история вашего проекта выглядит следующим образом:

$ git log --pretty=format:'%h %s' --graph * 734713b Fix refs handling, add gc auto, update tests * d921970 Merge commit 'phedders/rdocs' |\ | * 35cfb2b Some rdoc changes * | 1c002dd Add some blame and merge stuff |/ * 1c36188 Ignore *.gem * 9b29157 Add open3_detach to gemspec file list

Для просмотра предыдущего коммита достаточно написать HEAD^ , что означает «родитель HEAD»:

$ git show HEAD^ commit d921970aadf03b3cf0e71becdaab3147ba71cdef Merge: 1c002dd. 35cfb2b. Author: Scott Chacon Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs'

Примечание
Экранирование карета в Windows

В командной строке Windows ( cmd.exe ) ^ является специальным символом и требует другого обращения. Вы можете либо удвоить его, либо поместить ссылку на коммит в кавычки:

$ git show HEAD^ # НЕ будет работать в Windows $ git show HEAD^^ # OK $ git show "HEAD^" # OK

Также вы можете указать число после ^ — например, d921970^2 означает «второй родитель коммита d921970». Такой синтаксис полезен только для коммитов слияния, которые имеют больше одного родителя. Первым родителем является ветка, в которую вы выполняли слияние, а вторым — коммит в ветке, которую вы сливали:

$ git show d921970^ commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b Author: Scott Chacon Date: Thu Dec 11 14:58:32 2008 -0800 Add some blame and merge stuff $ git show d921970^2 commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548 Author: Paul Hedderly Date: Wed Dec 10 22:22:03 2008 +0000 Some rdoc changes

Второе важное обозначение для указания предков это символ тильда ~ . Он также соответствует ссылке на первого родителя, поэтому HEAD~ и HEAD^ эквивалентны. Различия становятся заметными, когда вы указываете число. HEAD~2 означает «первый родитель первого родителя» или «дедушка» — при этом происходит переход от заданного предка вглубь указанное число раз. К примеру, для показанной ранее истории, коммитом HEAD~3 будет:

$ git show HEAD~3 commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d Author: Tom Preston-Werner Date: Fri Nov 7 13:47:59 2008 -0500 Ignore *.gem

То же самое можно записать как HEAD~~~ , что также является первым родителем первого родителя первого родителя:

$ git show HEAD~~~ commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d Author: Tom Preston-Werner Date: Fri Nov 7 13:47:59 2008 -0500 Ignore *.gem

Вы также можете совмещать эти обозначения — можно получить второго родителя предыдущей ссылки (предполагается, что это коммит слияния) используя запись HEAD~3^2 , и так далее.

Диапазоны коммитов

Теперь вы умеете указывать отдельные коммиты, давайте посмотрим как указывать диапазоны коммитов. Это в частности полезно для управления вашими ветками — если у вас есть множество веток, вы можете использовать указание диапазонов коммитов для ответа на вопрос «Что было сделано в этой ветке, что я ещё не слил в основную ветку?»

Две точки

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

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

Рисунок 136. Пример истории для выбора диапазонов коммитов

Вы хотите посмотреть что находится в вашей экспериментальной ветке, которая ещё не была слита в основную. Вы можете попросить Git отобразить в логе только такие коммиты, используя запись master..experiment — она означает «все коммиты, которые доступны из ветки experiment , но не доступны из ветки master ». Для краткости и наглядности в этих примерах вместо настоящего вывода лога мы будем использовать для коммитов их буквенные обозначения из диаграммы, располагая их в должном порядке:

$ git log master..experiment D C

С другой стороны, если вы хотите наоборот увидеть все коммиты ветки master , которых нет в ветке experiment , вы можете поменять имена веток в команде. При использовании записи experiment..master будут отображены все коммиты ветки master , недоступные из ветки experiment :

$ git log experiment..master F E

Это полезно если вы хотите сохранить ветку experiment в актуальном состоянии и просмотреть, какие изменения нужно в неё слить. Другое частое использование такого синтаксиса — просмотр того, что будет отправлено в удалённый репозиторий.

$ git log origin/master..HEAD

Такая команда покажет вам все коммиты вашей текущей ветки, которые отсутствуют в ветке master удалённого репозитория origin . Если вы выполните git push , находясь на ветке, отслеживающей origin/master , то коммиты, отображённые командой git log origin/master..HEAD , будут теми коммитами, которые отправятся на сервер. Вы также можете опустить одну из частей в такой записи, Git будет считать её равной HEAD . Например, вы можете получить такой же результат как в предыдущем примере, выполнив git log origin/master.. — Git подставит HEAD , если одна часть отсутствует.

Множественная выборка

Запись с двумя точками полезна как сокращение, но, возможно, вы захотите использовать более двух веток для указания нужной ревизии, например, для того, чтобы узнать какие коммиты присутствуют в любой из нескольких веток, но отсутствуют в ветке, в которой вы сейчас находитесь. Git позволяет сделать это, используя символ ^ или опцию —not , перед любой ссылкой, доступные коммиты из которой вы не хотите видеть. Таким образом, следующие три команды эквивалентны:

$ git log refA..refB $ git log ^refA refB $ git log refB --not refA

Этот синтаксис удобен, так как позволяет указывать в запросе более двух ссылок, чего не позволяет сделать синтаксис с двумя точками. Например, если вы хотите увидеть все коммиты, доступные из refA и refB , но не доступные из refC , вы можете использовать одну из следующих команд:

$ git log refA refB ^refC $ git log refA refB --not refC

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

Три точки

Последний основной способ выбора ревизий — это синтаксис с тремя точками, который обозначает все коммиты, доступные хотя бы из одной ссылки, но не из обеих сразу. Вспомните пример истории коммитов в Пример истории для выбора диапазонов коммитов. Если вы хотите узнать какие коммиты есть либо в ветке master , либо в experiment , но не в обеих сразу, вы можете выполнить:

$ git log master. experiment F E D C

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

В таких случаях с командой log часто используют опцию —left-right , которая отображает сторону диапазона, с которой был сделан каждый из коммитов. Это делает данную информацию более полезной:

$ git log --left-right master. experiment < F < E >D > C

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

Введение в Git: настройка и основные команды

Как установить и настроить Git в различных ОС, создать новые и клонировать существующие репозитории, а также базовые концепции ведения веток.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.

В целом СКВ можно разделить таким образом:

Локальные — все файлы хранятся только в вашей операционной системе, например, разложены по папкам с версиями.
Централизованные — проект хранится на сервере, а ваша рабочая версия включает только текущий набор файлов.
Распределенные — копии проекта (и вся информация о версиях) располагаются не только на сервере, но и на нескольких клиентских машинах, чтобы обеспечить устойчивость к отказу сервера.

Очевидно, что Git — не единственная система контроля версий, однако по многим параметрам самая удобная и популярная на сегодняшний день. Благодаря распределенной структуре репозитории Git хранятся на всех клиентских компьютерах, что защищает от потерь данных и позволяет полноценно управлять версиями проекта оффлайн.

Главная отличительная черта Git состоит в подходе к обработке данных. Каждый раз при сохранении данных проекта (коммите) система фиксирует состояние файла (делает снимок) и создает ссылку на этот снимок. Последующие изменения отражаются через ссылки на более ранние версии файла. Нет необходимости снова сохранять файл целиком. К тому же, основываясь на контрольных hash-суммах, система снимков обеспечивает целостность всей истории изменений. На практике это означает, что невозможно (либо крайне трудно) полностью удалить данные из рабочего каталога и утратить к ним любой доступ. В большинстве случаев данные можно восстановить из ранней версии проекта.

Таким образом, систему контроля версий в Git проще всего представлять как поток снимков (сохраненных состояний проекта).

Принципы работы с Git

У проектных файлов в Git есть 3 базовых состояния

Измененные (modified) — файлы в процессе рабочего редактирования.
Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.

У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.

Чаще всего работа с Git устроена примерно так:

Вы вносите правки в файлы рабочей копии проекта.
Индексируете их, подготавливая к коммиту (здесь Git создает снимки новых правок).
Делаете коммит, и индексированные правки наконец сохраняются в вашем каталоге Git.

Установка Git

Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).

Однако командная строка все равно удобна для тонкой настройки и «нестандартных» действий, поэтому полезно представлять себе, как управлять проектом через нее.

Сначала потребуется установить Git на свой компьютер.

Установка в Linux

Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:

> sudo dnf install git-all

На Ubuntu и других Debian-подобных систем введите apt:

> sudo apt install git

Более подробные сведения можно получить по ссылке: https://git-scm.com/download/linux.

Установка на Mac

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

> git --version

И следовать дальнейшим инструкциям.

Если вы пользуетесь Homebrew, запустите команду:

$ brew install git

Установка в Windows

Новейшая сборка доступна на официальном сайте Git по ссылке: https://git-scm.com/download/win (загрузка запустится автоматически).

Настройка Git

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

Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:

Параметры из файла [path]/etc/gitconfig (системные) могут работать для всех пользователей системы и репозиториев. Они редактируются командой git config —system.
Параметры из файла ~/.gitconfig или ~/.config/git/config (глобальные) применяются к одному пользователю, если запустить команду git config —global.
Локальные параметры из файла config в рабочем каталоге .git/config сохраняют только для выбранного репозитория. Ему соответствует команда git config —local.

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

Всю используемую конфигурацию можно просмотреть так:

> git config --list --show-origin

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

> git config --global user.name "Danil Z" > git config --global user.email danilz@danilz.com

Также можно выбрать и текстовый редактор, введя команду git config —global core.editor. Например, чтобы выбрать Emacs, выполните:

> git config --global core.editor emacs

В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:

> git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

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

Общий список текущих настроек просматривается с помощью команды git config —list. Проверить, что записано в любой из доступных настроек, можно командой с ключом git config :

> git config user.email

Выбор ветки по умолчанию

Итак, наконец можно создать репозиторий в выбранном каталоге командой git init. Основная ветка автоматически будет названа master. Изменить это (в нашем случае задав ветку main) можно так:

> git config --global init.defaultBranch main

Работа в репозитории

Как правило, есть два варианта начать работу с репозиторием Git:

Можно выбрать локальный каталог и создать новый репозиторий в нем.

Можно клонировать существующий репозиторий с локального компьютера или сервера. Обычно проекты клонируются именно с сервера.

Если у вас на компьютере уже есть рабочий проект, но еще не назначен контроль версий, то нужно сначала перейти в каталог проекта.

> cd /home/user/SomeConsoleApp

> cd /Users/user/SomeConsoleApp

> cd C:/Users/user/SomeConsoleApp

> git init

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

И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add .

Заодно создадим начальный коммит командой git commit:

> git add readme.md > git commit -m 'Initial project version'

Команду git add можно гибко настраивать с помощью дополнительных параметров (флагов), которые подробно описаны в официальной документации: https://git-scm.com/docs/git-add. К примеру, команда git add —force добавит даже игнорируемые файлы, а git add —update позволит обновить отслеживаемые файлы.

В этом репозитории вы можете продолжать работать и дальше, со временем обновляя его и отправляя рабочие версии на сервер.

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

Когда вы работаете в команде, разрабатываемые проекты часто размещают на сервере. Это один из самых распространенных сценариев. Вам нужно получить копию проекта последней версии на свой компьютер, чтобы далее вносить в него свой вклад.

В качестве примера мы будем рассматривать проект, который создадим на ресурсе https://github.com/ . После регистрации на сайте и подтверждения по e-mail нужно создать новый репозиторий, как показано на скриншотах.

Видно, что можно выбрать тип репозитория:

публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;

приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.

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

Самые удобные способы клонирования проекта — через протоколы HTTP и SSH, прочесть обо всех более развёрнуто можно по ссылке: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols.

Для наших целей воспользуемся протоколом https и следующей командой:

> git clone https://github.com/DanZDev2/SomeConsoleApp SomeConsoleApp

На вашем компьютере в каталоге, куда вы перешли в командной строке, должен появиться каталог SomeConsoleApp, внутри него — каталог .git и все скачанные файлы репозитория последней версии.

После получения проекта обычно начинается более рутинный рабочий процесс — правки, добавление функционала и т. д. Далее в какой-то момент вы захотите сохранить прогресс в новой версии проекта.

Правила и периодичность обновления могут быть почти любыми, но хорошим тоном обычно считается сохранять рабочую (или промежуточно завершенную) версию. Важное требование для команд разработчиков — возможность сборки проекта, иначе другие участники команды будут вынуждены тратить время на борьбу с ошибками компиляции.

Сохранение снимков и просмотр статуса проекта

Как упоминалось ранее, часть файлов в рабочем каталоге может и не находиться под контролем версий. За отслеживаемыми файлами «наблюдает» Git, они были как минимум в прошлом снимке состояния проекта. Неотслеживаемыми могут быть, например, вспомогательные файлы в рабочем проекте, если они не зафиксированы в прошлой версии проекта и не готовы к коммиту. Их можно выделить в отдельную категорию для Git, о чем будет рассказано далее.

Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.

При этом нужно внимательно следить, чтобы вспомогательные файлы, особенно объемные, оставались вне контроля версий. Если по недосмотру добавить их в коммит и отправить на сервер — вероятнее всего, ваши правки придется частично откатывать.

Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:

On branch master Your branch is up to date with ‘origin/master’. nothing to commit, working tree clean

Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:

>git status On branch master Your branch is up to date with ‘origin/master’. Untracked files: (use “git add . ” to include in what will be committed) Program.cs SomeConsoleApp.csproj SomeConsoleApp.sln nothing added to commit but untracked files present (use “git add” to track)

Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.

Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:

> git commit -m "Task 2: basic project template added"

Для удаления ненужных файлов из репозитория можно использовать команду git rm . Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.

Файл .gitignore

Как упоминалось ранее, в рабочий каталог могут попадать файлы, которые вам бы не хотелось отправлять на сервер. Это и документы с вашими экспериментами или образцами, и автоматически генерируемые части проекта, актуальные только на вашем компьютере. Git может полностью игнорировать их, если создать в рабочем каталоге файл с названием .gitignore и внести в него все имена ненужных файлов и папок.

Открывать файл можно в любом текстовом редакторе. Обычно удобнее не перечислять абсолютно все имена (которые к тому же всегда известны), а воспользоваться подобными инструкциями:

/bin /obj *.pdb *.exe

Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.

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

Управление удаленными репозиториями

Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add , например:

>git remote add myDemo https://github.com/DanZDev2/DemoApp >git remote myDemo origin

Отправка изменений в удаленный репозиторий (Push)

На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.

Команда для отправки изменений на сервер такова: git push . Если ваша ветка называется master, то команда для отправки коммитов станет такой:

> git push origin master

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

Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.

Получение изменений из репозитория (Pull)

Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.

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

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

Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch дважды с разными аргументами:

>git branch Dev >git branch Test

Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout :

>git checkout Dev Switched to branch ‘Dev’ Your branch is up to date with ‘origin/Dev’.

Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:

>git add . >git commit -m “dev readme changed” [Dev #####] dev readme changed 1 file changed, 2 insertions(+)

Если теперь отправить их на сервер, то можно убедиться в появившемся отличии веток:

Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.

Слияние веток (merge)

Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge :

>git merge Dev Updating #####..##### Fast-forward README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Изменения успешно перенесены. В наших упрощенных условиях команда завершилась без ошибок, не найдя конфликтов в файлах. Если же над общими участками какого-либо файла успели поработать несколько человек, с этим нужно разбираться вручную. При возникновении ошибок Git помечает общие части файлов из разных веток и сообщает о конфликте.

Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.

Когда спорные участки всех файлов приведены к итоговому состоянию, нужно повторить стандартную процедуру: создать коммит и отправить их командой push в нужную ветку в репозитории.

Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:

pull (забрать изменения с сервера);

внести правки, добавить что-то важное в проекте;
add (добавить изменённые файлы к коммиту);

commit (сохранить состояние проекта с комментариями);

push (отправить изменения на сервер).

merge (при необходимости внедрить изменения из другой ветки проекта).

Заключение

Мы рассмотрели, как устанавливать и настраивать Git в различных ОС, создавать новые и клонировать существующие репозитории, получать и отправлять новые версии проекта, а также ознакомились с базовыми концепциями ведения веток.

Этой информации обычно хватает для повседневных задач, связанных с хранением рабочих проектов.

Знакомство с Git и GitHub: обзор и руководство для начинающих

Git — распределенные системы контроля версий, которые помогают обмениваться кодом и «ковать» проекты в команде — отслеживать и контролировать все изменения в коде. Если вы занимаетесь разработкой приложений, веб-сайтов или игр, то наверняка сталкивались с этим.

Одна из таких систем — GitHub — платформа для хостинга репозиториев. Расскажем о ней подробнее: как зарегистрироваться, создать проект, вносить в него изменения и не столкнуться с конфликтами версий.

Регистрация на GitHub: создание аккаунта

Для работы с платформой нужно создать аккаунт. Для этого переходим по ссылке и тапаем по кнопке Sign up.

Адрес электронной почты. Если на почту уже был зарегистрирован аккаунт, на странице появится сообщение об ошибке: «Email is invalid or already taken».

Пароль. Система рекомендует использовать для пароля последовательность из 15 символов или 8, но с использованием хотя бы одной цифры и строчной буквы.

Имя пользователя. «Юзернейм» должен быть уникальным. При этом он не может начинаться или заканчиваться дефисом.

Теперь нужно нажать кнопку Continue, принять или отклонить предложение о подписке на рассылку и пройти экстравагантную валидацию:

Затем подтвердите адрес электронной почты.

Во всплывающих окнах указывайте настройки на свое усмотрение. Для ознакомления и некоммерческого использования достаточно бесплатного тарифа. Регистрация завершена.

Установка Git

Для работы с репозиторием необходимо скачать Git-терминал или GitHub Desktop. Что из этого выбрать — решать вам. Но предпочтительней уметь работать с командной строкой Git. Такое требование часто можно встретить в вакансиях. Вдобавок, знание командной строки позволяет работать с другими платформами, подобными GitHub.

Терминал

Если у вас установлен Linux, смело пропускайте раздел. С Mac и Windows другая история.

Mac OS

Если вы пользовались XCode, вероятно, Git уже установлен. В противном случае зайдите в терминал, выполните команду git и нажмите кнопку Установить.

После установки можно узнать версию Git.

git --version

Windows

На винду Git можно скачать с официального сайта или через пакет Git Chocolatey. Дополнительная информация о Git Windows доступна по ссылке.

GitHub Desktop. Краткий обзор

Непривычна работа в командной строке — установите «десктопную» версию (доступна на всех ОС). Она хорошо подходит для базовых операций.Установщик есть на официальной странице GitHub Desktop. Там же и наиболее подробное описание программы.

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

А после — интерфейс с привычным функционалом: можно создавать и клонировать репозитории.

Важно отметить, что установка GitHub Desktop на Linux может отличаться в зависимости от дистрибутива. Рекомендуем ознакомиться с официальной инструкцией.

Создание первого репозитория

После регистрации и настройки рабочего окружения можно приступить к работе с проектом. Для начала создадим репозиторий на GitHub — облачное пространство, в котором размещаются файлы проекта и его документация. Существует несколько способов.

Первый способ — синхронизация с локальным репозиторием

Допустим, нам нужно выложить в открытый доступ код программы Selectel — определитель динозавров по фотографиям.

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

Для этого необходимо зайти в терминал, перейти в директорию проекта и ввести команду:

git init

Загрузка файлов в репозиторий. Создание коммитов

Далее следует добавить все файлы проекта в своеобразный пакет изменений и сделать commit («закоммитить») — загрузить изменения.

git add main.py git add GAN_core.py git add dino_ds_api.py git commit -m “первый коммит”

Последняя команда делает сам «коммит», а флаг -m указывает на сообщение «первый коммит».

В примере были «закоммичены» несколько python-файлов: main, GAN_core и dino_ds_api. Если вам нужно добавить в «коммит» все, что есть в директории, — используйте команду:

git add .

Теперь создадим репозиторий на GitHub. Для этого нужно нажать на кнопку Create repository.

В открывшемся окне обязательно к заполнению только поле с названием проекта. Оно должно быть кратким, но понятным. В нашем примере это gan-dino (gan от generative adversarial networks и dino от dinosaur).

Все остальное опционально:

Описание. Поле с кратким описанием проекта.

Режим доступа. Для коммерческих или корпоративных продуктов обычно устанавливается режим private (репозиторий доступен ограниченному кругу лиц). В остальных случаях — public (доступно по ссылке).

Файл README. Если в репозитории нужно подробное описание проекта — поставьте галочку рядом с Add a README file. Но есть нюанс: для первого способа создания репозитория галочки быть не должно.

Конфигурация .gitignore. Бывает, что в проекте нужно разместить невидимые для Git файлы. Чтобы как-то их обозначить, придумали конфигурацию .gitignore, в которой их можно перечислить.

Лицензия. Чтобы никто не использовал ваш код в коммерческих целях без спроса, необходимо добавить файл с лицензией. В нем правообладатели прописывают правила использования своей интеллектуальной собственности.

Создадим public-проект gan-dino, без файла README и конфигурации .gitignore.

Далее GitHub показывает наборы команд, необходимые для загрузки исходного кода в репозиторий. Нас интересует второй блок.

git remote add origin https://github.com/t-rex-general/gan-dino.git git branch -M main git push -u origin main

Первая строка загружает origin — прообраз нашего проекта в глобальном репозитории. Со второй командой мы познакомимся позже. Третья команда загружает (пушит) изменения в GitHub-репозиторий.

После ввода команд система попросит авторизоваться с помощью пароля и названия профиля.

После 13 августа 2021 года вместо пароля нужно вводить токен.

Откройте настройки вашего аккаунта, выберите пункт меню Developer settings, кликните по Personal access tokens и generate new token. А затем повторите попытку.

Получилось! В репозиторий загрузились нужные файлы. Можно смело делиться ссылкой на него.

Второй способ — от глобального к локальному

Бывает другая ситуация, когда кода программы нет и нужно создать пустой репозиторий на GitHub, а после — сделать его локальный дубликат. Данный процесс называется локальным развертыванием.

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

Чтобы клонировать этот репозиторий себе на компьютер, нужно нажать на зеленую кнопку Code, скопировать HTTPS-адрес, перейти в терминал, в нужную директорию и ввести команду:

git clone https://github.com/t-rex-general/gan-dino2.git

В результате файл README.md появится в выбранной директории — локальном репозитории.

С помощью этой же команды можно клонировать и чужие проекты. Например, чтобы не писать все модули для определителя динозавров самостоятельно, можно клонировать чужой репозиторий себе на компьютер. Или сделать fork («форк»), то есть скопировать чей-то проект в свой GitHub-профиль для его доработки.

Третий способ — внутри GitHub

Если нет возможности использовать Git-терминал или GitHub Desktop, можно работать напрямую с GitHub. Перед этим создаем репозиторий с файлом README.

Внутри GitHub есть онлайн-редактор кода и интерфейс работы с пространством имен (создание файлов, директорий и загрузка других элементов).

Например, для создания нового файла достаточно нажать на кнопку Create new file. Откроется встроенный редактор кода.

Потом необходимо сделать коммит.

Работа с ветками

С точки зрения Git, весь процесс разработки — это история коммитов. Такие истории называются ветками — своеобразными указателями на последний коммит.

Два программиста работают над одним контроллером для авторизации. Первому нужно написать шифрование пароля по заданному «юзер-токену», а второму — запрограммировать регистрацию информации в базу данных. Разработчики обнаружили, что у токена не тот тип данных, и решают преобразовать его, используя новую переменную. Они это сделают по-разному. Но ничего страшного: каждый из них работал в своей ветке и заметит конфликт при их слиянии.

Создание веток через Git

Чтобы создать ветку (например, dev) в проекте, нужно ввести команду:

git branch dev

После ветка появится в общем списке.

git branch

Видно, что выбрана ветка main, то есть все коммиты загружаются в нее. Чтобы работать с веткой dev, нужно переключиться.

git checkout dev

Попробуем изменить файл проекта и загрузить коммит.

git add main.py git commit -m “добавили if”

Теперь можно посмотреть логи — историю добавления коммитов.

Действительно, второй коммит «улетел» в ветку dev. Если нас не устроили изменения, можно откатиться до предыдущего (любого) коммита по его номеру.

git checkout 61a8f08226eb8067d4e356387f1dcce5c79812dd

Чтобы запушить ветку в онлайн-репозиторий введем команду:

git push --set-upstream origin dev

Открываем репозиторий в GitHub и видим, что добавилась ветка dev:

Но если мы зайдем в main.py, то никаких изменений там не обнаружим, пока не выберем ветку dev.

Чтобы изменения затронули и main-ветку, нужно сделать merge — слияние веток.

Создание веток через GitHub

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

В рамках веток можно также вносить изменения — механизм работы не меняется.

Слияние веток проекта

Мы почти разработали свой проект. Самое время объединить ветки dev и main.

Первым шагом необходимо переместиться в ветку main:

git checkout main

Вторым шагом — сделать merge с веткой dev и запушить изменения:

git merge dev git push

Теперь в GitHub-репозитории отображается актуальная информация.

Работа в команде: конфликты версий и git pull

После релиза нашего приложения прошло немало времени. Пользователи приложения требуют обновлений, а в команду пришли еще два разработчика — Василий и Григорий.

Было принято решение добавить в программу новую функцию — определитесь массы динозавра на изображении.

Однако в команде не была налажена совместная работа, и оба программиста внесли изменения, не посоветовавшись друг с другом. Помимо прочего, у них были равносильные права доступа к репозиторию, из-за чего Вася даже успел запушить обновление на GitHub.

Код различается: в программе слева выводится максимальная масса динозавра, а справа — последовательность из возможных значений.

Гриша пытается сделать коммит и пуш своей программы, но сталкивается с ошибкой — конфликтом версий, когда изменения от разных кодеров накладываются друг на друга.

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

git pull

Если это сделать, в файле main.py появится структура, в которой будут видны изменения, которые внесли Вася и Гриша.

Теперь, если Василий считает свою версию более важной, он может убрать код Гриши из программы, и сделать пуш:

git add main.py git commit -m “dino_weight” git push

Репозиторий успешно обновлен.

На практике конфликтов гораздо больше и разрешаться они могут по-разному. Важно научиться серфить по руководству git и гуглить. Впрочем, это относится ко всему процессу изучения Git и GitHub.

Fork и Pull Request

Бывает, что ваш репозиторий кто-то форкает и вносит свои коррективы. Вы можете даже не знать, кто инициатор. Если он захочет поделиться корректировками с вами, то создаст запрос слияния (Pull Request).

Зайдем с другого аккаунта, найдем репозиторий gan-dino через поисковую систему в GitHub и сделаем форк.

В нашем списке репозиториев появился новый gan-dino-FORK — это форк-образ gan-dino. Теперь можно внести изменения, например, в main.py, и сделать pull request.

Затем владельцу репозитория нужно подтвердить или отклонить запрос. Чтобы это сделать, нужно перейти во вкладку «Pull requests», выбрать интересующий pull-запрос и нажать одну из предложенных кнопок.

Домашнее задание

Любой конкурентоспособный разработчик должен разбираться в Git. Нелишним будет и знание GitHub, в котором есть много возможностей, значительно упрощающих работу над проектами в команде (project management). Например, дашборды во вкладке Projects, повторяющие функционал Trello и Jira.

GitHub — это целая социальная сеть для разработчиков из разных частей света.

На этом наш краткий обзор GitHub и Git подошел к концу. Мы рассмотрели, как создавать аккаунты GitHub и работать с репозиториями через терминал Git (регистрация и установка, коммиты, пуши и пулы изменений). Это основное. Более подробную информацию можно найти в справочниках Git и GitHub.

Используем GitHub в разработке сервисов

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

Если у вас остались вопросы по работе с Git или GitHub, напишите нам.

Начало работы с Git: подробный гайд для новичков

Привет тебе, будущий Senior Software Engineer. Сегодня поговорим о системе контроля версий, а именно о Git (читается как ГИТ, а не ДЖИТ, как могло бы показаться из грамматики английского языка). Да-да, я знаю что есть еще и Mercurial, SVN… Но будем откровенны: их время уже ушло, и тратить ваше драгоценное время на них не собираюсь. Чтобы вы понимали важность знания гита в наше время, скажу так: без знания/понимания этого вам делать в программировании нечего. Но прелесть в том, что для постоянной работы не нужно держать в голове все команды и возможности. Нужно знать набор команд, которые помогут понимать всё, что происходит.

Основы Git

Git — это распределенная система контроля версий нашего кода. Зачем она нам? Для распределенных команд нужна какая-то система управления работы. Нужна, чтобы отслеживать изменения, которые происходят со временем. То есть шаг за шагом мы видим, какие файлы изменились и как. Особенно это важно, когда анализируешь, что было проделано в рамках одной задачи: это дает возможность возвращаться назад. Представим себе ситуацию: был работающий код, всё в нем было хорошо, но мы решили что-то улучшить, там подправить, сям подправить. Все ничего, но такое улучшение поломало половину функционала, сделало невозможным работу. И что дальше? Без Гита нужно было бы часами сидеть и вспоминать, как же все было изначально. А так мы просто откатываемся на коммит назад — и все. Или что делать, если есть два разработчика, которые делают одновременно свои изменения в коде? Без Гита это выглядит так: они скопировали код из оригинала, сделали что нужно. Наступает момент, и оба хотят добавить свои изменения в главную папку. И что делать в этой ситуации. Я даже не берусь оценить время, чтоб проделать эту работу. Таких проблем не будет вовсе, если пользоваться Гитом.

Установка Git

Установим гит на компьютер. Я понимаю, что у всех разные OS, поэтому постараюсь описать для нескольких случаев.

Установка для Windows

Как обычно, нужно скачать exe файл и запустить его. Здесь все просто: жмем на первую ссылку гугла, устанавливаем и всё. Для работы будем использовать bash консоль, которую они предоставляют. Чтобы работать в виндоусе, нужно запустить Git Bash. Вот как он выглядит в меню пуск: И это уже консоль, в которой можно работать. Чтобы не переходить каждый раз в папку с проектом, чтобы там открыть гит, можно в папке правой кнопкой мыши открыть консоль с нужным нам путем:

Установка для Linux

Обычно git уже установлен и есть в дистрибутивах линукса, так как это инструмент, первоначально написанный для разработки ядра линукса. Но бывают ситуации, когда его нет. Чтобы проверить это, нужно открыть терминал и прописать: git —version. Если будет вразумительный ответ, ничего устанавливать не нужно. Открываем терминал и устанавливаем. Я работаю на Ubuntu, поэтому могу сказать, что писать для нее: sudo apt-get install git. И все: теперь в любом терминале можно пользоваться гитом.

Установка на macOS

Здесь также для начала нужно проверить, есть ли уже гит (смотри выше, как на линуксе). Если все же нет, самый простой путь — это скачать отседова последнюю версию. Если установлен XCode, то гит уже точно будет автоматически установлен.

Настройка гита

У гита есть настройка пользователя, от которого будет идти работа. Это разумная и необходимая вещь, так как когда создается коммит, гит берет именно эту информацию для поля Author. Чтобы настроить имя пользователя и пароль для всех проектов, нужно прописать следующие команды:

git config --global user.name ”Ivan Ivanov” git config --global user.email ivan.ivanov@gmail.com

Если есть необходимость для конкретного проекта поменять автора (для личного проекта, например), можно убрать —global, и так получится:

git config user.name ”Ivan Ivanov” git config user.email ivan.ivanov@gmail.com

Немного теории…

гит репозиторий (git repository);

коммит (commit);

ветка (branch);

смерджить (merge);

конфликты (conflicts);

спулить (pull);

запушить (push);

как игнорировать какие-то файлы (.gitignore).

Состояния в Гит

неотслеживаемое (untracked);

измененное (modified);

подготовленное (staged);

закомиченное (committed).

Как это понимать?

Это состояния, в которых находятся файлы из нашего кода. То есть, их жизненный путь обычно выглядит так:

Файл, который создан и не добавлен в репозиторий, будет в состоянии untracked.

Делаем изменения в файлах, которые уже добавлены в гит репозиторий — находятся в состоянии modified.

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

Из заготовленных файлов из состояния staged создается коммит и переходит уже в гит репозиторий. После этого staged состояние — пустое. А вот modified еще может что-то содержать.

Выглядит это так (картиночка из официальной доки, так что можно верить)):

Что такое коммит

Коммит — это основной объект в управлении контроля версий. Он содержит все изменения за время этого коммита. Коммиты связаны между с собой как односвязный список. А именно: Есть первый коммит. Когда создается второй коммит, то он (второй) знает, что идет после первого. И таким образом можно отследить информацию. Также у коммита есть еще своя информация, так называемые метаданные:

уникальный идентификатор коммита, по которому можно его найти;

имя автора коммита, который создал его;

дата создания коммита;

комментарий, который описывает, что было сделано во время этого коммита.

Вот как это выглядит:

Что такое ветка

Ветка — это указатель какого-то коммита. Так как коммит знает, какой коммит был до него, когда ветка указывает на какой-то коммит, к ней относятся и все те предыдущие. Исходя из этого можно сказать, что веток, указывающих на один и тот же коммит, может быть сколько угодно много. Работа происходит в ветках, поэтому когда создается новый коммит, ветка переносит свой указатель на более новый коммит.

Начало работы с Гитом

Можно работать и только с локальный репозиторием, и с удаленным. Для отработки нужных команд можно воспользоваться только локальным репозиторием. Он хранит всю информацию только локально в проекте в папке .git. Если говорить об удаленном, то вся информация хранится где-то на удаленном сервере: локально хранится только копия проекта, изменения которой можно запушить (git push) в удаленный репозиторий. Здесь и далее будем обсуждать работу с гитом в консоли. Конечно, можно пользоваться какими-то графическими решениями (например, в Intellij IDEA), но сперва нужно разобраться, какие команды происходят и что они значат.

Работа с гитом в локальном репозитории

Далее я предлагаю вам проделать все те шаги, которые проделал я, в то время как будете читать статью. Это улучшит ваше понимание и усвоение материала. Так что приятного аппетита 🙂 Чтобы создать локальный репозиторий, нужно написать:

git init

После этого будет создана папка .git в том месте, где находится консоль. .git — это папка, которая хранит всю информацию о гит репозитории. Ее удалять не нужно 😉 Далее, добавляются файлы в этот проект, и их состояние становится Untracked. Чтобы посмотреть, какой статус работы на данный момент, пишем:

git status

Мы находимся в master ветке, и пока мы не перейдем в другую, так все и останется. Таким образом видно, какие файлы изменены, но еще не добавлены в состояние staged. Чтобы добавить их в состояние staged, нужно написать git add. Здесь может быть несколько вариантов, например:

git add -A — добавить все файлы из состояния в staged;

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

git add — добавляет только конкретный файл. Здесь можно пользоваться регулярными выражениями, чтобы добавлять по какому-то шаблону. Например, git add *.java: это значит, что нужно добавить только файлы с расширением java.

Ясно, что первые два варианта простые, а вот с добавлением будет интереснее, поэтому пишем:

git add *.txt

Чтобы проверить статус, используем уже известную нам команду:

git status

Отсюда видно, что регулярное выражение отработало верно, и теперь test_resource.txt находится в staged состоянии. И, наконец, последний этап (при локальном репозитории, с удаленным будет еще один ;)) — закоммитить и создать новый коммит:

git commit -m “all txt files were added to the project”

Далее есть отличная команда, чтобы посмотреть на историю коммитов в ветке. Воспользуемся ею:

git log

Здесь уже видно, что появился наш первый коммит с текстом, который мы передали. Очень важно понять, что текст, который мы передаем, должен максимально точно определять то, что было проделано за этот коммит. Это в будущем будет помогать множество раз. Пытливый читатель, который еще не уснул, может сказать: а что случилось с файлом GitTest.java? Сейчас узнаем, используем для этого:

git status

Как видим, он так и остался в состоянии untracked и ждет своего часа. А может мы вовсе не хотим его добавлять в проект? Бывает и такое. Далее, чтобы стало интереснее, попробуем изменить наш текстовый файл test_resource.txt. Добавим туда какой-то текст и проверим состояние:

git status

Здесь хорошо видна разница между двумя состояниями — untracked и modified. GitTest.java находится в состоянии untracked, а test_resource.txt находится в modified. Теперь, когда уже есть файлы в состоянии modified, мы можем посмотреть на изменения, которые были произведены над ними. Сделать это можно при помощи команды:

git diff

То есть здесь хорошо видно, что я добавил в наш текстовый файл hello world! Добавляем изменения в текстовом файле и коммитим:

git add test_resource.txt git commit -m “added hello word! to test_resource.txt”

Чтобы посмотреть на все коммиты, пишем:

git log

Как видим, уже есть два коммита. Таким же образом добавляем и GitTest.java. Теперь без комментариев, просто команды:

git add GitTest.java git commit -m “added GitTest.java” git status

Работа с .gitignore

Ясно, что мы хотим хранить только исходный код и ничего другого в репозитории. А что может быть еще? Как минимум, скомпилированные классы и/или файлы, которые создают среды разработки. Чтобы гит их игнорировал, есть специальный файл, который нужно создать. Делаем это: создаем файл в корне проекта с названием .gitignore, и в этом файле каждая строка будет шаблоном для игнорирования. В этом примере гит игнор будет выглядеть так:

``` *.class target/ *.iml .idea/ ```

первая строка — это игнорирование всех файлов с расширением .class;

вторая строка — это игнорирование папки target и всего, что она содержит;

третья строка — это игнорирование всех файлов с расширением .iml;

четвертая строка — это игнорирование папки .idea.

git status

Ясно, что мы не хотим как-то случайно (если использовать git add -A) добавить скомпилированный класс в проект. Для этого создаем .gitignore файл и добавляем все, что описывалось ранее: Теперь добавим новым коммитом гит игнор в проект:

git add .gitignore git commit -m “added .gitignore file”

И теперь момент истины: у нас есть в untracked состоянии скомпилированный класс GitTest.class, который мы не хотели добавлять в гит репозиторий. Вот здесь-то и должен заработать гит игнор:

git status

Все чисто) Гит игнору +1)

Работа с ветками и иже с ним

Разумеется, работать в одной ветке неудобно одному и невозможно, когда в команде больше одного человека. Для этого существует ветвление. Как я уже говорил, ветка — это просто подвижный указатель на коммиты. В этой части рассмотрим работу в разных ветках: как смерджить изменения одной ветки в другую, какие могут возникнуть конфликты и многое другое. Чтобы посмотреть список всех веток в репозитории и понять, на какой находишься, нужно написать:

git branch -a

Видно, что у нас только одна ветка master, и звездочка перед ней говорит, что мы находимся на ней. К слову, чтобы узнать, на какой ветке мы находимся, можно воспользоваться и проверкой статуса (git status). Далее есть несколько вариантов создания веток (может их и больше, я использую эти):

создать новую ветку на основе той, на которой находимся (99% случаев);

создать ветку на основе конкретного коммита (1%).

Создаем ветку на основе конкретного коммита

Опираться будем на уникальный идентификатор коммита. Чтобы найти его, напишем:

git log

Я выделил коммит с комментарием “added hello world…”. У него уникальный идентификатор — “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Я хочу создать ветку development начиная с этого коммита. Для этого напишу:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Создается ветка, в которой будут только первые два коммита из ветки master. Чтобы проверить это, мы сперва убедимся, что перешли в другую ветку и посмотрим на количество коммитов ней:

git status git log

И правда: получилось, что у нас два коммита. Кстати, интересный момент: в этой ветке еще нет файла .gitignore, поэтому наш скомпилированный файл (GitTest.class) теперь подсвечивается в untracked состоянии. Теперь можем провести еще раз ревизию наших веток, написав:

git branch -a

Видно, что есть две ветки — master и development — и сейчас стоим на development.

Создаем ветку на основе текущей

Второй способ создания ветки — создание на основе другой. Я хочу создать ветку на основе master ветки, поэтому нужно сперва перейти на нее, а уже следующим шагом — создать новую. Смотрим:

git checkout master — переходим на ветку master;

git status — проверяем, точно ли на мастере.

Вот здесь видно, что мы перешли на master ветку, здесь уже работает гит игнор, и скомпилированный класс уже не светится как untracked. Теперь создаем новую ветку на основе master ветки:

git checkout -b feature/update-txt-files

Если есть сомнения, что эта ветка будет не такой же, как и master, можно это легко проверить, написав git log и посмотреть на все коммиты. Там их должно быть четыре.

Резолвим конфликты

Прежде чем разобраться с тем, что такое конфликт, нужно поговорить о слиянии (смердживании) одной ветки в другую. Вот такой картинкой можно показать процесс, когда одну ветку мерджат в другую: То есть, есть главная ветка. От нее в какой-то момент создают второстепенную, в которой происходят изменения. Как только работа сделана, нужно слить одну ветку в другую. Я не буду описывать разные особенности: я хочу донести в рамках этой статьи только понимание, а уже детали узнаете сами, если будет нужно. Так вот, на нашем примере, мы создали ветку feature/update-txt-files. Как написано в имени ветки — обновим текст. Теперь нужно создать под это дело новый коммит:

git add *.txt git commit -m “updated txt files” git log

Теперь, если мы хотим смерджить feature/update-txt-files ветку в master, нужно перейти в master и написать git merge feature/update-txt-files:

git checkout master git merge feature/update-txt-files git log

Как результат — теперь и в мастер ветке есть коммит, который был добавлен в feature/update-txt-files. Эта функциональность добавлена, поэтому можно удалить фиче (feature) ветку. Для этого напишем:

git branch -D feature/update-txt-files

Пока понятно, да? Усложняем ситуацию: теперь допустим, что опять нужно изменить txt файл. Но теперь еще и в мастере этот файл будет изменен также. То есть он будет параллельно изменяться, и гит не сможет понять что нужно делать в ситуации, когда мы захотим смерджить в master ветку новый код. Поехали! Создаем новую ветку на основе master, делаем изменения в text_resource.txt и создаем коммит под это дело:

git checkout -b feature/add-header . делаем изменения в файле

git add *.txt git commit -m “added header to txt”

Переходим на master ветку и также обновляем этот текстовый файл в той же строке, что и фиче ветка:

git checkout master … обновили test_resource.txt

git add test_resource.txt git commit -m “added master header to txt”

И теперь самый интересный момент: нужно смерджить изменения из feature/add-header ветки в master. Мы находимся в мастер ветке, поэтому нужно только написать:

git merge feature/add-header

Но мы получим результат с конфликтом в файле test_resource.txt: И здесь мы можем видеть, что гит не смог самостоятельно решить, как смерджить этот код и говорит, что нужно вначале разрезолвить конфликт, а уже потом сделать коммит. Ок, открываем в текстовом редакторе файл, в котором конфликт, и видим:Чтобы понять, что здесь сделал гит, нужно вспомнить, что мы где писали, и сравнить:

между “
между “=======” и “>>>>>>> feature/add-header” находятся изменения, которые были в feature/add-header ветке.

Таким образом гит показывает, что в этом месте он не смог понять, как слить воедино этот файл, разделил этот участок на две части из разных веток и предложил решить нам самим. Хорошо, твердою волей решаю убрать все, оставить только слово header: Посмотрим на статус изменений, описание будет несколько другим. Будет не modified состояние, а Unmerged. Так что смело можно было добавить пятое состояние… Но я думаю, что это излишне, посмотрим:

git status

Убедились, что это другой случай, необычный. Продолжаем:

git add *.txt

В описании можно заметить, что предлагают написать только git commit. Слушаем и пишем:

git commit

И все: таким образом мы сделали это — разрезолвили конфликт в консоли. Конечно, в средах разработки можно это сделать немного проще, например, в Intellij IDEA все настроено так хорошо, что можно выполнять все необходимые действия в ней. Но среда разработки делает много чего “под капотом”, и мы зачастую не понимаем, что именно там произошло. А когда нет понимания, тогда могут возникнуть и проблемы.

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

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

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD пайплайн и другими функциями.
После новости о том, что Microsoft купила GitHub, некоторые разработчики продублировали свои наработки в GitLab.

BitBucket — веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git. Одно время имел большое преимущество перед GitHub в том, что у него были бесплатные приватные репозитории. В прошлом году GitHub также открыл эту возможность для всех бесплатно.

И так далее…

Теперь локально есть полная копия проекта. Чтобы быть уверенным, что локально находится последняя копия проекта, нужно, как говорится, спулить данные, написав:

git pull

В нашем случае сейчас ничего не изменилось удаленно, поэтому и ответ: Already up to date. Но если я внесу какие-то изменения в удаленном репозитории, локальный обновится после того, как мы их спулим. И, наконец, последняя команда — запушить данные на удаленный репозиторий. Когда мы локально что-то сделали и хотим это передать на удаленный репозиторий, нужно сперва создать новый коммит локально. Для этого добавим в наш текстовый файл еще что-нибудь: Теперь уже обыденная для нас вещь — создаем коммит под это дело:

git add test_resource.txt git commit -m “prepated txt for pushing”

И теперь команда, чтобы отправить это на удаленный репозиторий:

git push

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

Полезные ссылки

Официальная дока на гит, есть на русском. Рекомендую как справочное пособие.

Git

Похожие публикации:

Fonts googleapis com что это такое

Кто может работать с системами программирования

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

Что сделать после установки fedora