Комментарии 61
очень полезная шпаргалка. ответил на все вопросы кроме последнего, но, блин, я мозг сломал, что удаленный репозиторий это не deleted а remote.
имхо если на собеседовании спрашивают рандомные вопросы из документации - смысла туда идти нет
Это всё фигня. Самое важное - это научить людей во время разрешения конфликтов в IDE применять изменения с нужной стороны. У нас был чел на проекте, месяца три работал, так он абсолютно всегда применял изменения не с той стороны. Люди с ума сходили, вроде сделал фичу, тестер протестил, задеплоили, а клиент говорит, что не работает. Стягиваешь последний develop, думаешь, ща поставлю брейкпоинт в своём коде и буду дебажить, а твоего кода просто нет!!!
Вопрос больше к лидам? Почему пул реквесты так смотрят ?
Это они расслабились после длительной работы с адекватными разрабами))
Бывает) на такие моменты, начинаешь думать, что регламенты на комит и права на слитие не пустое место. Надо дрессировать джунов порядком..
У ревью есть много других бонусов.
Каких например, буду рад узнать? Можете подробнее раскрыть тему?
Первое, это обмен опытом. Даже сеньор от джуна иногда может подсмотреть что-то новое. Второе, это то, что в итоге ревьювер будет лучше знать, как устроен весь проект, а не только та часть, что он написал сам.
Что должно быть в голове у собеседующего, чтобы начать гонять по командам git? Уважаемый, у тебя всего один час на то, чтобы дать ответ на вопрос "что за человек перед тобой и сможет ли он принести прибыль организации?" И ты не нашел ничего лучше, чем спрашивать его про команды git? Да что с тобой не так!? Ты хочешь понять действительно ли перед тобой профессионал и ты для этого решил проверить насколько человек силен в зубрежке!?
Что должно быть у человека в голове, который пришел на собеседование по гиту, у меня таких и не было никогда)) я написал еще в начале, что это некоего рода шпаргалка и направление куда мыслить.
Если тебя спросят про Муму и Герасима в лодке, ты будешь описывать биологический процесс, как он топил человека, или все же характер героев и психологическую проблему произведения.
Gitflow это нечто другое. То что вы описали больше похоже на gitlabflow.
Они все похожи, отличий на самом деле мало.
Но эти отличия важны.
Про gitlabflow не могу ничего сказать, а про отличия gitflow от githubflow могу сказать, что отличия конечно есть. Первый более спринтовый и подходит для больших команд и нечастых релизов. Второй больше потоковый, фичу сделал, фичу выкатил. Оба подхода хороши, но надо понимать какой лучше для конкретного проекта.
Очень абстрактный ответ. Частично правильный. Киллер фича gitflow в том что можно поддерживать и обновлять сразу много версий продукта. Хорошо работает для библиотек и десктоп програм, например ядра Линукс. Но за это вы платите повышенной сложностью. В общем не рекомендуется использовать.
Единственный раз когда я с этим сталкивался, это было в требованиях на разработку проекта. Ни заказчик ни разработчики проекта не знали что это такое и использовали gitlabflow, этого термина они тоже не знали.
местами как-то очень категорично
Как удалить файл/папку из репозитория?
Имхо, следует отметить, что папка/файл останется в истории гита. Если целью стоит уменьшить вес .git, то нужно переписывать историю.
За что отвечает команда git merge? Загрязняет ветку мерж комитами ...
Необязательно. Допустим, переключился я в новую ветку для работы, сделал несколько коммитов, и увидел, что это хорошо. Тогда флаг --ff-only перенесёт эти коммиты в основную ветку без коммита слияния.
https://git-scm.com/book/ru/v2
https://git-scm.com/book/en/v2
Вот самая лучшая шпаргалка
Мой стаж в IT больше 25 лет, от разраба до архитектора, не помню ни одной команды git, держу под рукой шпаргалку, мне её хватает. Если пригласят на собеседование по командам git сразу пошлю умника-неадеквата подальше.
Собеседование по командам git и не бывает, не надо понимать все буквально. Но пару тройку вопросов все равно зададут. Нет?
Нет.
Я не верю вам.
И правильно делаете. Мне доводилось собеседовать людей, которые про git почти ничего не знали. "Вроде, commit там был".
Собеседовал "Архитектора" как-то, дак при разговоре он сам себя запутал между 3х понятий pull, push и commit. Такое неприемлемо вообще. Я понимаю, если ты пол жизни использовал svn, но там даже абревиатура отпугнула его, даже попробовать ответить на вопрос.
Зачем на собеседовании спрашивать о том, что легко осваивается в процессе работы? Это такая проверка на culture fit, только что бы такие же фанатики прошли? За около 20 лет использования git, не могу припомнить, что бы я использовал что-то, кроме init, commit, push, pull, merge, branch, diff, blame, tag и checkout. Притом, в самой их простейшей форме, без каких либо хитрых ключей. Изредка что-то нужно сделать необычное, так смотрю в документации и поисковиках - как, делаю и забываю.
Для примерного определения квалификации, зарплаты, задач, которые можно прямо сразу предложить, и потенциальных проблем, которые, возможно, придётся решать вне плана.
Вот тут очень старая история на близкую тему. Там, правда, главные герои друг друга стоят...
Я работал со студентами, они справились с созданием пул-реквестов на гитхабе. В этом плане что гит, что багтрекер, это инструменты с низким уровнем начала использования.
Я работаю в большой компании и в том числе отвечаю на вопросы других разработчиков про гит. Большинство вопросов в статье им просто не нужно знать для работы.
Вопросы все больше у вас "базовые", а в разработке случаются и вопросы чуточку посложнее.
Как посмотреть содержимое и откатить merge-commit?
Как узнать в какие ветки попал коммит (по хэшу)?
Как склеить не два рядом стоящих коммита, а скажем отстоящие друг от друга на 10 коммитов?
Как проверить наложится ли ваша ветка с изменениями в другую без конфликтов не сливая ее фактически (ну или откатив слияние)?
Как отредактировать измененные в коммите файлы (добавить, удалить, переименовать)?
Если интересуетесь Python, неплохое видео про внутрянку гита https://m.youtube.com/watch?v=xvzo_nV9PjU&pp=ygUPamFtZXMgcG93ZWwgZ2l0
Практической пользы я в нём не нашел, просто интересно.
Еще замечание/предложение по следам комментариев. Нет вопросов про .gitignore и про то, что делать, чтобы в коммит не попала чувствительная информация, типа access token.
Про чувствительную информацию да, согласен. Что и как делать?
Что и как делать?
Если Вы меня спрашиваете, то я бы все пароли, ключи и т.п. вынес в отдельный файл settings.py и прописал его в .gitignore
Альтернативой могут быть просто текстовые конфиги или переменные окружения.
Если уж так получилось, что что-то протекло, то во-первых, отозвать доступ (перегенерировать ключ или токен, сменить пароль и т.п., конкретное действие зависит от характера утёкших данных), во-вторых, пройтись по всему репозиторию BFG-repo-cleaner-ом
За что отвечает команда git merge? Загрязняет ветку мерж комитами ...
Как-то слишком категорично. Если вы сторонник ребейза, подскажите как правильно вести разработку, когда в команде разработчики пилят отдельные фичи (порой пересекающиеся), а релиз собирается под конец месяца из набора готовых фичей, причем релиз вполне может и пересобираться по желанию заказчика?
За что отвечает команда git merge?
Загрязняет ветку мерж комитами, но не изменяет историю комитов.
То есть предназначение git merge - загрязнить мерж коммитами?
Ну ОК, буду знать...
За что отвечает команда git merge?
Загрязняет ветку мерж комитами, но не изменяет историю комитов.
Гит мердж не всегда создает мердж коммиты. И вызывается он гораздо чаще.
В чем заключается разница между git pull и git fetch?
Извлекает все изменения текущей ветки с сервера
git pull
Комманда git fetch извлекает все изменения текущей ветки с сервера. Pull алиас к fetch + merge (если в конфиге прописана свзять между текущей веткой и веткой в remote репозитории).
При этом если мердж не fast-forward, то он не выполнется.
Git: Очередной лист Вопросов и Ответов