Comments 5
Объёмная статья, но по делу. Есть структура и много каритнок:)
Советуете советы, которых сами же не придерживаетесь (не с заглавной буквы).
Сообщение в императивном наклонении - для человека ли оно? (не лучший способ обращения к коллеге: "добавь..."). Это скорее приказ гиту - сделай то, что мне надо.
А совет писать исходный код в комментарии к коммиту - кажется совсем за гранью понимания.
Про сообщение коммита тут вообще каша получилась.
50 символов относятся только к первой строке сообщения коммита - она заголовок этого сообщения. После которой должна быть пустая, а потом уже тело сообщения.
О форматах сообщений коммитов лучше почитать классику, а не эту статью:
Как следует писать комментарии к коммитам – отличное описание и обоснование.
Руководство по написанию коммитов – чуть шире и больше охват, но о том же
Про маленькую/большую первую букву - как мне кажется, это вопрос вкуса и использования сообщения коммита. Если из заголовков сообщений потом автоматически делается сообщение для релиза, то маленькие имеют смысл, иначе лучше с большой буквы.
Лично я рекомендую забыть про рекомендацию «Используйте повелительное наклонение». Это круто работает для английского языка, но убого выглядит в русском. Сообщение коммита «Исправь ошибку в отчёте» не может быть нормальным. В русском языке естественно использовать причастия - точнее "краткую форму страдательного причастия прошедшего времени глаголов совершенного вида" («добавлено поле», «исправлено поведение», «удалено изображение», «изменена кнопка» и т.п.). Это лучше читается с логах, чем глагол в прошедшем времени (у которых в русском языке есть еще и лицо с количеством из-за которых сообщения будут то "исправил", то "исправила", то "исправили").
Длина первой строки. Рекомендуемые 50 символов для русского языка это жестоко – никто не сможет адекватно придумывать такие заголовки. Но, Gitlab, например, режет заголовок на 74 символах, поэтому проще сразу ориентировать на этот размер.
Длина последующих строк – рекомендуется 72 символа, но на это можно забить по договорённости с командой. Лучше договоритесь в теле markdown использовать: GitLab и GitHub в MR/PR отлично подхватывают.
Код в комментарии коммита - странная дичь, если это не репозиторий какой-то библиотеки и в комментарии коммита какой-то небольшой пример кода.
В любом случае - договорённости внутри команды важнее любых рекомендаций. Если команда договорилась писать сообщения коммитов определённым образом, то это и надо соблюдать.
Git — это распределённая система управления версиями: есть один сервер, через который разработчики обмениваются кодом. Разработчик копирует (клонирует) проект к себе на локальную машину, делает изменения и сохраняет их на удалённый сервер. При необходимости другие разработчики могут скопировать эти изменения к себе.
Почти всё не так. Git — это распределённая система управления версиями, но это как раз о противоположном. С точки зрения git все репозитории (клоны репозитория) равноправны. Нет выделенного "сервера", есть много репозиторииев, обычно с общей частью истории коммитов. Более того, у git почти нет сервера - это просто утилита командной строки, просто есть несколько протоколов доступа к другим (reference) репозиториям. В самом git не ни аутентификации, ни прав доступа, ни истории pull request - ничего лишнего. Собственно, операция pull request достаточно специфична именно для git и отражает примерно следующее: "Я в своём репозитории сделал вот такие коммиты (с такими-то хешами родительских). Прими их, пожалуйста в свой репозиторий в ветку nnn". Т.е. не вы отправляете коммиты в чужой репозиторий, а просите "владельца" чужого репозитория их принять.
GitHub (но не git!), собственно, оборачивает этот достаточно сложный процесс совместной работы в простые и понятные схемы с "главным сервером" и наворачивает горку удобств (типа аутентификации, авторизации, история дискуссий, поиск и т.д. и т.п.)
Шок контент! В открытый доступ выложены материалы первого спринта курса DevOps от Яндекс практикума. Который состоит из 10 спринтов и дипломного проекта. Стоимость этого удовольствия 120 тысяч. Т.е. информация выше тянет примерно на 10 тысяч.
И да, в требованиях к учащимся этого курса: от 3-х лет опыта в разработке.
Работаем с Git: первые шаги в GitHub