Введение в Git

Опубликовано: 2022-06-30

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

Под каждым веб-сайтом выполняется код — независимо от того, используете ли вы WordPress, WooCommerce, Drupal, Magento, NextJS или даже код HTML, написанный вручную. Существуют наборы файлов, необходимые для того, чтобы каждая страница отображала и отображала контент для всего мира.

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

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

Понимание Git

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

Краткая история

Еще в 2005 году группа разработчиков создавала проект под названием Linux, бесплатную операционную систему с открытым исходным кодом. Им нужен был способ легко сообщать об изменениях сотням участников. Первоначально они распространяли отдельные патчи, содержащие обновленный код, но это оказалось проблематичным по многим направлениям, особенно при определении того, что является «истинной» и последней версией любого конкретного набора изменений.

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

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

График изменений

Концептуально Git можно представить как граф узлов, где каждый узел — это моментальный снимок всего проекта в определенный момент времени. Книга Git на git-scm.com описывает структуру моментального снимка.

Git хранит данные в виде моментальных снимков проекта с течением времени.

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

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

Пример git-графа

Создание графа Git

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

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

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

Git добавляет и фиксирует шаги

Путешествие назад во времени

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

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

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

Сила ветвления и слияния в Git

Одна из самых мощных возможностей Git — возможность создавать параллельные альтернативные реальности. Нет, правда.

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

После внесения изменений в ветку функций вы можете применить все изменения к основной ветке, выполнив слияние Git.

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

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

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

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

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

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

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

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

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

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

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

Что нельзя хранить в Git

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

Если присутствует файл «.gitiginore», Git проверит его, чтобы увидеть, должен ли он вообще отслеживать эти элементы. Внутри «.gitiginore» вы можете перечислить имена отдельных файлов, целые каталоги или целые типы файлов. Например, если вы хотите исключить все файлы .png и .jpg и всю папку «wp-content/uploads», в ваших файлах «.gitiginore» вы должны просто написать:

 *.png *.jpg wp-content/uploads

Зачем исключать медиафайлы из Git?

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

Хотите верьте, хотите нет, но вы можете не захотеть отслеживать изменения в самом ядре WordPress. На это есть несколько причин.

Во-первых, для любой CMS есть старая поговорка: «Не взламывайте ядро!» В ядре WordPress не должно быть ничего, что нужно было бы отслеживать. Любые обновления должны исходить от самого WordPress, и если вам нужна более ранняя версия, это легко указать при ее установке. Вы абсолютно можете хранить всю установку WordPress в Git, но в определенных ситуациях это не имеет большого значения. Вы действительно хотите отслеживать изменения только в коде, которым вы манипулируете, например, в ваших пользовательских плагинах и дочерних темах. Это действительно хорошая идея, чтобы проконсультироваться с вашим хостинг-провайдером за советом по этой теме.

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

Вывод

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

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

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

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

Связанные ресурсы

- Локальная разработка WordPress с XAMPP

- Расширенное использование Git и рабочие процессы

- Гит Хуки

- Что такое сайт для разработчиков?

- Кэширование для WordPress