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
Python: #python
Теория: #theory
Debian: #debian
Новости: #news
Оболочка: #shell
Память: #memory
СПО: #opensource
Терминал: #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