Для чего нужен флаг bare
1 ответ 1
совсем короткая формулировка
вот вам надо, допустим, скопировать архив с одного сервера на другой, и вам дают инструкцию:
более обстоятельный ответ
начать надо, пожалуй, с иллюстрации того, что, собственно, представляет собой git-хранилище (часто используется термин «git-репозиторий»).
вот оно, свежесозданное хранилище, не отслеживающее (пока) ни одного файла, но уже содержащее 9 каталогов и 13 файлов (в разных версиях и сборках программы git конкретные цифры могут, конечно, слегка отличаться), необходимый минимум, который позволит программе git начать отслеживание файлов вашего проекта (ну, почти необходимый — без файлов с примерами из каталога hooks можно было бы и обойтись):
эти файлы и каталоги появятся в текущем (изначально пустом) каталоге после выполнения команды:
«спрятаны» они будут не только «для эстетики» и не только потому, что эти «внутренние потроха» для «обычного» пользователя программы git представляют мало интереса. основная цель — «освободить» текущий каталог под собственно файлы (и каталоги) вашего проекта. в этом случае он (текущий каталог) будет выполнять функции рабочего каталога (working tree в оригинальной документации, другой нередко встречающийся перевод — рабочая копия).
если при хранилище имеется рабочий каталог, то такое хранилище называют «не-bare-хранилищем», или «хранилищем с рабочим каталогом», а чаще, для краткости — просто «хранилищем». а если рабочего каталога нет, то такое хранилище называют «bare-хранилищем» (дословно — «голым»).
а какая польза от такого «bare-хранилища»? какой практический смысл в нём? что с ним можно сделать?
ну, с точки зрения «конечного» пользователя (чаще всего — программиста) пользы, действительно, мало, ведь не видно же файлов/каталогов проекта. а вот с точки зрения программы git — это полноценное хранилище, которое можно клонировать, делать из него pull-ы, а в него — push-ы. именно в таком виде (без рабочего каталога) располагаются хранилища на таких серверах, как github.com, bitbucket.org и тому подобных. программа git легко может извлечь и отобразить любую информацию из такого хранилища: историю коммитов, листинг файлов проекта, содержимое любого из файлов проекта в том состоянии, как он выглядел после любого из коммитов, и так далее и тому подобное.
ах, да, совсем забыл:
Настройка репозитория
Этот обучающий материал включает в себя обзор настройки репозитория в системе контроля версий Git. На этой странице вы узнаете, как инициализировать репозиторий Git для нового или существующего проекта. Ниже представлены примеры жизненного цикла для репозиториев, созданных локально и клонированных из удаленных репозиториев. Для работы с этим руководством требуются начальные знания о работе с интерфейсом командной строки.
В данном руководстве обсуждаются следующие основные вопросы:
По окончании данного модуля вы должны уметь создавать репозиторий Git, использовать основные команды Git, выполнять коммит измененного файла, просматривать историю проекта и настраивать соединение с сервисом хостинга Git (Bitbucket).
Что такое репозиторий Git?
Репозиторий Git — это виртуальное хранилище проекта. В нем можно хранить версии кода для доступа по мере необходимости.
Инициализация нового репозитория: git init
Создание версии существующего проекта с использованием нового репозитория Git
Указание в команде git init существующего каталога проекта приведет к исполнению описанной выше инициализации, но только на уровне этого каталога проекта.
Клонирование существующего репозитория: git clone
Команду git clone выполняют для создания копии (клонирования) удаленного репозитория. В качестве параметра в команду git clone передается URL-адрес репозитория. Git поддерживает несколько различных сетевых протоколов и соответствующих форматов URL-адресов. В этом примере используется SSH-протокол Git. URL-адреса SSH в Git имеют следующий шаблон: git@HOSTNAME:USERNAME/REPONAME.git
Дополнительную информацию об использовании команды git clone и поддерживаемых форматах URL-адресов в Git см. на странице git clone.
Сохранение изменений в репозитории: git add и git commit
«тест для обучения работе с Git»
По завершении этого примера файл CommitTest.txt добавится к истории репозитория, и репозиторий будет отслеживать последующие изменения в файле.
Совместная работа в разных репозиториях: git push
Важно понимать, что рабочая копия в Git существенно отличается от рабочей копии, получаемой при загрузке исходного кода из репозитория SVN. В отличие от SVN, в Git нет разницы между рабочими копиями и центральным репозиторием — все они являются полноценными репозиториями Git.
Поэтому совместная работа в Git принципиально отличается от совместной работы в SVN. В SVN работа строится на отношении между центральным репозиторием и рабочей копией, а модель совместной работы в Git основана на взаимодействии между репозиториями. Вместо загрузки рабочей копии в центральный репозиторий SVN в Git вы отправляете коммиты из одного репозитория в другой или копируете их в обратном направлении.
Вы легко можете задавать особую роль определенным репозиториям Git. Например, обозначив один из репозиториев Git как «центральный», вы можете воспроизвести централизованный процесс с использованием Git. Такой подход требует общих договоренностей, он не встроен в саму систему контроля версий.
Сравнение чистых и клонированных репозиториев
Если вы использовали команду git init для создания репозитория с нуля, у вас не будет удаленного репозитория, в который можно помещать изменения. Зачастую для инициализации нового репозитория пользователь переходит на сервис Git-хостинга (например, Bitbucket) и создает репозиторий там. Данный сервис предоставит URL-адрес Git, который затем можно добавить в локальный репозиторий Git. После этого можно выполнять команду git push в репозиторий на хостинге. После создания удаленного репозитория на выбранном хостинге вам понадобится обновить локальный репозиторий, выполнив привязку. Этот процесс описывается далее в руководстве по установке и настройке.
Конфигурирование и настройка: git config
Помимо конфигурирования URL-адреса удаленного репозитория, вам может потребоваться установить глобальные параметры Git, например имя пользователя или электронный адрес. Команда git config позволяет настроить инсталляцию Git (или отдельный репозиторий) из командной строки. С помощью этой команды можно установить любые настройки: от информации о пользователе до его предпочтений и характеристик репозитория. Ниже перечислены распространенные варианты конфигурации.
Git хранит варианты конфигурации в трех различных файлах, позволяющих ограничивать область видимости на уровне отдельных репозиториев (локальный), пользователя (глобальный) или всей системы (системный):
Эта команда задает имя автора, которое будет использоваться для всех коммитов, выполненных текущим пользователем.
Эта команда задает адрес электронной почты автора, который будет использоваться для всех коммитов, выполненных текущим пользователем.
Создайте быстрые клавиши для команды Git. Это мощная возможность для создания собственных комбинаций клавиш для часто используемых команд Git. Ниже показан упрощенный пример:
В текстовом редакторе откройте файл глобальной конфигурации для редактирования вручную. Подробное руководство по настройке текстового редактора для Git см. на странице Git config.
Пояснения
Git хранит варианты конфигурации в трех различных файлах, что позволяет ограничивать область видимости на уровне отдельных репозиториев, пользователей или всей системы.
Если параметры, указанные в этих файлах, конфликтуют, локальные настройки переопределяют пользовательские настройки, которые в свою очередь переопределяют системные настройки. Если вы откроете один из этих файлов, вы увидите нечто подобное:
Пример
В первую очередь после установки Git требуется указать свое имя и адрес электронной почты, а также настроить некоторые параметры по умолчанию. Пример типичной начальной конфигурации показан далее.
Представьтесь репозиторию Git с помощью команды git config
Выберите любимый текстовый редактор
Добавьте алиасы по типу SVN
Резюме
Мы показали, как создать репозиторий Git двумя способами: git init и git clone. Этим руководством можно пользоваться при необходимости управления исходным кодом ПО или другим контентом, при хранении которого требуется поддерживать версионность. Кроме того, были представлены команды git add, git commit, git push и git remote и показаны простые примеры их использования.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
git init
Команда git init создает новый репозиторий Git. С ее помощью можно преобразовать существующий проект без управления версиями в репозиторий Git или инициализировать новый пустой репозиторий. Большинство остальных команд Git невозможно использовать без инициализации репозитория, поэтому данная команда обычно выполняется первой в рамках нового проекта.
Использование
Сравнение git init и git clone
Шаблоны git init
Доступные по умолчанию шаблоны — это удобный справочный ресурс, в котором можно найти примеры использования возможностей шаблонов. В таких шаблонах в том числе показана настройка полезной функции Git hook. При создании шаблона можно задать нужные элементы Git hook. Это позволит инициализировать новые репозитории Git с готовыми к работе элементами hook. Дополнительные сведения о Git hook см. на странице о Git hook.
Настройка
Вывод только критических сообщений, сообщений об ошибках и предупреждений. Вывод других сообщений блокируется.
Создание чистого репозитория (см. раздел «Чистые репозитории» выше).
Указание каталога с шаблонами для использования (см. раздел «Шаблоны git init» выше).
Назначение прав доступа для нового репозитория. Данный параметр позволяет с помощью указания прав Unix задать пользователей и группы, которым разрешено осуществлять операции push и pull в репозитории.
Git: документация – часть 1: создание репозитория
Перевод замечательной документации от Atlassian.
Так же – есть отличный ресурс на русском тут>>>, в котором более детально рассматриваются вопросы, связанные с внутренней структурой Git.
В этой документации будут рассмотрены основные команды Git. В первой части – “Создание репозитория” – описаны утилиты, необходимые для начала работы с новым проектом под контролем Git.
git init
Команда git init создаёт новый репозиторий. Её можно использовать для превращения уже существующего проекта в Git-репозиторий – или для создания нового. Большинство других команд Git не смогут работать вне проинициализированного репозитория, поэтому как правило – это первая команда при запуске нового проекта.
Использование
Обсуждение
По сравнению с SVN – команда git init предоставляет очень простой способ создания нового проекта под контролем системы VSC (Version Control System). Git не требует от вас создания репозитория, импорта файлов и загрузки рабочей копии. Всё, что вам надо сделать – это перейти в каталог вашего проекта и выполнить git init – вы сразу получите полнофункциональный репозиторий Git.
Однако, во многих проектах git init требуется выполнить только для центрально репозитория – разработчики как правило не используют git init для создания локальных репозиториев. Вместо этого – они используют git clone для копирования имеющего репозитория на их локальные рабочие станции.
Неизолированные репозитории
Пример
Так как самым подходящим способом создания локальной копии проекта является git clone – то git init обычно использутеся для создания центрального репозитория:
git clone
Использование
Клонирует репозиторий, расположенный по пути на локальную машину. может быть расположен как на локальной файловой системе – так и на удалённом сервере, с доступом по HTTP(S) или SSH.
Обуждение
Если проект уже создан в центральном репозитории – git clone наиболее распространённый способ для пользователей получить свою рабочую копию этого проекта. Как и git init – git clone обычно выполняется один раз – после того как разработчик получил своб копию проекта все операции по контролю версий и совместная работа выполняются в локальном репозитории.
Свзять репозиторий-к-репозиторию (repo-to-repo)
Важно понимать, что смысл понятия “рабочая копия” у Git очень отличается от рабочий копии, которую вы получаете после загрузки кода из SVN. В отличии от SVN – Git не делает различий между рабочией копией кода и кодом в центральном репозитории – оба являются полноценными репозиториями Git.
Это делает работу с Git принципиально отличной от работы с SVN. В то время как SVN зависит от отношений между центральным репозиторием и рабочей копией – модель отношений в Git базируется на связи репозиторий-к-репозиторию. Вместо того, что бы загружать рабочую копию в центральный репозиторий SVN – вы загружаете в или из одного репозитория в другой.
Конечно, ничто не мешает назначить некоторым репозиториям Git особую роль. Например, просто указав один репозиторий как “центральный” – вы можете вести всю работу над кодом вокруг одного хранилища. Смысл тут заключается в том, что вы сами можете решать этот вопрос – а не зависеть от решений, ограниченных VCS.
Пример
Пример ниже дмеонстрирует, как получить копию данных из центрального репозитория, который хранится на сервере с именем example.com с помощью SSH и используя имя пользователя john:
git config
Команда git config позволяет вам настроить ваш Git (или отдельный репозиторий) из командной строки. С помощью неё можно определить все – от информации о пользователи до настроек поведения репозитория. Ниже показано нескорлько наиболее используемых настроек.
Использование
Определяет почтовый адрес автора для его коммитов.
Создаёт короткое имя для команды Git.
Определяет тектовый редактор, который будет использоваться такими командами как git commit для всех пользователей на этой машине. Аргумент должен быть именем исполняемого файла, который запускает желаемый редактор (например – vi ).
Открывает основной конфигурационный файл для ручного редактированияю
Обуждение
Git хранит опции в трёх различных файлах, что позволяет вам разделить опции для отдельных репозиториев, пользователей и всей системы:
В случае конфликтов – локальные настройки имеюти преимущество над настройками пользователя, а настройки пользователя – над общесистемными. Если вы откроете любой из этих файлов – вы увидите что-то вроде такого:
Пример
Первое, что вы можете захотеть сделать после установки Git – это определить ваше имя и почтовый ящик, а так же задать некоторые значения по умолчанию. Обычная конфигурация может выглядеть так:
Создание, настройка и использование собственного Git-сервера
Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.
Зачем нужен собственный Git-сервер?
В подобных ситуациях, для того, чтобы обойти ограничения, или если вам нужно контролировать то, что происходит с вашими репозиториями, лучше всего создать собственный Git-сервер. Это, с одной стороны, поможет сэкономить, а с другой — даст полный контроль над сервером. Среди продвинутых пользователей Linux весьма распространена практика использования собственных Git-серверов, размещаемых, можно сказать, бесплатно, на уже используемых ими серверах.
В этом руководстве мы поговорим о двух подходах к управлению кодовой базой с использованием собственного Git-сервера. Первый заключается в использовании обычного Git-сервера, а второй — в применении инструмента с графическим интерфейсом GitLab. В качестве платформы для экспериментов тут используется сервер на полностью пропатченной Ubuntu 14.04 LTS, развёрнутый на VPS.
Использование Git
Здесь мы рассматриваем сценарий, в соответствии с которым у нас имеется удалённый сервер и локальный сервер. Работаем мы периодически то с одним, то с другим.
Для начала установим Git на этих двух машинах. Git можно установить либо из пакета, доступного в репозитории используемого дистрибутива, либо вручную. Тут мы воспользуемся простейшим методом:
Затем добавим пользователя для Git:
Для того чтобы упростить доступ к удалённому серверу, настроим вход по ssh без пароля.
Создадим ssh-ключи на локальном компьютере:
Система спросит у вас о том, куда нужно сохранить ключ. Если вас устраивает стандартное место хранения ключа, просто нажмите Enter. Далее вам предложат задать пароль, который будет нужен для доступа к удалённому серверу.
Вышеописанная команда генерирует два ключа — открытый и закрытый. Запишите или запомните расположение открытого ключа. Он понадобится нам на следующем шаге.
Теперь надо скопировать эти ключи на сервер, что даст возможность наладить канал связи между двумя машинами. На локальном компьютере выполните следующую команду:
Теперь подключитесь по ssh к серверу и создайте директорию проекта для Git. Для репозитория можно использовать любую папку, которая покажется вам подходящей:
Затем перейдите в эту директорию:
Создайте пустой репозиторий:
Если команда успешно сработала, вы увидите сообщение, подобное следующему:
Теперь нужно создать Git-репозиторий на локальной машине. Для этого создаём директорию:
Далее, создаём в ней файлы проекта, и, оставаясь в ней, инициализируем репозиторий:
Об успешной инициализации репозитория можно судить по такому сообщению:
Теперь добавим файлы проекта в репозиторий:
До сих пор мы работали на локальном сервере. Теперь нам нужно отправить локальные данные на удалённый сервер, что сделает их доступными через интернет и позволит организовать совместную деятельность нескольких разработчиков:
Теперь можно отправлять изменения с локальной машины на сервер или загружать данные с сервера, используя, соответственно, опции push или pull :
Если над проектом намереваются работать и другие программисты, сначала им надо клонировать репозиторий с сервера на своих локальных компьютерах:
В данной команде /home/swapnil/project.git — это путь к папке проекта на удалённом сервере, в вашем случае тут будет другой путь.
Затем, после клонирования, надо перейти в директорию проекта:
У вас, вместо project будет имя другой директории. Теперь можно приступать к работе над проектом, принимать изменения и отправлять их на сервер:
Мы полагаем, что вышеприведённых сведений достаточно для того, чтобы помочь тем, у кого не было опыта работы с Git, приступить к использованию собственного Git-сервера. Если вам нужен некий инструмент с графическим интерфейсом, позволяющий работать с проектом на локальной машине, можно воспользоваться чем-то вроде QGit или GitK для Linux.
QGit — графический инструмент для локальной работы с Git-репозиториями
Использование GitLab
Выше мы описали систему, позволяющую организовать совместную работу над проектами с помощью Git, полностью основанную на средствах командной строки. Работать в такой среде, конечно, сложнее, чем с GitHub. По иронии судьбы, хотя GitHub — это крупнейший в мире сервис для хостинга кода, его собственный код закрыт. Это — не опенсорсный проект, то есть, нельзя взять этот код и создать на его основе собственный GitHub. В отличие от чего-то вроде WordPress и Drupal, код GitHub нельзя загрузить и развернуть на собственном сервере.
Но, как это обычно бывает в мире опенсорса, проектам с закрытым кодом можно найти замену. В данном случае заменой GitHub может послужить весьма привлекательный опенсорсный проект GitLab. Он позволяет всем желающим разворачивать на собственных серверах нечто подобное GitHub. При этом GitLab можно использовать и для поддержки работы крупной компании или большой команды, и для организации собственного репозитория для небольшого проекта, который пока не готов к тому, чтобы представить его широкой общественности.
GitLab задействует бизнес-модель, характерную для опенсорсных проектов. А именно, имеется свободно распространяемая версия ПО, которую все желающие могут разворачивать на своих серверах, и хостинг кода, похожий на GitHub.
Свободно распространяемая версия GitLab имеет две редакции — бесплатную Community Edition (Core) и платную Enterprise Edition (существуют её варианты Starter, Premium и Ultimate). Последняя основана на Community Edition, которая отлично масштабируется, и, кроме того, включает в себя некоторые дополнительные возможности, ориентированные на организации. Это немного напоминает позиционирование WordPress.org и WordPress.com.
Среди возможностей GitLab можно отметить управление Git-репозиториями, средства обзора кода, наличие системы отслеживания ошибок, ленты активности, поддержку вики-страниц. Здесь имеется и GitLab CI — система непрерывной интеграции.
Многие VPS-провайдеры, вроде DigitalOcean, предлагают пользователям дроплеты GitLab. Если вы хотите развернуть GitLab на собственном сервере, вы можете установить эту систему вручную. GitLab предлагает пакет Omnibus для различных операционных систем. Прежде чем установить GitLab, может возникнуть необходимость в настройке почтового SMTP-сервера для того, чтобы система могла отправлять электронную почту. Рекомендовано для этих целей пользоваться Postfix. Поэтому, перед установкой GitLab, установим Postfix:
В процессе установки Postfix система задаст вам несколько вопросов. Не стоит пропускать ответы на них, но если ответы на них не даны, можно перенастроить систему, выполнив следующую команду:
После запуска этой команды нужно указать параметр Internet Site и задать почтовый идентификатор для домена, который будет использоваться GitLab. Далее, надо будет указать имя пользователя для Postfix и почтовый адрес. Значения остальных параметров можно не менять. После установки и настройки Postfix можно заняться GitLab.
Загрузим свежий пакет отсюда с помощью wget :
Теперь установим его:
Настроим и запустим GitLab:
Теперь надо будет настроить доменное имя в конфигурационном файле, что даст возможность работать с GitLab. Откроем файл:
Сайт GitLab, открытый в браузере
Смена пароля на сайте GitLab
После того, как пароль изменён, можно войти на сайт и заняться работой с проектами.
Работа с проектами в GitLab
GitLab — это серьёзная система, имеющая массу возможностей. Как в них разобраться? Позволим себе привести тут несколько изменённую цитату из фильма «Матрица»: «Увы, невозможно рассказать о том, что умеет GitLab. Вы должны увидеть это сами».
Уважаемые читатели! Пользуетесь ли вы собственными Git-серверами? Если да — просим рассказать о том, как вы их настраиваете и поддерживаете.
