Git - что такое отслеживающая ветка?

5 последних уроков рубрики «Разное»

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

Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.
Создание вебсайта — процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.
Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Установка git

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

Для установки на Windows нажимаем на кнопку ниже, скачиваем и устанавливаем.

Для Mac OS открываем терминал и пишем, если установлен Brew:

Если Brew не установлен, то вводим эту команду.

После этого появится окно, где предложит установить Command Line Tools (CLT). Соглашаемся и ждем установки. Вместе с CLT установиться и git

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

Настройка

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

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

Более интересные перемещения

Также возможно сделать так, чтобы при перебазировании воспроизведение коммитов применялось к совершенно другой ветке. Для примера возьмём историю разработки с тематической веткой, ответвлённой от другой тематической ветки (рисунок 39, ниже). Вы создаёте тематическую ветку , чтобы добавить в проект некоторую функциональность для серверной части, и делаете коммит. Затем вы выполнили ответвление, чтобы сделать изменения для клиентской части, и создали несколько коммитов. Наконец, вы вернулись на ветку и сделали ещё несколько коммитов.

Рисунок 39 – История разработки с тематической веткой, ответвлённой от другой тематической ветки

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

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

Рисунок 40 – Перемещение тематической ветки, ответвлённой от другой тематической ветки

Теперь вы можете выполнить перемотку (fast-forward) для ветки (рисунок 41, ниже):

Рисунок 41 – Перемотка ветки для добавления изменений из ветки

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

Это повторит работу, сделанную в ветке поверх ветки , как показано на рисунке:

Рисунок 42 – Перебазирование ветки на вершину ветки

После чего вы сможете выполнить перемотку основной ветки ():

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

Рисунок 43 – Окончательная история коммитов

Сравнение слияния и перебазирования

Начальное состояние и параллельное сравнение конечных состояний слияния и перебазирования

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

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

Настройка нескольких пультов

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

git remote add

Затем, когда вы хотите передать на второй пульт, добавьте имя и ветку удаленного управления в вашу команду push:

git push second master

Или переключите пульт по умолчанию, используя :

git push --set-upstream second master

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

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

Вы можете создать ветку с :

git checkout -b deployment

Затем добавьте удаленное развертывание:

git remote add deployment

и получите ветку master:

git fetch deployment master

Затем вы можете установить восходящий поток для текущей ветви, выполнив:

git branch --set-upstream-to=deployment/master

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

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

Чем коммит отличается от пуша

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

Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.

Получается, последовательность действий такая:

Вы подключаетесь к репозиторию и клонируете его.
Делаете себе новую ветку.
Перед началом работы делаете пулл, чтобы забрать актуальную версию файлов.
Пилите в своей ветке то, что вам нужно.
Когда работа сделана, вы её коммитите.
Чтобы отправить её другим ребятам, вы её пушите.
Когда работу одобряют и перепроверяют, вашу ветку мержат (сливают, склеивают) с мастер-веткой.
Пользователи счастливы, что вы добавили им новых возможностей.

git rm command tutorial in details || git interview question || github

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

Файл указывает, какие неотслеживаемые файлы Git должен игнорировать.

Какие файлы следует игнорировать?

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

Файлы времени выполнения, такие как журнал, блокировка, кэш или временные файлы. Файлы с конфиденциальной информацией, такой как пароли или ключи API. Скомпилированный код, такой как каталоги .class или .o .Dependency, например каталоги /vendor или /node_modules Каталоги сборки, такие как /public, /out или /dist Системные файлы, такие как .DS_Store или Thumbs.db IDE или файлы конфигурации текстового редактора.

.gitignore

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

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

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

Правила личного игнорирования

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

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

Глобальный

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

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

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

Создайте файл:

Добавьте файл в конфигурацию Git:

Откройте файл в текстовом редакторе и добавьте в него свои правила.

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

Игнорирование ранее зафиксированных файлов

Файлы в вашей рабочей копии могут быть отслежены или не отслежены.

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

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

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

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

Отладка файла

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

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

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

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

Вывод

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

gitignore.io — это онлайн-сервис, который позволяет создавать файлы для вашей операционной системы, языка программирования или IDE.

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

Команда ls — это одна из основных команд, которую должен знать любой пользователь Linux. Он используется для отображения информации о файлах и каталогах в файловой системе.

SSHFS (SSH Filesystem) — это клиент файловой системы на основе FUSE для монтирования удаленных каталогов по SSH-соединению. Из этого туториала вы узнаете, как установить клиент SSHFS в Linux, macOS и Windows и как смонтировать удаленный каталог.

3 ответа 3

В Git есть специальная команда cherry-pick , которая позволяет вставлять в текущую ветку изменения из любого коммита. Работает она так:

Пример выше применяет последний коммит из ветки test в текущую ветку.

При желании, можно перенести более одного коммита за один раз. Например:

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

Используя SHA хэш коммита (или его сокращенный вариант).
Используя имя ветки (можно использовать синтаксис ^ и

Используя тэг, которым помечен коммит.

Более подробная информация о том, как сослаться на коммит есть в документации к Git.

Стоит отметить, что в отличии от слияния ( merge ) при cherry-pick переносятся только изменения, а не сам коммит полностью. При этом, в целевой ветке создается новый коммит (коммиты) содержащий необходимые изменения.

именно. я так в вебшторме делал и результат предсказуемый получился * в ветке dev на делал изменений * понял что это задел под новую фичу сделал новый бранч * в новом бранче сделал коммит * сделал пуш на сервер

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

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

Итак, , как я могу сделать, что незафиксированные изменения (или изменения, хранящиеся в индексе), будут переданы в другую ветку, чем текущая?

Другие ответы, предлагающие проверить другую ветку, а затем выполнить ее, работают только в том случае, если проверка возможна с учетом локальных изменений. Если нет, вы используете наиболее распространенный прецедент для git stash :

Первый stash скрывает ваши изменения (в основном, делает временную фиксацию), а последующий stash pop повторно применяет их. Это позволяет git использовать возможности слияния.

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

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

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

И, конечно же, помните, что все это заняло немного времени, и в следующий раз избегайте его, возможно, поместив ваше текущее имя ветки в приглашение, добавив $(__git_ps1) к вашему PS1 в вашем bashrc. (См. Например Git в Bash.

Переносим удалённый репозиторий на ПК

Перейдите на сайт desktop.github.com и скачайте GitHub Desktop — это приложение, которое позволит синхронизировать удалённый репозиторий на GitHub и файлы на вашем компьютере без командной строки терминала:

Скачиваем приложение под свою операционную систему.
Открываем приложение и проходим авторизацию — нужно указать электронную почту и данные вашего GitHub-аккаунта.
Приложение синхронизируется с удалённым репозиторием и предложит выполнить одно из следующих действий: создать новый репозиторий, добавить локальную папку с компьютера в GitHub Desktop или клонировать существующий репозиторий в папку компьютера.

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

После установки GitHub Desktop запросит синхронизацию с GitHub-аккаунтом. Если аккаунта нет, приложение предложит его создать
Рабочее пространство в GitHub Desktop — мы можем клонировать репозиторий, создать новый или перенести нужные файлы с компьютера
Выбираем репозиторий, сохраняем его на рабочем столе и жмём кнопку Clone

После клонирования репозитория в рабочем пространстве появятся три вкладки: Current Repository, Current Branch и Fetch origin.

Current Repository — раздел позволяет переключаться между несколькими репозиториями, отслеживать невнесённые изменения (вкладка Changes) и смотреть историю коммитов (вкладка History).
Current Branch — раздел позволяет переключаться между несколькими ветками проекта.
Fetch origin — раздел обновляет внесённые изменения и синхронизирует файлы локального и удалённого репозитория.

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

Рабочее пространство для работы с клонированным репозиторием
История изменений нашего репозитория

Цвета в Git

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

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

Значение по умолчанию – , при котором цвета используются при непосредственном выводе в терминал, но исключаются при перенаправлении вывода в именованный канал или файл.

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

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

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

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

Как же работает система контроля версий?

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

В качестве системы контроля версий используем git. Сначала необходимо установить его на сервере. Для этого обязательно нужно иметь SSH-доступ. Кроме того, потребуется удаленный репозиторий. Он точно такой же, как на вашем сайте, но находится в другом месте, это позволяет работать с ним и рабочему, и тестовому сайту на равных.

Существуют веб-сервисы для хостинга IT-проектов, например, github.com и bitbucket.org, оба имеют бесплатные версии, в которых есть ограничения на количество пользователей или приватных репозиториев. Но мы используем бесплатную альтернативу – GitLab.

Что такое Git в Python?

Модули Git языка Python – это распределенная система контроля версий. Система контроля версий – это набор инструментов, используемых для отслеживания прошлого набора файлов проектов.

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

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

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

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

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

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

Опубликованные ветки

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

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

Зачем новичку учить Git

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

Новый человек приходит в компанию и клонирует репозиторий проекта на ПК.
Получает задачу, создаёт новую ветку и пишет код.
Когда всё готово — отправляет запрос на добавление кода в master-ветку.
Другие разработчики смотрят код, оставляют комментарии и указывают на ошибки.
Новичок дорабатывает код, обновляет master-ветку и переходит к следующей задаче.

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

Ограничения wiki на GitHub

Github имеет некоторые ограничения:

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

Note: Здесь речь именно о встроенной функции Wiki на GitHub, а не GitHub Pages. Для стилизования и автоматического создания контента можно использовать такие инструменты, как Jekyll. Более подробно GitHub Pages рассмотрим в руководстве по Jekyll.

Слияние

Начнем с самого распространенного рабочего процесса интеграции изменений: слияния. Перед объединением изменений Ada с Satoshi должен сначала обновить свой локальный указатель на ветку, поскольку в данный момент она устарела. Как только и синхронизируются, Satoshi сможет включить все изменения в свою тематическую ветку.

Процесс слияния:

После всех изменений в Satoshi может продолжить разработку ветки и на заключительном этапе объединить ее с .

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

Git — это не GitHub

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

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

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

Сливаем ветки

В файловом менеджере или в терминале с помощью команды ls посмотрите на файлы, которые у нас есть. Их должно быть два readme.txt и index.html.

Попробуем переключиться на другую ветку. Создайте новую ветку от мастера с именем secondone:

git checkout -b secondone master

Мы создали новую ветку от мастера. Давайте посмотрим на файловую систему

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

Index.html файла там нет, он живет в отдельной ветке initialwork.

Если нам нужны изменения, которые были сделаны в файле initialwork, то мы можем слить их. Для этого можно выполнить команду git merge и указать имя ветки, которую нужно слить:

git merge initialwork

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

Updating 3167f60..2255b8f
Fast-forward
 index.html | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 index.html

Теперь в файловой системе можно увидеть файл index.html.

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

Но изменения все еще не в мастере. Мы можем переключиться на мастер:

git checkout master

и посмотреть на файловую систему. У нас тут все еще только readme.txt.

Обратите внимание, что при переключении на мастер я выполнял команду git checkout без ключа -b, потому что ветка master уже существует и нам не нужно ничего создавать, поэтому просто git checkout – переключиться без создания. Теперь мы можем слить с мастером любую ветку initialwork или secondone

В обоих ветках уже есть файл index.html и в любом случае он появиться в мастере. Так что можно выполнить команду:

Теперь мы можем слить с мастером любую ветку initialwork или secondone. В обоих ветках уже есть файл index.html и в любом случае он появиться в мастере. Так что можно выполнить команду:

git merge initialwork

или

git merge secondone

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

git merge initialwork
Updating 3167f60..2255b8f
Fast-forward
 index.html | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 index.html

git merge secondone
Already up to date.

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

Странная нотация (~ и ^)

При использовании команды «странная нотация» бывает особенно полезной, поскольку позволяет указывать коммиты, близкие к HEAD, без необходимости написания их хэшей:

HEAD~ — это сокращенная запись HEAD~1 и означает первого родителя коммита. HEAD~2 означает первого родителя у первого родителя коммита. HEAD~n можно понимать как «n коммитов перед HEAD» или «n-ый предок HEAD».
HEAD^ (или HEAD^1) тоже означает первого родителя коммита. Но вот HEAD^2 означает второго родителя коммита. Помните, коммит, представляющий собой нормальное слияние (merge), имеет двух родителей: первый родитель — это коммит, в который осуществляется слияние, а второй родитель — коммит, который был слит. Вообще говоря, слияния могут иметь произвольно много родителей (octopus merges).
Операторы ^ и ~ могут выстраиваться в линию, например, HEAD~3^2 будет означать второго родителя предка HEAD третьего уровня; HEAD^^2 — второго родителя первого родителя HEAD; HEAD^^^ — это просто эквивалент HEAD~3.

Получение изменений

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

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

Как работать с git?

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

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

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

git push origin master

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

Вебхуки (WebHooks) – это уведомление сторонних приложений посредством отправки на них уведомлений о произошедших событиях.

В командной работе перед отправкой на рабочий сайт может понадобиться согласование с ведущим разработчиком проекта. Поэтому доступ к основной ветке следует запретить. А слияние с ней будет происходить с помощью запросов (merge request).

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

А вот схема работы процесса в одной картинке:

Автоматический деплой с помощью вебхука

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

1. Забирает все изменения из удаленного репозитория

git fetch —all

2. Обновляет файлы до состояния, зафиксированном на удаленном репозитории, при этом удаляя все изменения на сайте, которые не были зафиксированы.

git reset —hard origin/master

Почему нужно удалять незафиксированные изменения?

Если коротко – исключить возможность конфликтов.

Конфликты возникают, когда произошли изменения в одном и том же файле, и при слиянии (merge) git не может верно решить, как правильно объединить файлы. Если одновременно редактировалась одна строка, то возникает конфликт. Программно невозможно решить, какая из версий должна быть на сайте.