Основы работы с Git. Отличный, лаконичный и информативный… | by Jenny V | NOP::Nuances of Programming

В процессе разработки ПО значимая роль отводится сотрудничеству. В большинстве случаев деятельность разработчика включает работу в команде и совместное использование проекта с другими специалистами. Практический опыт использования системы контроля версий не просто важен, а ВАЖЕН для всех, кто намерен заниматься разработкой ПО. В то же время будет сложно привить навык использования контроля версий тем начинающим программистам, которые во время рабочего процесса позволяют коду изливаться из них бурным потоком, вместо того чтобы придержать обороты и размещать его по частям.

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

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

Приступим!

Этап 1. Проверка ветки

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

git branch

Если увидели этот результат, то притормозите!

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

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

Итак, что же следует делать, если вы находитесь на ветке master?

Этап 2. Переключение на новую ветку

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

git checkout -b <your-new-branch-name>

Имя ветки <your-new-branch-name> должно отражать проблему, ради решения которой она и создается. Если вы намерены создать базу данных, то в качестве имени ветки следует указать create-database.

Этап 3. Написание кода

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

Будет целесообразно сосредоточиться только на решении задачи, указанной в имени текущей ветки. Основываясь на нашем примере, код в create-database должен способствовать созданию базы данных. Как только вы его написали и он заработал согласно вашему замыслу, самое время им поделиться!

Этап 4. Просмотр статуса

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

Если все в полном порядке, то для индексации этих изменений просто введите в терминал следующую команду:

git add .

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

Этап 5. Создание коммита

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

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

git commit -m “useful info about the code I wrote”.

Флаг -m указывает команде git commit, что вы добавляете полезный комментарий о коде. Итак, его уже можно отправлять, но прежде немного задержимся еще на одном этапе.

Этап 6. Проверка ветки

Догадываюсь, что вас не обрадует предложение по нескольку раз вводить в терминал команду git branch. Но так надо. Проверим дважды — от нас не убудет. Зато вы избавите себя от необходимости запоминать имена веток, поскольку за вас это сделает инструмент!

Этап 7. Отправка

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

git push origin <your-branch-name>

Вы увидите нечто подобное:

Если вы используете VScode, то эта команда + клик на http-адрес перенесут вас на этап 8. И вот ваша ветка запущена в эфир!

Этап 8. Запросы на слияние

На этом этапе мы готовы, можно сказать сгораем от нетерпения, написать дополнительный код. Но прежде посмотрим, что же мы отправили. Перейдите на онлайн-репозиторий Github и сделайте запрос на слияние ветки:

Кликните на Pull request для активации процесса

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

Если все идет по плану, то произойдет успешное слияние веток и другие разработчики получат доступ к написанному вами коду.

Этап 9. Лицом к лицу с master

На данный момент ветка master в онлайн-репозитории содержит больше кода, чем в локальном. Надо бы это исправить. Вернитесь на ветку master и введите в терминал следующую команду:

git pull origin master

Если все сработало, то вы увидите эти зеленые строки плюсов:

Этап 10. Итоги

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

Читайте также:

  • Создание и отслеживание первого рабочего потока Github Actions
  • Автоматизированное семантическое управление версиями с помощью GitVersion
  • Используй git-команды, как senior developer

Читайте нас в Telegram, VK и Яндекс. Дзен

Перевод статьи Alex Mata: Introduction to Git Workflow

Git bash: определение, команды и начало работы

По сути Git — это набор служебных программ командной строки, предназначенных для выполнения в Unix-подобных средах. Современные операционные системы, такие как Linux и macOS, имеют встроенные терминалы командной строки. Благодаря этому они особенно удобны для работы с Git. В Microsoft Windows используется командная строка Windows, отличная от терминала Unix-систем.

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

Интерфейс терминала Git предлагается в приложении Git Bash.

Что такое Git Bash?

Git Bash — это приложение для сред Microsoft Windows, эмулирующее работу командной строки Git. Bash — аббревиатура от Bourne Again Shell. Оболочка (Shell) представляет собой приложение терминала для взаимодействия с операционной системой с помощью письменных команд. Bash — популярная оболочка, используемая по умолчанию в Linux и macOS. Git Bash представляет собой пакет, который устанавливает в операционную систему Windows оболочку Bash, некоторые распространенные утилиты Bash и систему Git.

Установка Git Bash

Git Bash поставляется в составе пакета Git For Windows. Скачайте и установите Git For Windows, как любое другое приложение для Windows. После загрузки найдите входящий в состав пакета файл

.exe и откройте его, чтобы запустить Git Bash.

Использование Git Bash

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

Навигация по папкам

Bash-команда

pwd используется для вывода пути к текущему рабочему каталогу. Команда pwd эквивалентна выполнению команды cd в терминале DOS (или в консоли Windows). Это папка или путь для текущего сеанса Bash.

Bash-команда ls используется для вывода списка содержимого текущего рабочего каталога. Команда ls эквивалентна команде DIR в консоли Windows.

И оболочка Bash, и консоль Windows поддерживают команду cd. Команда cd представляет собой акроним от «Change Directory» (сменить каталог). Команда cd вызывается с добавлением в качестве аргумента имени каталога. При выполнении команды cd происходит смена текущего рабочего каталога сеанса терминала на каталог, переданный в виде аргумента.

Команды Git Bash

Git Bash поставляется с дополнительными командами, которые можно найти в эмулируемом каталоге /usr/bin. В целом Git Bash предоставляет достаточно функциональную оболочку для Windows. В пакет также входят следующие команды оболочки, рассмотрение которых не входит в задачи текущего документа: ssh, scp, cat, find.

Помимо уже рассмотренного набора команд Bash, пакет Git Bash содержит полный набор основных команд Git, которые рассматриваются на этом сайте. Подробнее см. на соответствующих страницах документации по

git clone, git commit, git checkout, git push и другим командам.

Учебник

GIT для начинающих || Simplilearn

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

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

Что такое Git?

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

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

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

Что такое GitHub?

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

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

Далее в этом руководстве по работе с Git рассмотрим несколько команд, используемых в Git.

Различные команды в Git

До сих пор в руководстве по работе с Git вы читали все о Git и GitHub. Далее в руководстве по работе с Git идут команды Git.

  • Git-конфигурация
  • Инициализация Git
  • Гит добавить
  • Гит разница
  • Git фиксирует
  • Git сброс
  • Git-статус
  • Git слияние
  • Git нажать
  • Git вытащить

Далее в этом руководстве по работе с Git мы подробно рассмотрим команду Git push.

Команда Git Push

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

Теперь, когда мы узнали о команде Git push в этом руководстве по Git Bash, давайте взглянем на демонстрацию команды Git push.

Демонстрация команды Git Push

Далее в руководстве по работе с Git давайте начнем с открытия Git Bash и настройки его с помощью имени пользователя и идентификатора электронной почты. Для настройки используем следующие команды:

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

Git config —global user.name «Simplilearn GitHub»

Git config —global user.email [email protected]

Конфигурация Git — список

Затем проверим текущий рабочий каталог:

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

мкдир Git_Demo

компакт-диск Git_Demo

пароль

Мы можем перейти в каталог и проверить папку Git_demo.

Каталог «Git_demo» пока будет пуст.

Создадим папку для репозитория.

мкдир FirstRepo

компакт-диск FirstRepo

пароль


Папка «FirstRepo» пуста. Теперь мы инициализируем репозиторий в нашей папке.

Инициализация Git

На экране появляется нечто, называемое «мастером». Всякий раз, когда репозиторий Git создается в первый раз, он создает ветку с именем master. Перейдите в папку; вы можете найти скрытую папку «.git».

Если вы проверите папку, вы увидите несколько каталогов и конфигураций. Убедитесь, что вы не вносите никаких изменений ни в один из каталогов.

Создается при инициализации репозитория.

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

Для первого блокнота команды следующие:

сенсорный альфа.txt

блокнот alpha.txt

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

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

статус git

Это показывает, что файл еще не зафиксирован, и есть неотслеживаемые файлы. Неотслеживаемые файлы отмечены красным цветом.

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

git добавить .

Следующий шаг — зафиксировать файл.

git commit -m «альфа»

Давайте еще раз проверим состояние файла.

статус git

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

Затем проверьте всю информацию о сделанных фиксациях.

журнал git

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

Давайте сделаем еще один коммит.

Повторите тот же процесс еще раз. Я сделаю блокнот, добавлю в него что-нибудь и закрою.

сенсорный бета.txt

блокнот бета.txt

git добавить .

git commit -m «бета»

журнал git

Мы видим номер коммита и порядок коммитов.

Теперь давайте отправим два блокнота на GitHub. Откройте свою учетную запись GitHub и создайте новый репозиторий. Имя репозитория будет «FirstRepo».

Скопируйте URL-адрес «git remote add origin».

Вставьте скопированный URL-адрес в Git Bash.

git удаленный -v

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

git push -u мастер происхождения

Репозиторий создается на сервере, и содержимое помещается в этот репозиторий. Он связывает ветку master в локальном репозитории с веткой master на сервере.

Затем обновите страницу GitHub, и вы сможете найти там все коммиты.

Каждая фиксация имеет хэш-идентификатор, который содержит сведения о каждой фиксации.

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

Сократите разрыв между разработчиками программного обеспечения и операторами и развивайте свою карьеру в DevOps, выбрав нашу уникальную программу последипломного образования в DevOps. Зарегистрируйтесь на PGP в сотрудничестве с Caltech CTME сегодня!

Заключение  

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

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

Git Tutorial for Beginners — Crash Course

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

Important

Ищете самые важные команды Git? Нажмите здесь, чтобы перейти к концу статьи!

#

Git против Github

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

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

#

Репозитории, ветки и коммиты

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

Однако код не хранится напрямую в репозитории. Внутри нашего репозитория у нас есть «подпапки», так называемые веток . После того, как мы добавили первый код в наш репозиторий, по умолчанию создается «главная» ветка. Однако мы не ограничены одной веткой, репозиторий обычно содержит несколько веток. Итак, это репозитории и ветки, но где хранится наш код?

В наших отделениях! Ветвь содержит разные версии нашего кода, наши коммитов . Каждый коммит — это моментальный снимок конкретной версии кода.

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

#

Как установить и использовать Git

Git можно скачать бесплатно здесь.

Git работает только в терминале (MacOS) или в командной строке (Windows), поэтому он не поставляется с графическим интерфейсом пользователя (GUI). Обязательно ознакомьтесь с выделенными ресурсами на случай, если эти термины будут для вас совершенно новыми.

Если вы работаете с интегрированной средой разработки, вы также можете использовать встроенный терминал. В этом видео/статье я буду использовать Visual Studio Code.

Важно

Вы предпочитаете видео? Не пропустите видео Full Git Crash Course в верхней части этой страницы!

#

Основные команды

Давайте создадим новый проект, папку, содержащую, например, файл index. html, и добавим в него базовый код:

 

Hello

Некоторый текст

Важно

Вы новичок в веб-разработке? Обязательно посмотрите наше видео «Как работает Интернет», чтобы легко начать работу!

#

git init

Давайте напишем нашу первую команду Git. git init превратит наш проект в проект, управляемый Git. Вы должны увидеть информацию Initialized empty Git Repository в своем терминале, подтверждающую, что Git теперь отслеживает проект. Но почему наш проект пустой?

#

git status

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

#

git add

Отслеживание файлов работает либо с git add filename («имя файла» должно быть именем файла, который вы хотите отслеживать), либо с git добавить . , который будет отслеживать изменения во всех файлах внутри репозитория. С git status мы видим, что мы добавили новый файл (в нашем случае index.html) в репозиторий, хотя до этого момента мы не сохраняли никаких изменений в коде.

#

git commit

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

#

Более глубокое погружение в ветки и коммиты

Время для краткого обзора, прежде чем мы углубимся:

  1. Мы превратили папку нашего проекта в репозиторий Git с помощью git init

  2. Мы сказали Git отслеживать любые изменения в файле ìndex.html с git add .

  3. Мы сохранили текущую версию нашего кода в коммите с помощью git commit -m "добавлен начальный код"

Это было просто, не так ли? Но как насчет Бранчей? Я уже говорил вам, что мы автоматически создали нашу основную ветку с нашим первым коммитом, но где мы можем увидеть эту ветку?

#

ветка git

ветка git перечисляет все ветки в нашем репозитории. Хотя мы не добавляли никакого имени, мастер-ветка была автоматически создана с нашей первой фиксацией:

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

Давайте добавим код в наш файл index.html:

 

Привет

Некоторый текст

Другой текст

С git добавить . и git commit -m "div добавлен" мы можем добавить этот новый код в качестве второго коммита в нашу ветку.

##git log

Ввод git log в нашем терминале отобразит все коммиты внутри нашей ветки:

Каждый коммит содержит уникальный идентификатор, автора, дату и сообщение коммита (это -м "ваше сообщение" часть). «HEAD» просто указывает на последний коммит нашей текущей ветки, подробнее об этом в следующей главе.

Прокрутив немного вниз, вы также увидите наш первоначальный коммит с именем «starting code».

Но как Git создает эти коммиты? Каждый коммит не является обновленной копией предыдущего коммита. После первого коммита Git просто отслеживает изменения для каждого следующего коммита. Итак, с git add . , Git проверяет наши файлы на наличие изменений, git commit затем сохраняет эти изменения в новом коммите.

Такое отслеживание изменений делает Git быстрым и эффективным, поскольку многократное создание копий просто раздует нашу папку Git, чего мы определенно хотим избежать в любом проекте!

#ГОЛОВА

Пришло время поближе познакомиться с ГОЛОВОЙ.

 

Привет

Некоторый текст

Другой текст

Проверка головы

Я добавил еще один «div» и создал новый коммит ( git add . и git Commit -m "head testing" ), как объяснялось ранее, этот коммит стал HEAD, так как это последний коммит в нашем Ветвь:

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

##git checkout

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

Здесь мы можем использовать идентификатор, который мы ранее рассматривали с git log :

Давайте проверим второй коммит с именем «div добавлен» с git checkout yourcommitsID (просто скопируйте и вставьте идентификатор коммита в часть «yourcommitsID»).

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

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

Сначала мы должны вернуться в нашу главную ветку с git checkout master (или просто git master ), теперь мы вернулись в последний коммит ветки (наш HEAD).

Удалить наш последний коммит теперь легко. Скопируйте идентификатор фиксации, к которой вы хотите вернуться (НЕ идентификатор фиксации, которую вы хотите удалить), и используйте git reset --hard ID (идентификатор должен быть идентификатором фиксации). Вот и все, теперь мы сбрасываем HEAD и удаляем все последующие коммиты.

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

#

Откат неустановленных изменений

Снова добавим код:

 

Привет

Некоторый текст

Еще один текст

Что-то, что мне не нужно

Оказывается, этот код нам на самом деле не нужен, и мы хотели бы его удалить, хотя изменения не были зафиксированы. Помимо ручного удаления нашего кода (что не будет работать так просто, если вы изменили много кода в разных местах), git checkout -- . давайте вернемся к нашему последнему коммиту (который, конечно, не включает эти незафиксированные изменения).

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

#

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

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

  • главная ветка, которая содержит текущую стабильную и работающую версию вашего веб-сайта

  • ветка функций, в которой вы сейчас работаете над новой функцией.

Конечной целью будет объединение обеих ветвей, как только новая функция будет завершена и готова к запуску.

#

git checkout -b

git checkout -b создает новую ветку на основе последней фиксации ветки, в которой вы сейчас работаете. Поскольку мы находимся в последней фиксации в главной ветке, которая содержит «index. html», новая созданная ветка также будет включать этот код и все коммиты внутри этой ветки, поэтому мы в основном копируем всю ветку.

git checkout -b new-feature создаст новую ветку с именем «new-feature»:

После создания ветки мы автоматически работаем в последнем коммите этой ветки (вы всегда можете проверить это с помощью git ветки и git log ), и мы можем добавить к ней код, всего стиля. css для простоты.

git добавить . и git commit -m "css добавлено" создаст новый коммит с этими изменениями в нашей ветке «new-feature».

Это также приводит к двум разным HEADS. В ветке «new-feature» только что созданный нами коммит является HEAD, в ветке master у нас другой HEAD, наш коммит «div add» — второй на скриншоте:

#

Слияние веток

Вернувшись в нашу основную ветку с git master , теперь мы можем объединить или объединить две наши ветки с git merge new-feature .

Это добавит изменения, сделанные в ветке «new-feature», в нашу главную ветку, и, следовательно, наш последний коммит «css added» теперь является HEAD обеих веток.

#

Удаление веток Git

Поскольку наша новая функция реализована в главной ветке, мы можем избавиться от ветки «новая функция» с помощью ветвь git -D новая функция .

#

Разрешение конфликтов слияния

Слияние ветвей — отличная функция, но иногда она также может вызывать конфликты.

В настоящее время у нас есть этот код в последнем коммите в нашей основной ветке:

 

Привет

Некоторый текст

Другой текст

Давайте создадим новую ветку с git checkout -b new-feature и изменим код следующим образом:

 

До свидания

Некоторый текст

Еще один текст

После добавления и фиксации изменений давайте переключимся обратно на мастер и измените код следующим образом:

 

BYE

Некоторый текст

Другой текст

Если мы также добавим и зафиксируем это изменение , мы работали над одним и тем же кодом в двух разных ветках (первые

), так что же произойдет, если мы сейчас попытаемся объединить ветки?

git merge new-feature выдаст нам ошибку: «Автоматическое слияние не удалось; исправьте конфликты, а затем зафиксируйте результат».

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

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

#

Полезные команды Git

Срочно нужно найти команду Git? Вот ваш маленький помощник:

  • git init : Инициализировать репозиторий Git в текущей папке

  • git status : Показать текущий статус вашего репозитория Git (статус «рабочее дерево»)

    3 90

  • git добавить . : отслеживать изменения всех файлов в вашем репозитории

  • git commit -m "ваше сообщение" : Сохранить обновленный код в новом коммите с именем «ваше сообщение»

  • git log : Список всех коммитов внутри вашей ветки

  • git checkout commitid Перейти к определенной фиксации ветки (commitid должен быть идентификатором фиксации, которую вы хотите проверить)

  • git checkout -- .