Переработать git на jun-3 #302
Comments
|
Ага, я в целом согласен. Там где на проекте активно ребейз используется и тд, то они индивидуально могут залететь в топик мидловский и ресурсы подсмотреть, но у нас таких немного |
мой опыт может отличаться от опыта других людей, тут интересно, что другие скажут, но мне в своё время понимание этих вещей сильно развязало руки и придало уверенности в работе с гитом, потому что спала какая-то магическая пелена и я начал более точно понимать команды, которые я использую в ежедневной работе, в целом не считаю это каким-то рокет саенсом, предлагаю оставить как есть
предлагаю оставить как есть
согласен, не юзабельно практически, предлагаю выпилить
гуглится в 5 секунд, не вижу смысла в карте держать, предлагаю выпилить
ну что такое сквош полезно знать, использовать или нет - вопрос десятый, предлагаю оставить как есть
согласен, в зависимости от проекта флоу отличаться будет, и не джуну его выбирать предлагаю выпилить и ничего не добавлять взамен Итого: я не перечислил только вопрос про ребейз. Потому что всё, что я предлагаю - это выпилить некоторые действительно лишние вопросы. Остальные вопросы я бы оставил на месте, а переносить один ребейз - не очень. |
|
в целом я не думаю, что "гит на миддле" - это вообще норм, потому что какие-то прямо сложные и редкие темы по гиту скорее всего по факту будут тупо мало юзабельны, а вопросам про всякие гит-флоу вообще место в какой-нибудь карте на тимлида, а не на нашем миддле, имхо |
Кстати да, пожалуй, лучше оставить. Единственное, вопрос про пакфайлы хочется детализировать, чтобы человек не тратил на них много времени.
Легко гуглится
Все флоу, которые я знаю, основаны на ветках доработок и интеграционных ветках, куда все сливается в конечном счете. Про это я и хотел спросить, потому что это точно пригодится с любым флоу. Плюс, хочется добавить вопросы, чтобы предостеречь людей от распространенных ошибок:
Тут можно возразить, что такие косяки найдутся на ревью, однако ошибку легче предотвратить, чем исправлять, особенно если доработка большая. А еще не надо переоценивать эффективность ревью :). Ревьюер может не заметить подозрительную правку, которая просочилась в мерже из ветки, которую мержить было нельзя.
А разве мержит только тимлид? На большом проекте может быть несколько человек с правом мержа. Даже если не мержишь, на определенном уровне желательно понимать, какие есть ветки в проекте, чтобы разобраться в истории гита - когда вышла такая-то доработка, вышел ли в прод такой-то багфикс и т.п. |
|
Согласен с Антоном по поводу реверта коммита. Мне кажется задавать вопрос нужно от обратного, аля "Как поступить если изменения в коммите нужно убрать с ветки?". Возможно ее и стоит оставить на джуне, но так чтобы не сильно упарываться в детали. Достаточно ответить на вопрос какие последствия приведут, если ревертнуть изменения не той командой. |
согласен
согласен оставить и дополнить
Если ты хочешь составить список абстрактных вопросов, которые под все флоу подойдут (ну или, по крайней мере, почти под все), у меня вопрос возникает: как к такой теме готовиться? я не вижу другого пути, кроме как изучить n конкретных гит флоу и оттуда вычленить какие-то абстрактные общие признаки, иного пути нет. Для меня это выглядит как перегрузка карты, потому что нюансы работы с гитом на конкретном проекте обговариваются в любом случае, а знать кучу гитфлоу джуниору не нужно точно, а на миддле это не маст хэв в карте, имхо
не думаю, что это стоит добавлять, потому что тут каждый конкретный случай нажо смотреть и думать, исходя из ситуации, можно ли или нельзя так делать; нельзя в общем случае четко сказать, можно ли конкретную фичеветку мержить в другую сейчас или нет
сложно представить, чтобы кто-то таким начал заниматься) на моём опыте такого не было ниразу, тут надо думаю еще у людей спрашивать, если ты прямо иначе считаешь
я говорил не о том, что только тимлид мержит, понимает, какие ветки есть впроекте, как устроен флоу на нём и так далее я говорил о том, что знать конкретные гитфлоу, как организовать работу с гитом на конкретном проекте в конкретных условиях, вот это вот всё - это околоорганизационная, инфраструктурная работа, которая точно не на джуна, возможно на миддла (что именно на тимлида это повесил - в целом спорно, да) |
Я поработал на двух проектах (в metalamp), где ничего не обговаривалось. Подразумевается, что надо делать как все. Проекты своеобразные, конечно, но это реальная ситуация :).
Список вопросов, которые точно подойдут везде:
Как готовиться: изучить какой-нибудь простой флоу с минимумом лишнего, где только ветка master и ветки доработок. Кажется, github flow таков. Только не git flow с его загонами. Конкретный флоу неважен. Зная один, человек быстро разберется в остальных. Тем более, если он только пилит доработки, ему не надо разбираться в сортах мастеров и стейджингов, а если надо - спросит. Я не уверен, что эти вопросы нужны. Мне кажется, нужны, но настаивать не буду - на самом деле, они несложные и учатся по ходу работы. Но, может быть, мне так кажется из-за опыта, а у кого-то будет другое мнение. Подождем отзывов. |
Имхо, такое на третьем джуне уже нет смысла спрашивать, разве что на 1 джуна, но это уже в новом ишью надо обсуждать. Единственное, последний вопрос не знаю (а надо?).
Это узкое место самих проектов, карта здесь не при чём. filter-branch я бы хотел оставить. изучается за 15 мин, но знание, что такая фича есть может быть сильно полезно в будущем. Ребэйз тоже хотел бы оставить, если у нас топика на мидле не будет. Но я и не вижу смысла в ещё одном топике. А вообще, я думаю, ничего плохого, что в карте будет что-то, что сейчас не очень надо, но может пригодиться потом. |
мне кажется, что это организационный косяк на проекте, что если процессы нормально настроены, то объяснение гит флоу - это часть онбординга нового человека, и если на проекте с этим все нормально, то все необходимые нюансы должны обговариваться это первый кейс: гит флоу есть, онбординга нет второй кейс: нету гит флоу просто; это тоже, как я думаю, организационный косяк, который, как и в первом случае, должен фикситься в этой плоскости, а не картой так что согласен с Олегом "Это узкое место самих проектов, карта здесь не при чём." по поводу вопросов, согласен с Олегом, что дальше 1 уровня это не имеет смысла спрашивать правда на 1 тоже не считаю это нужным, потому что это на практике выясняется довольно быстро и легко
ответ на этот вопрос, что "это должна быть интеграционная ветка для активной разработки или релиза", по идее выясняется всеми новичками на первом же их проекте, а дальше - это уже здравый смысл, не сильно понимаю, зачем на это время на собесе тратить, т.к. абстрактный ответ - очень простой и его знают почти все, я думаю, кто хоть на 1 проекте работал, а конкретного ответа нету, т.к. везде по-разному
то же самое: очевидный для всех людей с опытом >=1 проекта ответ
у меня тоже сомнения, как и у Олега, зачем это надо, ну т.е. при необходимости это можно найти, а так, это не такая база, которая нужна прямо в карте, как по мне
я полностью согласен с тем, что это все по ходу работы учится, и причем довольно легко, а добавление этого в карту - это трата времени кучи людей, которые будут это сдавать и принимать а знания эти людьми будут получены независимо от того, есть ли это в карте или нет |
|
Подвожу тогда итоги:
|
|
Тут же голосую за добавление вопросов:
Плюс, мне показалось, что ресурс из Atlassian недостаточно подробный (мне не хватило, чтобы полностью разобраться) и я бы его заменила/или поставила на выбор с Pro GIT с указанием какие главы надо почитать. |
Выше коллеги голосуют за выпиливание вопросов по git workflow. Я бы оставил, но из соображений "чтоб было" - странно иметь здоровый чеклист с вопросами по гиту, в котором ничего нет про воркфлоу. Но они и правда простые и изучаются на проекте. Кстати, ты, как человек, недавно это все изучавший, как считаешь, стоит ли их оставлять в списке? |
|
Я за то, чтобы оставить один простой воркфлоу как пример (гитхаб воркфлоу например), и не смотреть подробно в рамках карты другие флоу. Не хочется, чтобы вопрос в итоге превращался в копание в отличиях разных флоу, чтобы их нужно было запоминать и рассказывать. Нужно обозначить что есть разные флоу, разобрать 1 пример, чтобы было понятно - если встанет вопрос как организовать работу на проекте - человек знал, что надо пойти и почитать поподробнее. |
|
Есть еще один вариант, оставить вопрос и ресурсы на разные флоу, но не просить их пересказывать на сдаче подробно. Вместо этого ознакомиться с ресурсами и проанализировать, как организована работа на текущем проекте, насколько она близка к официальным флоу и хотелось ли бы что-то поменять после прочитанного. Такое рассуждение в стиле сдачи ремесла программиста. |
организовывать работу на проекте - не ответственность джуна, он не должен этим заниматься @olgaklimenko я не вижу других причин это в карте оставлять, если ты не согласна с этим, или с тем, что я выше написал, отпишись) |
|
Согласна, что джун не должен отвечать за это. Мне приходит в голову аргумент, что не на каждый новый проект у нас ставят мидла, тимлида, техлида или еще кого-то, кто был бы ответственнен за это. Но если это учитывать, то третий джун разрастется до необъятных размеров :)) Так что я не против убрать этот вопрос совсем. |
|
Как минимум, надо выпилить из ресурсов статью про gitlab flow, отвратительная статья, автору надо ознакомиться с пирамидой Минто. |
я конечно вангую, но мне кажется, что если мы сейчас N разработчиков опросим, мы найдем очень маленький процент людей, которые юзали/юзают filter-branch |
Возможно. Но я, например, уже успел пропустить кейс, где мог бы ей воспользоваться, но не знал, что так можно) |
|
с Олегом поговорили, пришли к выводу filter-branch не добавлять, если кто-то считает иначе - велком В итоге:
|
|
@olgaklimenko по поводу твоих предложений
вопрос про форс пуш просто? звучит сильно просто, тогда не понятно, зачем это
ну удалять Atlassian я бы не стал прямо, мне он нравится, например как обсудим это, я верхнее сообщение отредактирую, если что, пока эти пункты не стал добавлять) |
ага, я просто не обратила на это внимание при изучении, поэтому предложила добавить. Но вообще и в Atlassian и git-scm это есть в разделе про ребейз (я как-то проглядела просто на Atlassian эту инфу при подготовке), так что можно не добавлять. Про ресурсы: давайте и то и другое положим рядышком на выбор (ок, без указания глав, там и правда не так сложно разобраться). |
а насчёт этого? |
|
отредактировала выше. |
|
@olgaklimenko @kelizarov @antonkalinin-ml @stanislav-az #302 (comment) здесь финальная версия с учетом всех обсуждений, полайкайте, если всё ок, или давайте дообсудим |
Раздумали удалять вопросы про гит воркфлоу? :) Не вижу этого пункта в посте. Мне бы хотелось оставить filter-branch. Пусть она редко нужна и нюансы использования забудутся - ничего, для этого есть git help. Но полезно потратить на нее полчаса, чтобы знать, что такая команда есть и что она может помочь в определенных случаях:
Все это случалось со мной и я успешно использовал filter-branch для исправления ситуации. И, к сожалению, видел случаи, когда люди могли бы использовать filter-branch, если бы знали про него, но они не знали, а потом приходилось разгребать последствия. Это тема немного не для джунов, но у нас нет чеклиста по гиту для мидлов. Велик шанс, что человек так и не узнает про filter-branch. Детально изучать ее не надо, достаточно в ознакомительном режиме почитать одну статью в pro git. |
Не раздумали) 1 пункт в моём сообщении:
По поводу filter branch: моя позиция по поводу вопросов в карте следующая: поскольку знаний, которые разработчику нужны - много, то мы не можем просто всё, что полезно, в эту карту добавлять. В карте должно быть только самое необходимое. Определить, что является "самым необходимым", а что не является, мы объективно не можем, поэтому тут вечно будут какие-то споры типа тех, что сейчас происходит. Я сделал следующее: я обошел лично человек 12 околомиддловых разработчиков и задал им вопрос в духе "юзал ли ты фильтер бренч". Оказалось, что только лишь один Олег использовал фильтер бренч. Остальные - либо не использовали, но слышали, что такое есть, либо даже не слышали, и при этом все прекрасно существовали. Я считаю, что проблемы, которые решает фильтер-бренч, достаточно специфичные, редкие, и отлично гугляться, пруфы:
https://www.rockyourcode.com/fix-wrong-email-address-in-git/#alternative - 2 ссылка в гугле; запрос - git wrong email in commits
https://ao.ms/how-to-split-a-subdirectory-to-a-new-git-repository-and-keep-the-history/ - 1 ссылка в гугле, запрос - git split repository keep history
https://docs.github.com/en/github/managing-large-files/working-with-large-files/removing-files-from-a-repositorys-history - 1 ссылка в гугле, запрос - git remove wrong file from history По перечисленным причинам, я не думаю, что такому вопросу место в карте развития. Аргумент, что "это всего полчаса" не считаю аргументом, потому что вопросов много, и каждые полчаса, или 10 минут, потраченные на один вопрос, прекрасно аккумулируются) То, что кто-то плохо прогуглил, или тупанул, или еще что-то, и пришлось "разгребать последствия", ну да, такое может быть всегда, но не думаю, что это настолько частая ошибка, что стоит из-за этого расширять карту. Мне кажется, что если бы это достаточно часто случалось, это бы заметили. Это моё финальное сообщение в данном топике, как будет приниматься решение - я хз, но мне добавить нечего больше :) |
Вот это прям отличный пример, что filter-branch это специфический случай, которых просто тьма и если все добавлять в карту, то, скорее всего, разработчик никогда не сдаст на грейд :) За выпиливание filter-branch голосую тоже, в остальной диалог не закапывался. Ну а в целом, тема git на 3 джуна мне показалась неплохая и много полезностей вытащил из нее. |
antonkalinin-ml
added
backend
@antonkalinin-ml тут предложил разделить гит jun-3 и часть перенести на миддла. Создала отдельное ишью, так как тема shared.
В чеклисте по гиту тоже есть не очень практичные вопросы, которые больше про понимание принципов, или вопросы о редкоиспользуемых командах. Можно их передвинуть на мидла:
merge --squash, если только это не ежедневная операция. Сквошем легко злоупотребить и получить коммит на 20000 строк. С такими коммитами бисект бесполезен, и от истории коммитов толку мало.Что такое Git workflow, какие знаете примеры?- вопрос слишком обширный и неконкретный. Джун не выбирает воркфлоу, он пользуется принятым на проекте. Джун едва ли будет выпускать релиз или поставку, ему не нужно знать тонкости, когда мержить релиз с мастером, откуда отводить хотфикс, где ставить теги и т.п. Я бы включил сюда более конкретные вопросы:The text was updated successfully, but these errors were encountered: