Собеседовал "Архитектора" как-то, дак при разговоре он сам себя запутал между 3х понятий pull, push и commit. Такое неприемлемо вообще. Я понимаю, если ты пол жизни использовал svn, но там даже абревиатура отпугнула его, даже попробовать ответить на вопрос.
Про gitlabflow не могу ничего сказать, а про отличия gitflow от githubflow могу сказать, что отличия конечно есть. Первый более спринтовый и подходит для больших команд и нечастых релизов. Второй больше потоковый, фичу сделал, фичу выкатил. Оба подхода хороши, но надо понимать какой лучше для конкретного проекта.
Пул реквесты хорошая штука. Но в идеале было бы хорошо, если бы все члены команды читали все реквесты. Тогда они будут еще полезнее. Но такая культура редка.
Что должно быть у человека в голове, который пришел на собеседование по гиту, у меня таких и не было никогда)) я написал еще в начале, что это некоего рода шпаргалка и направление куда мыслить.
Если тебя спросят про Муму и Герасима в лодке, ты будешь описывать биологический процесс, как он топил человека, или все же характер героев и психологическую проблему произведения.
Про чувствительную информацию да, согласен. Что и как делать?
Если так, то да) приятно пообщаться с грамотным человеком.
Fetch забирает со всех веток
Оба варианта хороши)) просто указал особенность.
Оба варианта хороши)) просто указал особенность.
Я из сишарповой тусовки ?
Я про изучение кода, а для оценки хватит и 2х
Я обычно использую lazygit и nvim в разработке, процентах в 80% задач.
Очень классные темы поднял, но статья была помечена как простая ?
Буду очень рад почитать о ваших практиках решения заданных вами гит задач.
Для работы может быть и не нужно. Но мы сейчас живем в таком мире где пройти собеседование сложнее, чем сама работа. ?
Собеседовал "Архитектора" как-то, дак при разговоре он сам себя запутал между 3х понятий pull, push и commit. Такое неприемлемо вообще. Я понимаю, если ты пол жизни использовал svn, но там даже абревиатура отпугнула его, даже попробовать ответить на вопрос.
Я не верю вам.
Про gitlabflow не могу ничего сказать, а про отличия gitflow от githubflow могу сказать, что отличия конечно есть. Первый более спринтовый и подходит для больших команд и нечастых релизов. Второй больше потоковый, фичу сделал, фичу выкатил. Оба подхода хороши, но надо понимать какой лучше для конкретного проекта.
Пул реквесты хорошая штука. Но в идеале было бы хорошо, если бы все члены команды читали все реквесты. Тогда они будут еще полезнее. Но такая культура редка.
Собеседование по командам git и не бывает, не надо понимать все буквально. Но пару тройку вопросов все равно зададут. Нет?
Да, это в идеальном мире, когда программист осознанно подходит к разработке. Я такое не часто встречаю.
Да, конечно. Согласен с вами. Вы озвучили хорошие мысли, но это мало кто понимает на начальных стадиях. Сначала база так сказать.
Собаку*
Благодарю, многим будет полезно. Согласен с вами, любую технологию, софт и тд стоит начинать с официальной документации - это тру стори))
Что должно быть у человека в голове, который пришел на собеседование по гиту, у меня таких и не было никогда)) я написал еще в начале, что это некоего рода шпаргалка и направление куда мыслить.
Если тебя спросят про Муму и Герасима в лодке, ты будешь описывать биологический процесс, как он топил человека, или все же характер героев и психологическую проблему произведения.