что это такое и в чём разница

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

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Содержание:

• Что такое Git
• Что такое GitHub и чем он отличается от Git
• Что такое система контроля версий
• Типы систем контроля версий
  • Локальные системы контроля версий (ЛСКВ)
  • Централизованные системы контроля версий (ЦСКВ)
  • Распределённые системы контроля версий (РСКВ)

Что такое Git

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

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

Преимущества Git:

• Бесплатный и open-source. Можно бесплатно скачать и вносить любые изменения в исходный код;
• Небольшой и быстрый. Выполняет все операции локально, что увеличивает его скорость. Кроме того, Git локально сохраняет весь репозиторий в небольшой файл без потери качества данных;
• Резервное копирование. Git эффективен в хранении бэкапов, поэтому известно мало случаев, когда кто-то терял данные при использовании Git;
• Простое ветвление. В других системах контроля версий создание веток— утомительная и трудоёмкая задача, так как весь код копируется в новую ветку. В Git управление ветками реализовано гораздо проще и эффективнее.

Теперь пора разобраться, что такое GitHub и как он работает с Git.

Что такое GitHub и чем он отличается от Git

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

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

Git-репозиторий, загруженный на GitHub, доступен с помощью интерфейса командной строки Git и Git-команд. Также есть и другие функции: документация, запросы на принятие изменений (pull requests), история коммитов, интеграция со множеством популярных сервисов, email-уведомления, эмодзи, графики, вложенные списки задач, система @упоминаний, похожая на ту, что в Twitter, и т. д.

Кроме GitHub есть другие сервисы, которые используют Git, — например, Bitbucket и GitLab. Вы можете разместить Git-репозиторий на любом из них.

Чтобы работать с Git эффективнее, посмотрите подборку шпаргалок: от основ до работы с GitHub.

Что такое система контроля версий

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

Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют разработчикам сохранять все изменения, внесённые в код. При возникновении проблем они могут просто откатить код до рабочего состояния и не тратить часы на поиски ошибок.

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

Типы систем контроля версий

Теперь вы знаете, что такое система контроля версий. Однако они тоже бывают разными. Существует три типа СКВ: локальная, централизованная и распределённая.

Локальные системы контроля версий (ЛСКВ)

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

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

Централизованные системы контроля версий (ЦСКВ)

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

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

Распределённые системы контроля версий (РСКВ)

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

Недостаток ЦСКВ был исправлен в РСКВ, клиенты которых не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени), а полностью копируют репозиторий. Это значит, что у каждого клиента есть копия всего исходного кода и внесённых изменений. В этом случае, если один из серверов выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Ещё одним преимуществом РСКВ является то, что они могут одновременно взаимодействовать с несколькими удалёнными репозиториями. Благодаря этому разработчики могут параллельно работать над несколькими проектами. Именно поэтому Git сейчас так популярен.

Написано на основе статьи «Difference Between Git and GitHub»

Git для начинающих. Часть 1. Что такое системы контроля версий?

Система контроля версий (Version Control System, VCS) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т. п. В статье рассмотрены виды VCS, принципы их работы, а также приведены примеры программных продуктов.

Что такое система контроля версий?

Наверное, всем знакома ситуация, когда при работе над проектом, возникает необходимость внести изменения, но при этом нужно сохранить работоспособный вариант, в таком случае, как правило, создается новая папка, название которой скорее всего будет  “Новая папка” с дополнением в виде даты или небольшой пометки, в нее копируется рабочая версия проекта и уже с ним производится работа. Со временем количество таких папок может значительно возрасти, что создает трудности в вопросе отката на предыдущие версии, отслеживании изменений и т.п. Эта ситуация значительно ухудшается, когда над проектом работает несколько человек.

Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update).

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

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

Централизованные системы контроля версий

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

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

Subversion (SVN) – система контроля версий, созданная на замену CVS. SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т. д. В целом SVN был (и остается) значительным шагом вперед по сравнению с CVS. 

Распределенные системы контроля версий

Распределенные системы контроля версий (Distributed Version Control System, DVCS) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

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

Начнем с Mercurial, эта система представляет собой свободную DVCS, которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg. Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla, OpenOffice, OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows, Mac OS, Linux), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial. Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git, который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux. Среди крупных проектов, в рамках которых используется git, можно выделить ядро Linux, Qt, Android. Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial, доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS, удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git, крупные корпорации, подобные Google, используют свои VCS.

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

Если вам больше нравится учиться по видео-лекциям, то рекомендуем классный курс по git от GeekBrains, перейдите по ссылке и найдите в разделе “Курсы” курс “Git. Быстрый старт”. Он бесплатный, нужно только зарегистрироваться на сайте. Рекомендуем повнимательнее посмотреть на этот ресурс, на нем ещё очень много чего интересного!

Часть 2. Установка Git >>>

Система контроля версий Git — javatpoint

следующий → ← предыдущая Система контроля версий — это программное обеспечение, которое отслеживает изменения в файле или наборе файлов с течением времени, чтобы вы могли позже вызвать определенные версии. Это также позволяет вам работать вместе с другими программистами. Система контроля версий — это набор программных инструментов, которые помогают команде управлять изменениями в исходном коде. Он использует базу данных особого типа для отслеживания каждой модификации кода. Разработчики могут сравнивать более ранние версии кода с более старой версией, чтобы исправить ошибки. Преимущества системы контроля версий Система контроля версий очень полезна и полезна при разработке программного обеспечения; разработка программного обеспечения без контроля версий небезопасна. Он обеспечивает резервные копии для неопределенности. Системы контроля версий предлагают быстрый интерфейс для разработчиков. Это также позволяет группам разработчиков программного обеспечения сохранять эффективность и гибкость в соответствии с масштабами команды, чтобы включать больше разработчиков. Вот некоторые ключевые преимущества системы контроля версий. Полная история изменений файла Одновременно работает Ветвление и слияние Прослеживаемость Типы системы контроля версий Система управления локализованной версии Централизованные системы контроля версий Распределенные системы контроля версий Локализованные системы контроля версий Метод локализованного контроля версий является распространенным подходом из-за его простоты. Но такой подход ведет к более высокой вероятности ошибки. При таком подходе вы можете забыть, в каком каталоге вы находитесь, и случайно записать не тот файл или скопировать файлы, которые вам не нужны. Чтобы решить эту проблему, программисты разработали локальные системы контроля версий с простой базой данных. В таких базах данных все изменения в файлах находились под контролем версий. Локальная система контроля версий хранит локальные копии файлов. Основным недостатком Local VCS является наличие единой точки отказа. Централизованная система контроля версий Разработчикам нужно было сотрудничать с другими разработчиками в других системах. Локализованная система контроля версий в этом случае не сработала. Для решения этой проблемы были разработаны централизованные системы контроля версий. В этих системах есть один сервер, содержащий версии файлов, и несколько клиентов для извлечения файлов из центрального места. Централизованные системы контроля версий имеют много преимуществ, особенно по сравнению с локальными системами контроля версий. Каждый в системе имеет информацию о работе, что другие делают над проектом. Администраторы имеют контроль над другими разработчиками. Легче иметь дело с централизованной системой контроля версий, чем с локализованной системой контроля версий. Локальная система управления версиями поддерживает серверный программный компонент, который хранит и управляет различными версиями файлов. Он также имеет тот же недостаток, что и локальная система контроля версий, а именно единую точку отказа. Распределенная система контроля версий Централизованная система управления версиями использует центральный сервер для хранения всей базы данных и совместной работы группы. Но из-за одноточечного отказа, что означает выход из строя центрального сервера, разработчики его не предпочитают. Далее разрабатывается распределенная система контроля версий. В распределенной системе управления версиями (например, Git, Mercurial, Bazaar или Darcs) у пользователя есть локальная копия репозитория. Таким образом, клиенты не просто извлекают последний снимок файлов, даже если они могут полностью отразить репозиторий. Локальный репозиторий содержит все файлы и метаданные, присутствующие в основном репозитории. DVCS позволяет автоматически управлять разветвлением и слиянием. Это ускоряет большинство операций, кроме толкания и вытягивания. DVCS расширяет возможности автономной работы и не зависит от одного места для резервного копирования. Если какой-либо сервер остановился и другие системы взаимодействовали через него, то любой из клиентских репозиториев мог быть восстановлен этим сервером. Каждая касса — это полная резервная копия всех данных. Эти системы не обязательно зависят от центрального сервера для хранения всех версий файла проекта. Разница между централизованной системой контроля версий и распределенной системой контроля версий Централизованные системы контроля версий — это системы, использующие архитектуру клиент/сервер . В централизованной системе контроля версий одна или несколько клиентских систем напрямую подключены к центральному серверу. Напротив, распределенные системы контроля версий — это системы, использующие одноранговую архитектуру . Существует множество преимуществ и недостатков использования обеих систем контроля версий. Давайте посмотрим на некоторые существенные различия между централизованной и распределенной системой контроля версий. Централизованная система контроля версий Распределенная система контроля версий В CVCS репозиторий размещается в одном месте и доставляет информацию многим клиентам. В DVCS у каждого пользователя есть локальная копия репозитория вместо центрального репозитория на стороне сервера. Основан на клиент-серверном подходе. Основан на клиент-серверном подходе. Это самая простая система, основанная на концепции центрального хранилища. Он гибкий и основан на концепции, согласно которой у каждого есть свой репозиторий. В CVCS сервер предоставляет новейший код всем клиентам по всему миру. В DVCS каждый пользователь может получить моментальный снимок кода и полностью отразить центральный репозиторий. CVCS прост в администрировании и имеет дополнительный контроль над пользователями и доступом к своему серверу из одного места. DVCS быстрее CVCS, так как вам не нужно взаимодействовать с центральным сервером для каждой команды. Популярными инструментами CVCS являются SVN (Subversion) и CVS . Популярными инструментами DVCS являются Git и Mercurial . CVCS легко понять новичкам. DVCS имеет сложный процесс для начинающих. Если сервер выходит из строя, ни одна система не может получить доступ к данным из другой системы. , если какой-либо сервер вышел из строя и через него взаимодействовали другие системы, этот сервер может восстановить любой из клиентских репозиториев Следующая темаУстановка Git на Windows ← предыдущая следующий →

Как работает контроль версий Git?

Git … Самый популярный и распространенный инструмент, используемый программистами в мире программирования.

Забудьте на мгновение об этом инструменте и просто посмотрите на картинку ниже…

Воспоминания… Ты смеешься?? (Да! Вы….)

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

Вы создаете несколько файлов в своем проекте, вносите некоторые изменения, реализуете что-то новое, а затем копируете файлы и даете им имя blogPost_new. Опять вносите изменения, создаете еще одну копию с другим именем файла blogPost_backup. Это продолжается, и теперь ваш каталог заполнен несколькими файлами для одного проекта. Файлы в вашем проекте: blogPost_old, blogPost_one, blogPost_two, blogPost_backup, blogPost_final и т. д. 

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

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

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

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

Возможно, вы использовали различные команды в git….git add, git push, git pull, git commit и т. д., но если мы спросим, ​​как все работает за кулисами и как выглядит поток Git, то каким будет ваш ответ…

Большинство из нас знает, не знает…

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

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

Краткое введение

Если вы не знакомы с этим инструментом, прочтите блог Полное руководство по Git и Github .

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

Давайте перейдем к главному… к основным функциям Git. Как Git обрабатывает ваши файлы и рабочий процесс.

Состояния в Git

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

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

Скорее всего, вы выполните описанные ниже действия…

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

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

1. Состояние изменено

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

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

2. Поэтапное состояние

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

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

3. Состояние фиксации

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

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

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

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

Расположение файлов  

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

1. Рабочий каталог

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

Не путайте рабочий каталог и каталог .git. Рабочий каталог создается пользователем и. Каталог git создается Git.

2. Промежуточная область

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

3. Каталог Git

• Этот каталог — сердце Git, где происходит все волшебство. Файлы в зафиксированном состоянии находятся в этом каталоге.
• Каталог .git создается Git и хранит файлы, которые зафиксированы или проинструктированы пользователем для мониторинга. В папке .git хранятся базы данных объектов и метаданные файлов.
• Команда git clone, за которой следует URL-адрес, создает локальную копию репозитория в вашей рабочей области.
• команда add добавляет файлы из рабочей области в индекс или в промежуточную область. Файл находится в промежуточном состоянии и помечен как зафиксированный, но еще не зафиксированный.
• При выполнении команд фиксации всех файлов, находящихся в промежуточном состоянии, их изменения будут зафиксированы в локальном репозитории.

Теперь взгляните на изображение ниже, чтобы понять весь рабочий процесс…

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

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

Теперь вопрос: если мы можем сделать все одной командой git pull, то зачем нам выполнять две отдельные команды git fetch и git merge?

Ответ таков: выполнение двух отдельных команд позволяет нам сравнивать файлы до того, как мы фактически получим последнюю версию файлов. Другими словами, вы можете получить файлы из удаленного репозитория с помощью команды git fetch, а затем запустить команду git diff HEAD , чтобы проверить, в чем разница между файлами, которые существуют в рабочем каталоге, и файлами, которые существуют в локальном репозитории. Основываясь на различиях, вы можете решить, хотите ли вы объединить файлы или нет. 9Команда 0006

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

Git Internals

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

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

1. объекты: Этот каталог действует как база данных и хранит все файлы репозиториев. Их содержимое кодируется и сжимается.

2. refs: Ссылки хранятся как обычные текстовые файлы в каталоге .git/refs, и этот файл хранит указатель на объекты фиксации. Проще говоря, если вам нужно манипулировать объектом, вам нужно запомнить хэш объекта. Запоминать эти хэши сложно, поэтому у git есть ссылка. Эти ссылки содержат хэш объекта фиксации.

3. HEAD: Этот файл содержит путь к ссылке, которая указывает на текущую ветку, над которой вы работаете, проверить.

4. config : В этом файле вы можете найти конфигурацию репо.

Некоторые вспомогательные команды, которые вы должны знать

Почти все команды git, такие как git add, git commit, состоят из некоторых низкоуровневых основных команд. Эти команды называются сантехническими командами (мы знаем, что это новое слово для вас… ).

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

• Предположим, у вас есть рабочий каталог, и вы инициализируете его с помощью Git. После инициализации вашего проекта, если вы создаете или помещаете в него файл, Git создает рабочее дерево , и в этот момент, когда вы запускаете команду git status , вы видите что-то вроде этого…

• Когда ваши файлы поэтапный git создает большой двоичный объект.
  

  This entry was posted in Популярное