Comments 30
.
Конфликты решаются в отдельном коммите или как?
Не правда же. В NGINX патч по описанным рецептам не примут. Значит не в любой проект.
Всегда казался странным коммит лог: Add вместо Added. Патч, что делает? Добавляет, а не добавить.
Можно представить, что выполнил такую задачу/todo и поэтому так и записываешь: "add beautiful button", например. Так менее странным кажется?
Неа, не кажется. Я вот тоже не понимаю, почему во всяких whatsnew пишут нормальным человеческим языком ("что сделано"), а в коммитах вот так вот (что сделать). Буквы экономят?
Есть мнение, что это наследие Линуса, для которого английский не родной. Так просто повелось.
Лично для меня между Add и Added разницы нет. Самое главное, чтобы не нужно было каждый раз думать, в каком же времени употребить глагол, так как необходимость любого усилия мозга подталкивает забить и написать "bugfix".
Чаще мне кажется все-таки "Add" пишут.
Дело не в Линусе (и с образованием у него всё хорошо), а в том, как git используется в ядре. А используется он чтобы автоматизировать работу с патчами на списке рассылки, где заголовок патча — это заголовок треда. На списке рассылки обсуждаются патчи, которые ещё не применены — поэтому завершённая форма глагола в заголовке несколько неестественна. Обсуждается предложение изменить ядро таким-то образом, и заголовок патча это отражает.
Это пошло не от Линуса и всего прочего. Пишут "Add" в повелительно наклонении именно потому, что когда мейнтейнер принимает патч (или письмо с патчем), а в более простых случаях принимает Merge request, то сообщение коммита говорит "добавить кнопку" и мейнтейнер делает выбор yes/no. То есть коммит говорит, какое действие он сделает при применении. Об этом ещё в Pro Git Book написано и много чего другого.
Посмотрел список рассылки nginx - вроде бы все стандартно, чем их правила принципиально от описанного в статье отличаются, кроме того, что у них mercurial?
Я думаю дело в том, что коммит это по-русски "обещание/обязательство"
Итого получается:
Commit #1: Added API for password change — обещание добавил АПИ для смены пароля
Commit #2: Add API for password change — обещание добавить АПИ для смены пароля
А на английском где-то читал, что good rule of thumb это добавлять going to:
(this) commit (is going to) "Add API for password change"
Я что-то путаю, или на бранче, например, feature-1234
git fetch && git merge origin/master
И
git pull origin master
Приведут feature-1234 к одному и тому же состоянию?
Можно сделать настройку git config --global pull.rebase true и тогда будет git pull через rebase работать.
Основная проблема в том, что git pull делает какие-то действия скрытно и начинающие бывает присылают какую-то жесть вообще, а на вопрос, откуда это взялось отвечают - да я только сделал git pull.
Если явно делают git merge, то как-то более ответственно что-ли подходят в этому делу.
а что не так с "Implement API for password change", если это атомарная и небольшая реализация?
Там 2 коммита подряд:
Small fix to that API
Implement API for password change
И "small fix to that API" как бы ссылается на предыдущий коммит, в будущем они могут как-то перемешаться в истории, и будет непонятно, к чему относится "that API"
Я вот такое представить себе затрудняюсь.
Например так. Решили откатить все недавние изменения, связанные с паролями. Грепом нашли нужные коммиты и откатили только их. Коммит с фиксом не найдётся.
И хорошо ещё, если откатить не получится из-за конфликтов. Хуже - если откатится только часть и никто об этом не узнает.
Так а как коммиты-то перемешиваются, если в истории будет
* Revert "Implement API for password change"
...
* Small fix to that API
* Implement API for password changeУ вас немного другая ситуация, когда откат «Implement API for password change» без «Small fix to that API» приводит к неправильному поведению. На эти грабли также легко наступить, если эти два коммита разделены во времени — когда «Small fix to that API» был добавлен через неделю-другую, потому что проблему обнаружили только со временем.
Коля сделал сначал "Add API", запушил изменения. Вася взял его ветку и сделал поверх пару своих коммитов. После этого Коля добавил коммит "Fix that API", но вмержили в мастер сначала Васину ветку.
Еще представьте, что "fix that api" вносит изменения в файл util.c, а "Add API" менял только api.c. Тогда при просмотре изменений по файлу util.c будет видно только коммит "Fix that API".
"Implement" длиннее "Add"
Вообще есть 2 способа добавить свежие изменения из mainstream в вашу ветку:
Rebase —…
Merge —…
А как же cherry-pick?
Правильное использование merge:
git fetch # скачиваем изменения с сервера
# надо находиться в ветке, которую вы хотите обновить
# вместо origin/master нужно вписать вашу mainstream ветку
git merge origin/master
# далее, если возник конфликт
git add file-with-conflict.go
git commitПоследней командой лучше делать не `git commit`, а
git merge --continueИначе гит не увидит откуда был merge.
Ещё есть хороший стандарт Conventional Commits и ориентированные на него разные тулзы для автоматического версионирования и создания логов изменений.
Мерджить же, на мой взгляд, лучше всё таки ребэйсом, чтобы коммиты из одной таски шли друг за другом, а не где попало. История проекта должна быть читабельной.
По поводу наименования: conventionalcommits.org и никак иначе
Очень нужный кейс, когда сделана большая фича в одной бранче на много, порядка 1000 строк изменений и нужно составить несколько MR в основную ветку, чтобы удобно было ревьювить. Как это лучше сделать? Буду очень признателен, если направите.
Как оформить серию коммитов Git, чтобы её приняли в любой проект