Git

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

Ветвление и слияние

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

  • Беспроблемное переключение контекста. Создайте ветку, чтобы опробовать идею, зафиксируйте несколько раз, вернитесь туда, откуда вы разветвились, примените патч, вернитесь туда, где вы экспериментируете, и объедините его.
  • Кодовые строки на основе ролей. Имейте ветку, которая всегда содержит только то, что идет в производство, другую, в которую вы объединяете работу для тестирования, и несколько более мелких веток для повседневной работы.
  • Функциональный рабочий процесс. Создавайте новые ветки для каждой новой функции, над которой вы работаете, чтобы вы могли легко переключаться между ними, а затем удаляйте каждую ветку, когда эта функция будет объединена с вашей основной строкой.
  • Одноразовые эксперименты. Создайте ветку, чтобы поэкспериментировать, осознать, что она не будет работать, и просто удалите ее - отказавшись от работы - пока никто ее не увидит (даже если вы тем временем подтолкнули другие ветки).

Branches

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

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

Маленький и быстрый

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

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

Контрольный показатель

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

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

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

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

Распределённый

Одна из самых приятных особенностей любой распределенной SCM, включая Git, - это то, что она распределенная. Это означает, что вместо «проверки» текущей части исходного кода вы выполняете «клонирование» всего репозитория.

Множественные резервные копии

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

Любой рабочий процесс

Благодаря распределенной природе Git и превосходной системе ветвления можно относительно легко реализовать почти бесконечное количество рабочих процессов.

Рабочий процесс в стиле Subversion

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

Workflow A

Рабочий процесс диспетчера интеграции

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

Workflow B

Рабочий процесс диктатора и лейтенантов

Для более масштабных проектов часто эффективен рабочий процесс разработки, подобный процессу ядра Linux. В этой модели некоторые люди («лейтенанты») отвечают за определенную подсистему проекта и объединяют все изменения, связанные с этой подсистемой. Другой интегратор («диктатор») может получать изменения только от своих лейтенантов, а затем отправлять их в «благословенный» репозиторий, из которого все затем клонируют снова.

Workflow C

Гарантия данных

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

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

Плацдарм

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

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

 

Index 1

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

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

Index 2

Бесплатно и с открытым исходным кодом

Git выпущен под лицензией GNU General Public License версии 2.0, которая является лицензией с открытым исходным кодом. Проект Git решил использовать GPLv2, чтобы гарантировать вам свободу обмена и изменения бесплатного программного обеспечения - чтобы убедиться, что программное обеспечение является бесплатным для всех его пользователей.

Учебные курсы по Git

  1. Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. - Учебник по Git 
  2. Основы Git
  3. Hexlet - Введение в Git

  4. Git и GitHub Курс Для Новичков

  5. YouTube

Использование Git

git hist

git status

git add .

git log

git commit -m "Описание изменения"

git push

  • Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. + Token1

Восстановление файла в предыдущее состояние

git log

git checkout <обозначение коммита> <имя файла>

 

Отказ от использования паролей

В июле 2020 года мы объявили о своем намерении требовать использования аутентификации на основе токенов (например, токен личного доступа, OAuth или токен установки приложения GitHub) для всех аутентифицированных операций Git. С 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git на GitHub.com.

Затронутые рабочие процессы

  • Доступ к Git из командной строки

Настольные приложения, использующие Git (GitHub Desktop не затрагивается) Любые приложения/сервисы, которые получают доступ к репозиториям Git на GitHub.com напрямую, используя ваш пароль. Это изменение не коснется следующих клиентов: Если для вашей учетной записи включена двухфакторная аутентификация, вам уже необходимо использовать аутентификацию на основе токена или SSH. Если вы используете GitHub Enterprise Server, мы не объявляли о каких-либо изменениях в нашем локальном предложении. Если вы поддерживаете приложение GitHub, приложения GitHub не поддерживают аутентификацию по паролю.

Мы описали нашу мотивацию, когда объявили об аналогичных изменениях в аутентификации с помощью API, следующим образом:

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

Начиная с 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git и будем требовать использования аутентификации на основе токенов, например токена личного доступа (для разработчиков) или токена установки приложения OAuth или GitHub (для интеграторов). для всех аутентифицированных операций Git на GitHub.com. Вы также можете продолжать использовать SSH-ключи там, где вам удобно.

Токены предлагают ряд преимуществ в плане безопасности по сравнению с аутентификацией на основе пароля:

  • Уникальные — токены специфичны для GitHub и могут генерироваться для каждого использования или для каждого устройства.
  • Возможность отзыва — токены могут быть отозваны по отдельности в любое время без необходимости обновления незатронутых учетных данных.
  • Ограниченный — токены могут иметь узкую область действия, чтобы разрешить только доступ, необходимый для варианта использования.
  • Случайный выбор — токены не подвержены типам словаря или попыткам грубой силы, которые могут быть у более простых паролей, которые вам нужно помнить или регулярно вводить.

Что вам нужно сделать сегодня

  • Для разработчиков: если вы используете пароль для аутентификации операций Git с GitHub.com сегодня, вы должны начать использовать личный токен доступа через HTTPS (рекомендуется) или ключ SSH до 13 августа 2021 года, чтобы избежать сбоев. Если вы получаете предупреждение о том, что используете устаревшую стороннюю интеграцию, вам следует обновить клиент до последней версии.
  • Для интеграторов: вы должны аутентифицировать интеграцию с помощью потоков авторизации в Интернете или на устройстве до 13 августа 2021 года, чтобы избежать сбоев.

Дополнительные сведения см. в разделе Авторизация приложений OAuth и объявление в блоге разработчиков.

Включение двухфакторной аутентификации

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

Браунауты

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

График

Сегодня — если вы используете пароли для аутентификации операций Git с GitHub.com сегодня, вы скоро получите электронное письмо с призывом обновить метод аутентификации или сторонний клиент.

  • 30 июня и 28 июля 2021 г. — аутентификация с помощью токена (или ключа SSH) будет временно требоваться для всех операций Git, чтобы побудить затронутых клиентов обновить свой метод аутентификации (см. ниже).
  • 13 августа 2021 г. — для всех аутентифицированных операций Git потребуется аутентификация с помощью токена (или ключа SSH).

 

Добавить комментарий