Администрация хранилища в Git

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

Чтобы выполнить это руководство, мы должны иметь представление об основных командах Git, таких как add, commit, push и clone, чтобы они могли выполнять упражнения шаг за шагом. Также необходимо, чтобы у них была функциональная установка Git и достаточные разрешения для его запуска на компьютере или компьютере, с которым они хотят следовать руководству, таким образом, они гарантируют, что все будет работать правильно.

Типы хранилищ

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

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

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

Клонировать репозиторий

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

 git clone repository_name 

Давайте рассмотрим пример того, как мы можем клонировать локальный репозиторий, чтобы выполнить этот пример, у нас должен быть только инициализированный репозиторий.
Давайте предположим, что у нас есть проект с именем example1, и он находится в папке с именем projects, и мы хотим получить его клон, но в новую папку с именем cloned в той же файловой системе. Для достижения цели мы должны остановиться на папке назначения и указать команду git clone, указывающую путь к проекту, который будет клонирован. В этом примере это будет следующим:

 git clone path \ projects \ example1 

Давайте посмотрим, как это выглядит в нашей командной консоли:

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

Происхождение

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

У нас есть один файл с именем File.txt. Если мы увидим клонированный проект, то заметим, что в нем есть два файла, и увидим, как внести изменения. Если мы заметим сообщение, которое выдает нам, мы увидим, что мы действительно получим ошибку:

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

$config[ads_text5] not found

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

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

$config[ads_text5] not found

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

Создайте наше собственное происхождение

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

 Git Remote добавить «имя» «маршрут» 

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

$config[ads_text6] not found

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

Мы видим, что, просто сделав новый push- запрос и Git знает, где зафиксировать содержимое коммита, мы клонируем этот новый пустой репозиторий, чтобы проверить его содержимое:

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

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