Merge Request и Pull Request, в чем разница?

Pull Request (относится к Open Source продуктам, на открытой платформе типа GitHub).
-> Я вот тут ваш продукт усовершенствовал, заберите-ка то, чего я наделал.

Merge Request (внутри компании, на закрытой платформе типа GitLab).
-> Я вот сделал правки, хочу свою ветку залить к вам в основную (master / main).

#git

GitHub / Bitbucket / GitLab в чем разница?

Все это +- одно и тоже, но есть небольшие различия.

GitHub - Open Source инструмент, есть так же закрытые репозитории, но в основном стал популярен из-за Open Source проектов.

Bitbucket - очень редко используется для Open Source, и часто для закрытых проектов, используется разными закрытыми компаниями вместе с Jira.

GitLab - тоже самое, есть CI/CD, многие компании берут его и разворачивает у себя в локальной сети для закрытого использования.

Процесс разработки программного обеспечения:
GitHub: Code -> Review.
GitLab: Code -> Review -> Build -> Test -> Plan.
Bitbucket: Code -> Review -> Build -> Test -> Plan.

#git

Права доступа файлов в GIT

Git не сохраняет права доступа файлов. После клонирования права доступа будут установлены в соответствии с umask пользователя.

В Git сохраняется только бит исполнения (x) для файлов. Остальные права доступа (чтение, запись) — нет, они выставляются согласно umask пользователя.

#git

——— НАВИГАЦИЯ ———

GIT: #git
Жвачка: #fun
Ядро: #kernel
Разное: #misc
ПО: #software
Игры: #games
Книги: #books
Люди: #people
Сборка: #build
Утилиты: #utils
Теория: #theory
Debian: #debian
Оболочка: #shell
СПО: #opensource
Память: #memory
Терминал: #terminal
Мои мысли: #thoughts
Безопасность: #security
Информация канала: #info
Конфигурационные файлы: #dotfiles

Кто я: https://xn--r1a.website/krxnotes/246
Откуда берется информация: https://xn--r1a.website/krxnotes/500

Поддержать канал:
2202 2036 6907 4603

Спасибо, что читаете!

Максимальный размер файла/репозитория на GitHub и немного про git-lfs

GitHub рекомендует, чтобы размер отдельных файлов в репозитории не превышал 50 МБ. Если файл больше этого размера, вы получите предупреждение. Для оптимальной производительности желательно, чтобы весь репозиторий был меньше 1-5 ГБ. Это помогает поддерживать высокую скорость и эффективность работы с репозиториями на платформе. На других платформах GitLab, Bitbucket +- тоже самое.

Если вам нужно хранить более крупные файлы, можно использовать Git Large File Storage (Git LFS), который имеет отдельные ограничения и квоты.

Установка:

$ apt-get install -y git-lfs

Инициализация Git LFS в репозитории:

$ git lfs install

Отследить тяжелый файл с помощью Git LFS (например, result.gif превышает 50 МБ):

$ git lfs track "result.gif"

Это создаст или обновит файл .gitattributes с информацией о том, что result.gif должен управляться через LFS.

Затем добавить изменения в Git:

$ git add .gitattributes result.gif
$ git commit -m "Add result.gif with Git LFS"

Отправить изменения:

$ git push

Эти шаги помогут вам эффективно управлять большими файлами в вашем репозитории, используя возможности Git LFS.

Важно понимать, что у Git LFS тоже есть лимит. В бесплатном тарифе пользователь получает 1 ГБ. Повышение = деньги.

#git

git-format-patch

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

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

Например, создать патч из последнего коммита:

$ cd my-git-project/
$ git format-patch HEAD~1

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

Создать три патча из трех последних коммитов:

$ git format-patch HEAD~3

#git

Аббревиатуры

В процессе работы с PL/MR на Git платформах часто используются сокращения, которые делают общение более быстрым и понятным:

- PTAL (Please Take A Look): Привлекает внимание к задаче или изменениям для получения комментариев или одобрения. Используйте, чтобы попросить коллегу взглянуть на код.

- LGTM (Looks Good To Me): Выражает одобрение изменений. Используйте, чтобы показать, что код вас устраивает и готов к слиянию.

- WIP (Work In Progress): Указывает, что работа над задачей ещё не завершена. Это предупреждение для ревьюеров, чтобы они не тратили время на детальный обзор, пока код не будет готов.

- NIT (Nitpick): Применяется для указания на несущественные замечания или предложения по улучшению кода, которые не являются обязательными для исправления.

- FYI (For Your Information): Используется, чтобы предоставить информацию без необходимости немедленного действия. Обычно применяется, чтобы держать команду в курсе изменений или решений.

- RFC (Request For Comments): Используется, чтобы попросить мнения или предложения по задаче или конкретному решению. Это приглашение к обсуждению, особенно если есть сомнения в выборе подхода.

Эти аббревиатуры помогут сделать ваше взаимодействие в команде более эффективным!

#git #misc

GitHub требует включения 2FA

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

Что такое двухфакторная аутентификация 2FA?

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

1. Что-то, что вы знаете: ваш пароль.
2. Что-то, что у вас есть: например, смартфон или аппаратный ключ безопасности.

Почему GitHub требует 2FA?

1. Улучшенная безопасность: Защита от взлома учетной записи даже в случае утечки пароля.
2. Защита репозиториев: Многие проекты на GitHub являются открытыми и могут быть уязвимы к атакам, если учётные данные будут украдены.
3. Соответствие лучшим практикам: Ведущие платформы стремятся к повышению уровня безопасности пользователей.

В течение 45 дней необходимо включить двухфакторную аутентификацию, иначе ваш аккаунт может быть ограничен или заблокирован. Это значит, что вы не сможете создавать репозитории или делать коммиты, пока не активируете 2FA. Лично мне уже пришло письмо на эту тему. Установил на смартфон Authy и подключил 2FA к GitHub.

> Habr

#git #misc

Подписание тегов и коммитов

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

1. Сгенерировать GPG ключ:

$ gpg --full-generate-key

2. Экспортировать ключ:

$ gpg --export --armor <Key ID>

3. В GitLab/GitHub:
Settings -> GPG Keys
Добавить экспортируемый ключ.

4. Прописать:

[user]
  email = example@gmail.com
  name = Ivan Ivanov
  signingkey = <Key ID>

[commit]
  gpgSign = true

Коммиты будут автоматически подписываться, а для тегов можно использовать:

$ git tag -s <new-tag>

В истории коммитов в веб-версии можно будет увидеть значок Verified

#git #security

Git по умолчанию не отслеживает пустые папки

Чтобы добавить пустую папку:

$ touch dir/.gitkeep
$ git add dir/
$ git commit -m "add empty 'dir' folder"

Так git будет сохранять папку через наличие файла .gitkeep

#git

Что такое upstream?

Процесс клонирования — это создание собственного репозитория (Б) на основе существующего (А) с целью добавить к продукту какие-то собственные изменения. Это называется fork (клонирование).

Так вот, (Б) — это форк/клон, а (А) — это upstream.

Создатель форка может быть никак не связан с создателями проекта и обычно может вносить изменения в форк, но не в upstream. В upstream он может только предлагать изменения.

Поддержкой upstream занимаются мейнтейнеры (сопровождающие) проекта. Их версия является "канонической", и все изменения, которые они принимают, обычно в конечном счёте попадают в форки, которые от них зависят. В этом смысле они "выше по течению": те изменения, что они принимают, "растекаются вниз" по форкам. Отсюда и название.

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

#git

git-cherry-pick

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

Для чего используется:
• Чтобы перенести один нужный коммит без merge всей ветки.
• Чтобы быстро забрать фикс или изменение из другой ветки.
• Чтобы исправить баги в релизной ветке, не таща лишнюю историю.

-> Как использовать
(перед этим нужно найти коммит, который нужно влить в ветку)

Переход в нужную ветку:

$ git checkout <branch>

Применить нужный коммит по его хэшу:

$ git cherry-pick <hash>

Отправить результат в репозиторий:

$ git push

Грубо говоря: cherry-pick — это "взять точечно один коммит и вставить его сюда".

#git

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

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

* Локальные системы контроля версий
* Централизованные системы контроля версий (CVS, SVN)
* Распределенные системы контроля версий (GIT)

Локальные системы контроля версий
Работают на одном компьютере и хранят историю изменений только локально. Примеры — простые инструменты, сохраняющие разницы файлов. Подход удобен для одиночной работы, но неудобен при командной разработке.

Централизованные системы контроля версий (CVS, SVN)
Централизованные системы контроля версий используют один главный сервер, на котором хранится весь репозиторий и вся история изменений, а разработчики получают только рабочие копии файлов и выполняют все операции — такие как коммиты, обновления или просмотр истории — через этот сервер. Такой подход упрощает администрирование и обеспечивает единое место управления проектом, но делает работу полностью зависимой от доступности сервера: без подключения разработчик не может ни сохранить свои изменения, ни получить новые.

Распределённые системы контроля версий (GIT)
Распределённые системы контроля версий дают каждому разработчику полный клон репозитория со всей историей, что позволяет выполнять коммиты, создавать ветки, экспериментировать и просматривать историю полностью локально, без доступа к сети. Обмен изменениями происходит только при необходимости, через push и pull, а отсутствие единого центра делает систему устойчивой: даже если удалённый сервер недоступен, работа продолжается, а множество локальных копий значительно упрощают параллельную и командную разработку.

#git #theory