Настройка репозитория Git
Репозиторий Git или репозиторий — это папка, в которую Git отслеживается изменения. На компьютере может быть любое количество репозиториев, хранящихся в собственной папке. Каждый репозиторий Git в системе является независимым, поэтому изменения, сохраненные в одном репозитории Git, не влияют на содержимое другого.
Репозиторий Git содержит каждую версию каждого файла, сохраненного в репозитории. Это отличается от других систем управления версиями, которые хранят только различия между файлами. Git сохраняет версии файлов в скрытой папке .git вместе с другими сведениями, которыми он должен управлять кодом. Git экономит эти файлы очень эффективно, поэтому наличие большого количества версий не означает, что он использует много места на диске. Хранение каждой версии файла помогает Git объединить код лучше и упрощает работу с несколькими версиями кода.
Разработчики работают с Git с помощью команд, выданных при работе в локальном репозитории на компьютере. Даже при совместном использовании кода или получении обновлений из команды выполняется из команд, которые обновляют локальный репозиторий. Этот локальный дизайн — это то, что делает Git распределенной системой управления версиями. Каждый репозиторий является автономным, и владелец репозитория отвечает за сохранение его актуальности с изменениями от других.
Большинство команд используют центральный репозиторий, размещенный на сервере, который каждый может получить доступ к координации своих изменений. Центральный репозиторий обычно размещается в решении управления версиями, например GitHub или Azure DevOps. Решение управления версиями добавляет функции и упрощает совместную работу.
Создание репозитория Git
Существует два варианта создания репозитория Git. Вы можете создать один из кода в папке на компьютере или клонировать его из существующего репозитория. При работе с кодом, который находится только на локальном компьютере, создайте локальный репозиторий с помощью кода в этой папке. Но большую часть времени, когда код уже предоставлен в репозитории Git, поэтому клонирование существующего репозитория на локальный компьютер рекомендуется использовать.
Создание репозитория из существующего кода
git init Используйте команду, чтобы создать репозиторий из существующей папки на компьютере. В командной строке перейдите в корневую папку, содержащую код и выполните следующую команду:
для создания репозитория. Затем добавьте все файлы в папку в первую фиксацию с помощью следующих команд:
> git commit -m «Initial commit»
Создание репозитория из удаленный репозиторий
git clone Используйте команду, чтобы скопировать содержимое существующего репозитория в папку на компьютере. В командной строке перейдите в папку, чтобы содержать клонированного репозитория, а затем выполните следующую команду:
Не забудьте использовать фактический URL-адрес существующего репозитория вместо URL-адреса заполнителя, показанного в этом примере. Этот URL-адрес, называемый URL-адресом клонирования, указывает на сервер, где команда координирует изменения. Получите этот URL-адрес из команды или с кнопки клонирования на сайте, где размещен репозиторий.
Не обязательно добавлять файлы или создавать начальную фиксацию при клонировании репозитория, так как он был скопирован вместе с журналом из существующего репозитория во время операции клонирования.
Следующие шаги
GitHub и Azure Repos предоставляют неограниченные бесплатные общедоступные и частные репозитории Git.
Являетесь пользователем Visual Studio? Дополнительные сведения о создании и клонировании репозиториев из Visual Studio см. в этом руководстве по Git.
Что такое Repo?
Репозиторий – это централизованное цифровое хранилище, которое разработчики используют для внесения изменений в исходный код приложения и управления ими. При разработке программного обеспечения разработчики должны хранить папки, текстовые файлы и другие типы документов и обмениваться ими. Репозиторий обладает функциями, которые позволяют разработчикам легко отслеживать изменения в коде, одновременно редактировать файлы и эффективно вести совместную работу над одним и тем же проектом в любом местоположении.
Почему репозиторий важен
Репозиторий позволяет командам разработчиков программного обеспечения вносить многочисленные изменения в код программы без ущерба для основного исходного кода. Вместо того чтобы вносить изменения непосредственно в основную ветку, они используют функции в репозитории для редактирования и просмотра изменений. Это уменьшает конфликты при слиянии, когда два или более разработчика редактируют одну и ту же часть кода.
Разработчики также используют репозитории для внедрения новых функций или исправления ошибок без влияния на производственную версию приложения. Они создают новую ветвь или копию исходного кода в качестве локального хранилища для работы. Таким образом, разработчики обеспечивают надлежащее тестирование новых изменений перед их выпуском для клиентов.
Преимущества репозитория для бизнеса
Предприятия становятся более гибкими и быстро реагируют на меняющиеся запросы потребителей, когда используют репозитории для разработки приложений. Разработчики могут быстро работать над новыми функциями, не влияя на стабильность реального приложения. Репозитории позволяют им быстро вносить изменения и решать потенциальные проблемы. Организации также могут координировать задачи по разработке приложений между разработчиками, которые работают удаленно.
Что такое репозиторий GitHub
GitHub – это облачный репозиторий, который позволяет разработчикам организованно хранить коды проектов и работать над ними. GitHub построен на базе Git, системы контроля версий, и включает дополнительные функции, улучшающие сотрудничество между разработчиками. Он предоставляет графический пользовательский интерфейс, который упрощает использование функций хранилища.
GitHub также стал онлайн-сообществом разработчиков проектов с открытым исходным кодом. Разработчики могут общаться с коллегами, присоединяясь к обсуждению, предлагая помощь и делясь своим опытом на благо публичных проектов на GitHub.
Поскольку GitHub является наиболее популярным и часто используемым репозиторием среди сообществ разработчиков по всему миру, эта статья блога посвящена именно репозиториям GitHub.
Как работает репозиторий GitHub?
Репозиторий GitHub позволяет разработчикам удаленно и распределенно сотрудничать с локально установленным инструментом контроля версий. Разработчики используют интерфейс командной строки для реализации функций в Git – программе контроля версий.
Git позволяет разработчикам создавать, управлять и объединять изменения кода с основным исходным кодом.
Создание
Сначала разработчики создают новый репозиторий в директории проекта, содержащий файлы кода. В качестве альтернативы они могут клонировать Git-репозиторий из существующего. Репозиторий Git обычно содержит файл README, в котором отображается информация, описывающая проект.
Настройка
Перед внесением изменений в локальный репозиторий разработчики настраивают его, добавляя такую информацию, как имя пользователя и электронная почта. Это позволяет сотрудникам определить автора конкретного Git-репозитория. Затем разработчик может внести изменения в код и сохранить их с помощью команды git commit.
Изменение
Разработчики вносят изменения в код в своем репозитории. Первоначально изменения хранятся только в их локальной системе. Когда изменения готовы, они могут объединить их с центральным репозиторием. Если другой разработчик вносит изменения в тот же файл, он может вручную просмотреть и разрешить любые конфликты.
Какие основные возможности предлагает репозиторий GitHub
Репозитории GitHub предоставляют разработчикам централизованные возможности версионирования кода, обмена и совместной работы со следующими функциями.
Разветвления
Разветвления – это процесс создания копии репозитория на GitHub. По умолчанию репозиторий GitHub имеет основную ветвь, содержащую исходные коды и файлы, которые разработчики загружают изначально. Если им нужно изменить определенную часть кода, они создают ветку, содержащую полную копию файлов кода, и соответствующим образом маркируют эту ветку.
Разработчики могут создавать несколько ответвлений основного репозитория. Например, они могут создать ветку функций для написания кода для новых функций программного обеспечения и другую ветку для устранения проблем, о которых было сообщено.
Commit
Commit – это функция, позволяющая разработчикам сохранять все изменения, внесенные ими в файлы кода в ветке. GitHub позволяет разработчикам описывать новые изменения, которые они внесли в код, при их сохранении. Благодаря этому члены команды будут в курсе изменений и причин, по которым они были внесены.
Запрос на извлечение
Запрос на извлечение посылает официальное сообщение другим участникам, работающим над основной веткой, или владельцу ветки с просьбой рассмотреть сохраненные изменения. Соавторы могут просматривать, комментировать или вносить дополнительные изменения в исходный коммит, прежде чем отправить его на слияние. Когда они просматривают запрос на извлечение, вкладчики могут видеть изменения в исходном коде.
Слияние
Слияние – это процесс GitHub, который применяет сохраненные изменения к основной ветке. Это делается, когда члены команды просмотрели и одобрили сохраненные изменения. Затем они вызывают запрос на слияние на GitHub, который запускает серию проверок перед слиянием изменений с исходным кодом.
Каковы типы репозиториев Git?
Разработчики могут создавать два типа репозиториев Git с различными уровнями прав доступа.
Репозитории без операционной системы
Пустой репозиторий содержит только индексную папку. Разработчики не могут изменять файлы в пустом хранилище.
Непустые хранилища
Непустой репозиторий хранит копии исходных файлов, над которыми разработчики могут работать и в которых могут сохранять изменения.
Как AWS поддерживает ваши требования к репозиториям?
В Amazon Web Services (AWS) AWS CodeCommit – это онлайн-система версионирования кода, которую можно использовать для безопасного размещения частных репозиториев Git. CodeCommit интегрируется с существующими инструментами на базе Git, образуя бесшовный конвейер непрерывной доставки и непрерывной интеграции (CI/CD). Ниже приведены некоторые способы использования CodeCommit.
- Обеспечьте автоматическую защиту кода с помощью шифрования, независимо от того, находится он в пути или в состоянии покоя
- Держите свои репозитории ближе к среде AWS
- Настройте безопасные и масштабируемые рабочие процессы совместной работы над кодом в облаке AWS
Начните работу с репозиториями сегодня, зарегистрировав аккаунт AWS.
Git репозиторий что это
Git (читается как «гит») — это система контроля версий, которая помогает отслеживать историю изменений в файлах. Git используют программисты для совместной работы над проектами.
«IT-специалист с нуля» наш лучший курс для старта в IT
Git — система контроля версий
В самом простом виде контроль версий — это сохранение на компьютере серии измененных файлов, например с разными датами в названии, или режим отслеживания исправлений в текстовых документах.
Разработчикам часто бывает нужно вернуться к предыдущей версии кода:
- если оказывается, что решаемая задача больше не актуальна;
- если требуется внести исправления в более раннюю версию программы;
- если ошибка нашлась во время работы над новой задачей.
Если над проектом работает много людей, нужно, чтобы они могли вносить изменения в одни и те же файлы без конфликтов и потерь кода. Все эти задачи удобно решаются с помощью Git.
К базовым возможностям Git относятся:
- возврат к любой предыдущей версии кода;
- просмотр истории изменений;
- параллельная работа над проектом;
- backup кода.
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Начало работы с Git
Чтобы работать с Git, нужно установить ее на компьютер. На официальном сайте Git можно найти установщик и подробные инструкции для новичков.
Git можно использовать из командной строки во встроенном терминале или установить клиент с графическим пользовательским интерфейсом. Графический интерфейс более удобен для новичков, однако часто в таких клиентах реализована только некоторая часть функциональности, поэтому в основном разработчики пользуются командной строкой.
Что такое репозиторий Git?
Репозиторий — это все файлы, находящиеся под контролем версий, вместе с историей их изменения и другой служебной информацией.
Репозиторий Git можно создать, либо выбрав любую папку на компьютере, либо клонировав себе уже существующий репозиторий, например у работодателя.
Где хранится репозиторий?
Существуют разные способы хранения и использования репозитория: выделяют локальные, централизованные и распределенные системы контроля версий.
В локальных системах контроля версий репозиторий хранится и используется на одном устройстве, но работать с такой системой может только один разработчик. В случае централизованной системы репозиторий хранится на одном сервере.
Лучше всего для большого количества разработчиков подходят распределенные системы контроля версий, к которым относится и Git. Такая система представляет собой облачное хранилище: каждый пользователь хранит на своем устройстве весь репозиторий целиком, и по мере изменения репозитории синхронизируются.
Что такое коммит и коммитить?
По-английски commit значит «фиксировать». Git-коммит — это операция, которая берет все подготовленные изменения и отправляет их в репозиторий как единое целое.
Зачем нужен коммит, если Git и так следит за всеми изменениями? Коммиты разбивают процесс разработки, состоящий из большого количества правок, на отдельные шаги. То есть коммит — это некое логически завершенное изменение внутри проекта и понятная (в том числе и другим разработчикам) точка, к которой можно вернуться, если возникнут какие-то проблемы.
Изменения в рамках одного коммита подчиняются определенным, установленным командой разработчиков правилам и рекомендациям, касающимся именования, описания и содержания коммитов.
Как правило, рабочий процесс представляет собой цикл: коммит — изменение файлов — коммит.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Что такое ветвление?
Удобная поддержка ветвления — важное свойство Git. Использование ветвления позволяет решать отдельные задачи, не вмешиваясь в основную линию разработки.
Ветка в Git — это последовательность коммитов. С технической точки зрения ветка — это указатель или ссылка на последний коммит в этой ветке. По умолчанию, имя основной ветки в Git — master. Каждый раз, когда создается новый коммит, указатель ветки master автоматически передвигается на него.
При создании новой ветки коммиту дается новый указатель, например testing. Если переключиться на ветку testing и сделать новый коммит, то указатель на ветку testing переместится вперед, тогда как указатель на основную ветку master останется на месте. Переключившись обратно на ветку master, файлы в рабочем каталоге вернутся в состояние коммита, на который указывает master.
В этом примере история проекта разошлась на две изолированные друг от друга версии, между которыми можно переключаться и при желании слить их в одну.
Зачем нужен GitHub?
GitHub — это самый популярный сайт для хранения git-репозиториев и работы с ними. Также GitHub является крупнейшей площадкой для размещения проектов с открытым исходным кодом. Для просмотра и загрузки общедоступных репозиториев не требуется ни регистрации, ни оплаты аккаунта.
В каком-то смысле GitHub — это еще и социальная сеть для разработчиков. Зарегистрированные пользователи могут публиковать контент и управлять своими репозиториями, вносить вклад в чужие репозитории, вести обсуждения, просматривать изменения в коде, комментировать их и следить за обновлениями знакомых.
GitHub часто используют при рекрутменте — активный аккаунт и высокое качество кода могут сильно помочь в поиске работы. Поэтому особенно важно иметь аккаунт, чтобы показать свой код коллегам и как он эволюционирует со временем.
Сейчас существует и множество других онлайн-сервисов, интегрированных с Git. Альтернативы GitHub — это, например, GitLab и BitBucket. У обоих сайтов меньше аудитория, но у них есть свой функционал и свои преимущества, например BitBucket более удобен для небольших проектов с закрытым кодом.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
Мобильный разработчик о том, как pet-проекты открывают двери в Сбербанк и МТС
Делимся ресурсами для поиска и подборкой возможностей для студентов в IT, которыми можно воспользоваться прямо сейчас
¶ Репозиторий
Репозиторий — каталог файловой системы, в котором могут находиться файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.
- локальный (расположен непосредственно в памяти компьютера разработчика, в нем происходит разработка и фиксация изменений, после чего можно отправить на удаленный репозиторий)
- удаленный (находится на сервере, может быть приватным – доступным ограниченному числу лиц, и публичным – open source)
По умолчанию репозиторий хранится в подкаталоге с названием .git в корневом каталоге рабочей копии дерева файлов, хранящегося в репозитории. Любое файловое дерево в системе можно превратить в репозиторий git, отдав команду создания репозитория из корневого каталога этого дерева (или указав корневой каталог в параметрах программы).
Репозиторий может быть импортирован с другого узла, доступного по сети. При импорте нового репозитория автоматически создается рабочая копия, соответствующая последнему зафиксированному состоянию импортируемого репозитория (то есть не копируются изменения в рабочей копии исходного узла, для которых на том узле не была выполнена команда commit).
Для того чтобы узнать как создать репозиторий перейдите по ссылке:
git quickstart
¶ Зеркалирование репозиториев
Зеркальное отображение репозиториев позволяет выполнять зеркальное отображение репозиториев на внешние источники и из них. Его можно использовать для зеркалирования веток, тегов и коммитов между репозиториями.
Зеркальное отображение репозитория полезно, когда вы хотите использовать репозиторий вне GitLab.
GitLab поддерживает два типа зеркалирования репозитория:
- Push: для зеркалирования репозитория GitLab в другое место.
- Вытягивание: для зеркалирования репозитория из другого места в GitLab.
При обновлении зеркального репозитория все новые ветки, теги и фиксации будут отображаться в ленте активности проекта.
Пользователи, имеющие как минимум доступ к проекту для разработчиков, также могут принудительно выполнить немедленное обновление, если:
- Зеркало уже обновляется.
- С момента последнего обновления не прошло 5 минут.
¶ Случаи применения
Ниже приведены некоторые возможные варианты использования зеркального отображения репозитория:
- Вы перешли на GitLab, но по-прежнему хотите сохранить свой проект в другом источнике. В этом случае вы можете просто настроить его для зеркалирования в GitLab (pull), и вся необходимая история коммитов, тегов и веток будет доступна в вашем экземпляре GitLab.
- У вас есть старые проекты в другом источнике, которые вы больше не используете активно, но не хотите удалять для архивирования. В этом случае вы можете создать push-зеркало, чтобы ваш активный репозиторий GitLab мог отправлять свои изменения в старое расположение.
- Вы являетесь пользователем GitLab с самоуправлением по соображениям конфиденциальности, и ваш экземпляр закрыт для публики, но у вас все еще есть определенные программные компоненты, которые вы хотите использовать с открытым исходным кодом. В этом случае использование GitLab в качестве основного репозитория, закрытого для общественности, и использование push-зеркалирования в общедоступный репозиторий, позволяет вам открывать конкретные проекты с открытым исходным кодом и вносить свой вклад в сообщество с открытым исходным кодом.
¶ Отправка в удаленный репозиторий
Для существующего проекта вы можете настроить push-зеркалирование следующим образом:
- Перейдите в Settings ->Repository и разверните раздел Mirroring repositories.
- Введите URL-адрес репозитория.
- В раскрывающемся списке «Mirror direction» выберите «Push».
- При необходимости выберите метод аутентификации в раскрывающемся списке Authentication method .
- При необходимости установите флажок «Keep divergent refs» (сохранять расходящиеся ссылки).
- При желании установите флажок «Only mirror protected branches» (только защищенные зеркалом ветви) .
- Нажмите кнопку «Mirror repository» , чтобы сохранить конфигурацию.
¶ Что значит сохранить расходящиеся ссылки
По умолчанию, если какая-либо ссылка на удаленном зеркале отличается от локального репозитория, вся отправка завершится неудачей и ничего не будет обновлено.
Например, если в репозитории есть master , develop и stable ветки, которые были зеркалированы на удаленный компьютер, а затем добавляется новый коммит для разработки на зеркале, следующая попытка push завершится неудачно, и master и stable ветки будут отключены. Никакие изменения в любой ветви не могут быть отражены, пока расхождение не будет устранено.
При включенной опции «Keep divergent refs» ветвь develop пропускается, позволяя обновлять master и stable .Статус зеркала будет отражать то, что develop разошлось и было пропущено, и будет помечено как неудачное обновление.
После создания зеркала этот параметр можно изменить только через API .
Когда включено push-зеркалирование, только push фиксируется непосредственно в зеркальном репозитории, чтобы предотвратить расхождение зеркала. Все изменения попадут в зеркальный репозиторий всякий раз, когда:
- Коммиты отправляются в GitLab.
- Инициируется принудительное обновление.
Изменения, отправленные в файлы в репозитории, автоматически отправляются на удаленное зеркало по крайней мере:
- В течение пяти минут после получения.
- В течение одной минуты, если включен параметр «Only mirror protected branches» (только защищенные зеркалом ветви).
Вы можете отправлять только защищенные ветки из GitLab в удаленный репозиторий.
В случае разветвленной ветви вы увидите ошибку, указанную в разделе «Mirroring repositories».
Вы также можете создавать и изменять push-зеркала проекта через API удаленных зеркал.
¶ Извлечение из удаленного репозитория
Вы можете настроить репозиторий так, чтобы его ветки, теги и коммиты автоматически обновлялись из вышестоящего репозитория.
Это полезно, когда интересующий вас репозиторий находится на другом сервере, и вы хотите иметь возможность просматривать его содержимое и его активность с помощью знакомого интерфейса GitLab.
Чтобы настроить вытягивание зеркала для существующего проекта:
- Перейдите в «Settings» -> «Repository» и разверните раздел «Mirroring repositories«.
- Введите URL-адрес репозитория.
- Выберите «Pull» в списке от «Mirror direction».
- При необходимости выберите метод аутентификации в раскрывающемся списке «Authentication method«.
- При необходимости установите следующие флажки:
- Overwrite diverged branches. (перезаписать расходящиеся ветви)
- Trigger pipelines for mirror updates. (запускайте конвейеры для обновлений зеркал)
- Only mirror protected branches.(только зеркально защищенные ветви)
- Нажмите кнопку «Mirror repository» , чтобы сохранить конфигурацию.
Поскольку GitLab теперь настроен на получение изменений из вышестоящего репозитория, вам не следует отправлять коммиты напрямую в репозиторий GitLab. Вместо этого любые коммиты следует отправлять в вышестоящий репозиторий. Изменения, отправленные в вышестоящий репозиторий, будут перенесены в репозиторий GitLab либо:
- Автоматически в течение определенного периода времени.
- Когда инициируется принудительное обновление.
Если вы вручную обновите ветку в репозитории GitLab, ветка будет отделена от восходящей, и GitLab больше не будет автоматически обновлять эту ветку, чтобы предотвратить потерю любых изменений. Обратите внимание, что удаленные ветки и теги в исходном репозитории не будут отражены в репозитории GitLab.
Для более подробной информации можно перейти по ссылке: Repository mirroring
¶ Коммит
Создать коммит (commit) — значит зафиксировать изменения любых файлов, входящих в репозиторий.
Любые файлы, созданные или измененные вами и для которых вы не выполнили git add после редактирования, не войдут в ваш коммит. Они останутся измененными файлами на вашем диске.
git commit — это команда для записи индексированных изменений в репозиторий Git.
Пример работы с коммитом можно посмотреть в разделе «Быстрый старт в Git»(в блоке «Что такое коммит?»).
¶ Если коммиты с другой почты
В статистике Git, размещенной в Личном кабинете, учитываются коммиты, сделанные только с почты с доменом @miem.hse.ru.
Если вы сделали часть коммитов с другой почты, то необходимо добавить ее в настройках аккаунта.
Для этого выполните следующие действия:
- Нажмите на иконку профиля в правом верхнем углу;
- Перейдите в «Settings«;
- Выберите раздел «Emails» в боковом меню;
- Там вы сможете указать дополнительную почту:
Обязательно перейдите по ссылке из письма с подтверждением, которое придет на указанный адрес. Чтобы статистика появилась в личном кабинете, необходимо сделать хотя бы один коммит в репозиторий после добавления почты.
¶ Просмотр истории коммитов
После того, как вы создали несколько коммитов или же склонировали репозиторий с уже существующей историей коммитов, вам может понадобится возможность посмотреть, что было сделано, то есть историю коммитов. Для этого используется команда git log .
Если вы запустите команду git log в папке склонированного проекта, то увидите следующий вывод:
По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке: последние коммиты находятся вверху.
¶ Поиск коммитов по разным критериям
Команда git log имеет большое количество опций для поиска коммитов по разным критериям. Рассмотрим наиболее популярные из них.
- Одним из самых полезных аргументов является -p или —patch , который показывает разницу (выводит патч), внесенную в каждый коммит. Вы можете ограничить количество записей в выводе команды; используйте параметр -2 для вывода только двух записей:
Эта опция отображает аналогичную информацию, но содержит разницу для каждой записи. Удобно использовать данную опцию для код ревью или для быстрого просмотра серии внесенных изменений.
- Существует возможность использовать серию опций для обобщения. Например, если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию —stat :
Опция —stat печатает под каждым из коммитов список и количество измененных файлов, а также сколько строк в каждом из файлов было добавлено и удалено.
- Рассмотрим опцию —pretty . Она меняет формат вывода. Существует несколько встроенных вариантов отображения:
- Опция oneline выводит каждый коммит в одну строку, это удобно, если вы просматриваете большое количество коммитов.
- Опции short , full и fuller делают вывод приблизительно в том же формате, но с меньшим или большим количеством информации соответственно:
- Опция format позволяет указать формат для вывода информации. Это полезно, когда вы хотите сгенерировать вывод для автоматического анализа. Так как вы указываете формат явно, он не будет изменен даже после обновления Git:
Полезные опции для git log —pretty=format отображает наиболее полезные опции для изменения формата.
- Наиболее распространенные опции для команды git log содержат описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
¶ Разница между автором и коммитером.
Автор – это человек, изначально сделавший работу, а коммитер – это человек, который последним применил эту работу. Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника: вы как автор и основной член команды как коммитер.
¶ Ограничение вывода
В дополнение к опциям форматирования вывода, команда git log принимает несколько опций для ограничения вывода – опций, с помощью которых можно увидеть определенное подмножество коммитов. Вы уже видели одну из таких опций — это опция -2 , которая показывает только последние два коммита.
- В действительности вы можете использовать -n , где n – это любое натуральное число и представляет собой n последних коммитов. На практике вы не будете часто использовать эту опцию, потому что Git по умолчанию использует постраничный вывод и вы будете видеть только одну страницу за раз.
Полезны такие опции для ограничения вывода по времени, как —since и —until . Например, следующая команда покажет список коммитов, сделанных за последние две недели:
git log —since=2.weeks
Эта команда работает с большим количеством форматов. Вы можете указать определенную дату ( «2020-10-20» ) или же относительную дату, например, «2 years 1 day 3 minutes ago» .
Можно фильтровать список коммитов по заданным параметрам. Опция —author дает возможность фильтровать по автору коммита, а опция —grep искать по ключевым словам в сообщении коммита.
Допускается указывать несколько параметров —author и —grep для поиска, которые позволят найти коммиты, сооветствующие любому указанному —author и любому указанному —grep шаблону; однако применение опции —all-match заставит искать коммиты соответствующие всем указанным —grep шаблонам.
- Опция -S принимает аргумент в виде строки и показывает только те коммиты, в которых изменение в коде повлекло за собой добавление или удаление этой строки. Например, если вы хотите найти последний коммит, который добавил или удалил вызов определенной функции, вы можете запустить команду: git log -S
- Опция «путь». Если вы укажете директорию или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире — , что отделяет указываемый путь от опций.
Опции для ограничения вывода команды git log вы можете увидеть эти и другие распространенные опции.
¶ Ветки
Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию имя основной ветки в Git — master.
Как только вы начнете создавать коммиты, ветка master будет всегда указывать на последний коммит. Каждый раз при создании коммита указатель ветки master будет передвигаться на следующий коммит автоматически.
¶ Создание новой ветки
Что происходит при создании ветки? Создаётся новый указатель для дальнейшего перемещения.
Чтобы создать ветку и сразу переключиться на нее, можно выполнить команду git checkout с параметром -b: git checkout -b testing .
Это тоже самое что и:
$ git branch testing
$ git checkout testing
Здесь мы сначала создали ветку, затем перешли на нее.
Вы всегда можете отследить, на какой ветке находитесь, с помощью команды git status .
¶ Работа с веткой master
По умолчанию master ветка защищенная (protected). То есть в нее может пушить только Maintainer. Лучше всего работать в другой ветке и делать merge request в master. Либо (не рекомендуется) — убирать защиту с master ветки.
¶ Как сделать merge request
Merge request позволяет перед коммитом в master ветку отправить внесенные изменения другим разработчикам проекта. Это аналог pull request в git. Merge request позволяет предотвратить внесение некорректных изменений, которые сломают проект.
Для начала создадим и перейдем на ветку, с которой будем работать:
git checkout -b — создание новой ветки и переключение на нее; вместо мы укажем development.
git add . — точка после git add означает, что git будет следить за всеми файлами;
git commit -m «Комментарий» — вместо — комментарий к коммиту;
git push -u origin — вместо , куда пишем (в нашем случае development)
Далее нужно перейти в настройки вашего проекта, в боковой меню нажмите на «Merge Requests«.
В открывшемся окне нажмите на кнопку «New Merge Request» для создания нового запроса на слияния одной ветки с другой.
В разделе выберите ветку, из которой хотите добавить изменения (в нашем случае development). В качестве «Target branch» выберите master.
Затем нажмите на кнопку «Compare branches and continue«.
Если не возникло конфликтов, на новой странице задайте заголовок, описание и в поле Assignee выберите своего руководителя.
Рекомендуем вам делать при слиянии веток сквош: объединять коммиты. Это помогает избежать путаницы и длинного списка коммитов. Для этого просто поставьте галочку около пункта «Squash commits when merge request is accepted». Далее нажмите на «Merge».
Подробнее о правильной работе с GitFlow можно прочитать здесь:
Модель ветвления Gitflow