Как закоммитить файл в github

Содержание
  1. Гайд по Git : Часть 1 : Как сделать коммит в Git
  2. Что такое VCS?
  3. Установка git
  4. Настройка
  5. Инициализация репозитория
  6. Коммиты
  7. Просмотр истории коммитов
  8. Навигация
  9. Detaching HEAD
  10. Относительные ссылки
  11. Заключение
  12. Как закоммитить файл в github
  13. Запись изменений в репозиторий
  14. Определение состояния файлов
  15. Отслеживание новых файлов
  16. Индексация изменённых файлов
  17. Сокращенный вывод статуса
  18. Игнорирование файлов
  19. Просмотр индексированных и неиндексированных изменений
  20. Коммит изменений
  21. Игнорирование индексации
  22. Удаление файлов
  23. Перемещение файлов
  24. Первый коммит в Github
  25. Руководство по созданию первого коммита в свой репозиторий на Github
  26. Основы
  27. Установка Git
  28. Для Linux:
  29. Для macOS:
  30. Для Windows, (для macOS и Linux — альтернатива):
  31. Создание и настройка локального репозитория
  32. Добавление файлов в локальный репозиторий
  33. Создание версии проекта
  34. Создание репозитория на Github
  35. GitHub: работа с ветками и коммитами
  36. Команды для консоли

Гайд по Git : Часть 1 : Как сделать коммит в Git

Отвечаю на вопросы: как сделать коммит, создать новую ветку, вмержить одну ветку в другую.

Я пользовался git еще в универе, было удобно писать диплом и не плодить 100 копий файлов с названиями: “диплом (новый)”, “диплом (новее нового)”, “диплом (новые правки)”.

Мои статьи основаны на отличном интерактивном курсе LearnGitBranching. Но у него есть существенный недостаток, они не используют настоящий Git в процессе обучения. Из-за этого ряд важных нюансов упускается.

В моей статье будет обучение на настоящем Git. Просто повторяйте команды за мной, чтобы попрактиковаться.

Что такое VCS?

Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют откатить проект до старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Репозиторием называют хранилище вашего кода. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске. Также есть хостинги репозиториев, такие как GitHub и GitLab, которые позволяют хранить проект в интернете.

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

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

Установка git

Основой интерфейс для работы с Git-ом является консоль. Это не удобно использовать в работе, но некоторые проблемы решаются только через консоль.

Windows. Проходим по этой ссылке, скачиваем и устанавливаем.

Для Mac OS. Открываем терминал и пишем:

Linux. Открываем терминал и вводим следующую команду.

Настройка

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

Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.

featured image 4

Инициализация репозитория

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

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

Посмотрим, какие файлы находятся сейчас в папке git-project :

Коммиты

Коммит в git репозитории хранит снимок всех файлов в репозитории. Почти как огромная копия, только эффективнее.

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

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

Файлы в репозитории могут находиться в 3 различных “областях”.

Наш проект сейчас пуст. Давайте создадим первый файл:

26

На данном этапе только область “Рабочий каталог” содержит данные.

Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед коммитом. На данном этапе вы можете в любой момент очистить все изменения и вернуться к последнему коммиту.

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

Для добавления в Индекс используется следующая команда:

27

28

Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.

29

Теперь посмотрим, какие изменения произошли в git:

Еще раз проверяем статус репозитория:

Новый файл появился в списке не отслеживаемых, то есть в Рабочем Каталоге. Давайте добавим в отслеживание этот файл, а так же измененный ранее.

26

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

27

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

git commitБлок помощи

Просмотр истории коммитов

Помимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.

Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям.

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

Detaching HEAD

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

Указатели могут ссылаться на другие указатели, обычно HEAD указывает на имя ветки. Но это можно изменить, например указать hash нужного коммита, чтобы откатиться к нему.

Создадим еще один файл и сделаем третий коммит:

Представим, что нам надо посмотреть, как выглядел наш репозиторий после второго коммита. Для этого используем команду checkout и хэш второго коммита. Кстати, можно не указывать его целиком, достаточно первых 5 символов.

28

Вызвав git log видим, что HEAD теперь указывает на второй коммит:

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

Вернем указатель HEAD на main :

Относительные ссылки

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

Давайте переключимся на коммит выше main :

Да, мы снова попали на второй коммит, то есть HEAD сейчас вновь указывает на второй коммит.

Вернемся на третий коммит:

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

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

Мы переместились на первый коммит. Вернемся:

Заключение

Это была первая статья по обучению git. Мы установили git и научились работать с некоторыми командами для создания коммитов и навигации по ним.

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

Если все получилось, переходите к следующему уроку 👇

Источник

Как закоммитить файл в github

Шпаргалка по консольным командам Git

Создать новый репозиторий

Добавление файлов к отслеживанию, индексация отслеживаемых

Убирание файла, папки из отслеживания

Временно переключиться на другой коммит

Переключиться на другой коммит и продолжить работу с него

Потребуется создание новой ветки, начинающейся с указанного коммита.

Удаление файла (просто удалить отслеживаемый файл из папки недостаточно, нужно сделать его неотслеживаемым и отправить коммит)

Перемещение/переименование файлов (Git не отслеживает перемещения/переименование, но пытается его угадать)

Собираем коллекцию простых и сложных примеров работы

Создание нового репозитория, первый коммит, привязка удалённого репозитория с gthub.com, отправка изменений в удалённый репозиторий.

Обычный рабочий процесс

Создание нового репозитория на github.com, клонирование к себе, работа, периодическая «синхронизация с github.com».

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

Внесение изменений в коммит

Есть master (публичная версия сайта), хотим масштабно что-то поменять (переверстать «шапку»), но по ходу работ возникает необходимость подправить критичный баг (неправильно указан контакт в «подвале»).

Работа с ветками, конфликт слияния

Есть master (публичная версия сайта), в двух параллельных ветках (branch_1 и branch_2) было отредактировано одно и то же место одного и того же файла, первую ветку (branch_1) влили в master, попытка влить вторую вызывает конфликт.

Синхронизация репозитория-форка с мастер-репозиторием

Есть некий репозиторий на github.com, он него нами был сделан форк, добавлены какие-то изменения. Оригинальный (мастер-) репозиторий был как-то обновлён. Задача: стянуть с мастер-репозитория изменения (которые там внесены уже после того, как мы его форкнули).

Ошибка в работе: закоммитили в мастер, но поняли, что нужно было коммитить в новую ветку (ВАЖНО: это сработает только если коммит еще не отправлен в удалённый репозиторий)

Нужно вернуть содержимое файла к состоянию, бывшему в каком-либо коммите (известна SHA коммита)

При любом действии с github (или другим удалённым сервисом) запрашивается логин/пароль

Речь именно о запросе пароля, а не ключевой фразы.

Источник

Запись изменений в репозиторий

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

Читайте также  Икеа хот дог как приготовить

Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.

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

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

lifecycle

Определение состояния файлов

Отслеживание новых файлов

Индексация изменённых файлов

Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :

Сокращенный вывод статуса

Игнорирование файлов

Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (

Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.

Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.

Чтобы исключить каталог добавьте слеш (/) в конец шаблона.

Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.

Просмотр индексированных и неиндексированных изменений

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

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

Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.

Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:

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

Коммит изменений

Эта команда откроет выбранный вами текстовый редактор.

В редакторе будет отображён следующий текст (это пример окна Vim):

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

Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.

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

Игнорирование индексации

Удаление файлов

Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :

В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:

Эта команда удаляет все файлы, имена которых заканчиваются на

Перемещение файлов

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

Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:

и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:

Однако, это эквивалентно выполнению следующих команд:

Источник

Первый коммит в Github

Руководство по созданию первого коммита в свой репозиторий на Github

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

Основы

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

Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.

GitHub — это сервис для проектов, использующих Git.

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

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

Репозиторий бывает:

Для первого коммита на Github необходимо установить Git, создать локальный репозиторий, добавить в него файлы, сделать коммит, подключиться к удалённому репозиторию и отправить в него изменения.

Установка Git

Для Linux:

1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git

Для macOS:

1. Воспользуемся homebrew
2. Вводим в терминале: brew install git

Для Windows, (для macOS и Linux — альтернатива):

1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.

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

Создание и настройка локального репозитория

Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.

2. Настроим имя пользователя и адрес электронной почты:

(где Name – логин пользователя, email@mail.ru — почта)

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

tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.

find – удаление файлов со специфичным суффиксом.

3. Переходим в папку с проектом Users/Public/Project:

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

Командная строка должна вернуть что-то вроде:

Добавление файлов в локальный репозиторий

1. Теперь создадим любой файл в нашей директории, например, first.txt

2. Добавим его в систему управления версиями:

3. Если нужно добавить все файлы в директории, то используем:

4. Проверить текущее состояние:

Можно отменить добавление файла командой:

Создание версии проекта

После добавления нужного файла в staging area (область подготовленных файлов) можно создать версию проекта.

Ключ –m означает создание пользователем описания этого коммита.

Для удаления всеx файлов в папке, не относящихся к проекту, и не сохраненных в репозитории, можно воспользоваться командой:

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

Все действия до этого раздела производились над локальным репозиторием, который находится у вас на компьютере. Если мы хотим сохранить проект в Интернете, и предоставить к нему доступ, то создадим репозиторий на Github.

1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).

2. Нажимаем кнопочку «+» и вводим название репозитория.

3. Выбираем тип Public (Private доступен только в платной версии).

4. Нажимаем Create.
В результате создан репозиторий в Github (на экране видим инструкцию, по соедининению локального репозитория со вновь созданным).

5. Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (желательно использовать его, но можно любое другое, главное – не master – оно используется в момент релиза версии).

Результат можно увидеть с помощью команды:

Если все правильно сделано, то увидим:

Для отмены регистрации удаленного репозитария, введите:

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

-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push

Читайте также  Как выводить клопов в домашних условиях

Источник

GitHub: работа с ветками и коммитами

thumb 6315c696dc3cda1be3c99cd49867750d

thumb 6315c696dc3cda1be3c99cd49867750d

retina e9dfa233807722acdc95356d565e1f1d

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

Ветка (branch) — это история коммитов. Давайте сначала разберемся, что это такое.

Коммит (commit) — это информация об измененных файлах. Коммит состоит из автора коммита, измененных файлов, HEAD и времени. Для примеров мы будем использовать репозиторий и сделаем первый коммит, который отправим на сервер. Он нужен для того, чтобы разграничивать задачки. Так будет понятно, какой код в истории относится к той или иной задаче, чтобы потом мы могли быстро понять суть.

Например, у нас задача — сделать блок формы. Для этого мы сделаем нужные изменения в файле index.html & style.css, и даже через месяц сможем при помощи истории изменений просмотреть измененные куски кода именно для этого блока.

При помощи команды git log в консоли мы можем отслеживать историю коммитов в ветке.

retina 03ccc426a119f4c6854a91baeda55eca

На самом GitHub мы можем увидеть последний коммит в файле и последний коммит в ветке. Всю историю мы можем просмотреть, кликнув по кнопке n commits, где n — количество запущенных на сервер коммитов. У нас в ветке пока что один коммит, поэтому на ссылке надпись 1 commit.

retina 4e4f0edc120c093f95af3f4edbad51ae

Сама история будет выглядеть как список коммитов без подробностей об изменённых файлах. Здесь давайте подробнее остановимся на том, что такое HEAD коммита. Это специальный указатель, при помощи которого вы можете гибко управлять коммитами — например, склеивать или сбрасывать до нужного момента.

retina 40a0f6857b93b93f84ceae8c44b50e8a

Если вы кликните по сообщению в коммите, в нашем случае это add first commit, то попадёте в список всех изменённых файлов.

retina 7c069ce55cb0ea04a0a7649a2a911f14

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

В нашем примере мы изменим содержание страницы index.html и добавим стили в style.css.

retina f305f6a23f133b891977eda81512088a

Изменения, не включенные в коммит, мы можем просмотреть при помощи команды git status.

retina dd2eb3ab858ac716a59fce32bc6eaba1

Чтобы добавить файлы в коммит, мы будем использовать git add. Здесь мы можем указать нужные нам файлы для коммита, например, index.html. Если после этого мы сделаем git status, то эти файлики подсветятся зелёным — это означает, что мы можем добавить их к коммиту.

retina f937b7172fd3f0b494d4decded1744bc

retina 741d87c605173cf7ead75284e62ebe9f

retina 85398cf40fba48b4de6fdaedbf2b31f0

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

retina 226a31b3111c37c0418edb181ccc05f8

retina 9ef16b884bc9a2117d3452da0b05d7b8

retina 0aafe6af2de3ad000ee6725abe49ea32

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

retina 6b57d32ce9799cbc7c7228a4f7b086b0

Теперь поговорим про ветки (branch). Ветка — это история изменений. Сейчас у в репозитории одна ветка main, в которой хранится стабильная версия. Как правило, новые задачи делаются в новых ветках, а потом вливаются в main после ревью кода.

Посмотрим, как выглядит наша ветка с двумя коммитами в графике.

retina 08fccc900e548e51700347f408d8f06b

Ветки можно просматривать при помощи команды git branch.

retina e921a5cfd7108b541ee9f6d962bb0df4

Пробежимся git log и сравним наши ветки.

retina 26cc45366007f641fe706f69b317bb8d

Тем не менее, если мы зайдем на GitHub, то обнаружим, что у нас там только одна ветка — main. Так происходит, потому что ветка form-index существует пока только на нашем компьютере, то есть локально.

retina ab94ed3cfd5a4e1f7c65b9e4df6b0847

Чтобы наша новая ветка появилась на сервере, нам нужно запушить наши изменения.

retina 7ab0c98104a388f2db84deb7e000d020

retina 60f09c62647bc20638e9857ff45b0894

Если посмотрим на историю коммитов в form, то увидим, что она отличается от main на один коммит.

retina 39fafa4776b59dc89499eefe69c38b9a

Мы можем создавать новые ветки не только из main, но и из других веток — так делают редко. Самое главное здесь понять, что если мы создали новую ветку из другой ветки, то мы наследуем историю коммитов ветки, из которой создали ветвление, но только в момент создания.

Давайте создадим ветку form-index-fix и посмотрим на историю коммитов в ней.

retina 628091c743edadf6c783535b74fcbef6

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

retina d6c39715ef44d50048c9253b283592a9

retina f6bcc3a0384320694e9b26b0fb542e84

Если ветку нужно удалить на сервере, то сделать это можно при помощи интерфейса GitHub — нет рекомендаций, когда нужно удалять удалённые ветки.

retina 534d743fa737147d456817f09481e012

retina 42060b117ff71427615cdc2be0b2e064

Команды для консоли

retina e9dfa233807722acdc95356d565e1f1d

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

Ветка (branch) — это история коммитов. Давайте сначала разберемся, что это такое.

Коммит (commit) — это информация об измененных файлах. Коммит состоит из автора коммита, измененных файлов, HEAD и времени. Для примеров мы будем использовать репозиторий и сделаем первый коммит, который отправим на сервер. Он нужен для того, чтобы разграничивать задачки. Так будет понятно, какой код в истории относится к той или иной задаче, чтобы потом мы могли быстро понять суть.

Например, у нас задача — сделать блок формы. Для этого мы сделаем нужные изменения в файле index.html & style.css, и даже через месяц сможем при помощи истории изменений просмотреть измененные куски кода именно для этого блока.

При помощи команды git log в консоли мы можем отслеживать историю коммитов в ветке.

retina 03ccc426a119f4c6854a91baeda55eca

На самом GitHub мы можем увидеть последний коммит в файле и последний коммит в ветке. Всю историю мы можем просмотреть, кликнув по кнопке n commits, где n — количество запущенных на сервер коммитов. У нас в ветке пока что один коммит, поэтому на ссылке надпись 1 commit.

retina 4e4f0edc120c093f95af3f4edbad51ae

Сама история будет выглядеть как список коммитов без подробностей об изменённых файлах. Здесь давайте подробнее остановимся на том, что такое HEAD коммита. Это специальный указатель, при помощи которого вы можете гибко управлять коммитами — например, склеивать или сбрасывать до нужного момента.

retina 40a0f6857b93b93f84ceae8c44b50e8a

Если вы кликните по сообщению в коммите, в нашем случае это add first commit, то попадёте в список всех изменённых файлов.

retina 7c069ce55cb0ea04a0a7649a2a911f14

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

В нашем примере мы изменим содержание страницы index.html и добавим стили в style.css.

retina f305f6a23f133b891977eda81512088a

Изменения, не включенные в коммит, мы можем просмотреть при помощи команды git status.

retina dd2eb3ab858ac716a59fce32bc6eaba1

Чтобы добавить файлы в коммит, мы будем использовать git add. Здесь мы можем указать нужные нам файлы для коммита, например, index.html. Если после этого мы сделаем git status, то эти файлики подсветятся зелёным — это означает, что мы можем добавить их к коммиту.

retina f937b7172fd3f0b494d4decded1744bc

retina 741d87c605173cf7ead75284e62ebe9f

retina 85398cf40fba48b4de6fdaedbf2b31f0

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

retina 226a31b3111c37c0418edb181ccc05f8

retina 9ef16b884bc9a2117d3452da0b05d7b8

retina 0aafe6af2de3ad000ee6725abe49ea32

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

retina 6b57d32ce9799cbc7c7228a4f7b086b0

Теперь поговорим про ветки (branch). Ветка — это история изменений. Сейчас у в репозитории одна ветка main, в которой хранится стабильная версия. Как правило, новые задачи делаются в новых ветках, а потом вливаются в main после ревью кода.

Посмотрим, как выглядит наша ветка с двумя коммитами в графике.

retina 08fccc900e548e51700347f408d8f06b

Ветки можно просматривать при помощи команды git branch.

retina e921a5cfd7108b541ee9f6d962bb0df4

Пробежимся git log и сравним наши ветки.

retina 26cc45366007f641fe706f69b317bb8d

Тем не менее, если мы зайдем на GitHub, то обнаружим, что у нас там только одна ветка — main. Так происходит, потому что ветка form-index существует пока только на нашем компьютере, то есть локально.

retina ab94ed3cfd5a4e1f7c65b9e4df6b0847

Чтобы наша новая ветка появилась на сервере, нам нужно запушить наши изменения.

retina 7ab0c98104a388f2db84deb7e000d020

retina 60f09c62647bc20638e9857ff45b0894

Если посмотрим на историю коммитов в form, то увидим, что она отличается от main на один коммит.

retina 39fafa4776b59dc89499eefe69c38b9a

Мы можем создавать новые ветки не только из main, но и из других веток — так делают редко. Самое главное здесь понять, что если мы создали новую ветку из другой ветки, то мы наследуем историю коммитов ветки, из которой создали ветвление, но только в момент создания.

Давайте создадим ветку form-index-fix и посмотрим на историю коммитов в ней.

retina 628091c743edadf6c783535b74fcbef6

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

retina d6c39715ef44d50048c9253b283592a9

retina f6bcc3a0384320694e9b26b0fb542e84

Если ветку нужно удалить на сервере, то сделать это можно при помощи интерфейса GitHub — нет рекомендаций, когда нужно удалять удалённые ветки.

Источник

admin
Своими силами
Adblock
detector