При работе в GitHub можно запретить пушить в мастер, а мердже разрешить через Pull Request только чере Squash & Merge. То есть не важно, что там у разработчика, в мастере будет красивенько.
Да, это правда. Тогда вся статья становится неактуальна, как заметил первый комментатор. Однако как раз в начале подчеркнула, что тут рассмаривается именно кейс, когда коммиты не сквошатся при мердже в мастер. Например, мы с командой обоюдно пришли к этому, нам так удобнее. Поэтому нам эти правила и актуальны :)
Да, хуки - это вообще отлично! С ними все куда проще и приятнее.
По возможности всё должно быть автоматизированно.
Что правда, то правда. Но все равно пока остаётся небольшая часть, которую пока могут контролировать только разработчики.
Например делать git push --force в ветку, где работает вся команда плохо
Это, конечно. Хотя опять-таки, смотря какой git workflow используется. Если это пет-проект одного разработчика и ему так удобнее - то, почему бы и нет. Главное, чтобы всем, кто с этим работает, было комфортно. Но в любом случае, при нашем git flow мы как раз в мастер не пушим никогда. У нас так же все через Merge Requests, а форс пуши только в свою feature ветку, пока она не вмерджена в мастер.
Это тоже очень полезная история. Я так же про это думала-думала, но в итоге оставила. Решила, что тут, в принципе, допустимо сказать, что это относится к `rebase --interactive`. Но я теперь подумаю над упоминанием и такого кейса.
Привет! Спасибо большое, что рассказал! Не знала об этой команде, хотя судя по описанию, она очень полезна. Там, на самом деле, довольно много малоизвестных, но отличных команд и флагов к ним.
Привет! Спасибо большое за комментарий! Да, вы как раз и написали обо всём, что я хотела сказать :)
И отличное замечание о небольших проектах. Действительно, так как методологий git workflow бывает много, одна из них как раз и предполагает пуш сразу в мастер. Поэтому это всё скорее не про то, как правильно и неправильно, а про то, от чего будет больше пользы в определенном проекте и с чем самим разработчикам удобнее работать.
Да, полностью с вами согласна, при описанном вами подходе, когда feature branch мерджится в master со сквошем всех коммитов, данная статья будет скорее неактуальна.
Однако git workflows бывают ведь разные и каждая команда вольна выбирать свой. Это дело вкусовщины и устоев команды. Например, у нас тот самый GitFlow Git workflow, о котором вы говорите, единственное отличие - мы не сквошим коммиты при мердже в master. Поэтому нам так важно, чтобы история коммитов, которая потом окажется в мастере, была чистой.
Я так же поддерживаю запрет коммитов напрямую в мастер (в обсуждаемых воркфлоу), поэтому сделала ремарку об этом в блоке про запрет пушей сразу в мастер. Там же и расписала, что весь код, оказывающейся в мастере, должен пройти ревью и тестирование - это как раз про pull (merge) реквесты.
А разработчик тоже, конечно, имеет права работать со своей веткой как ему нравится и удобно. Это отлично работает, если потом все его коммиты все равно сожмуться в один, как вы и описали. Но если в команде не принято мерджить в мастер со сквошем коммитов, то тут уже, после всех экспериментов разработчика, стоит привести историю коммитов ветки в аккуратный вид. Именно о том, как это проще сделать я и написала.
Это хорошее замечание, я добавлю заметку о том, для какого git workflow подойдет данная статья, сейчас это действительно не очень очевидно. Если вдруг я что-то упустила или не верно поняла - пишите, я буду только рада улучшить материал :)
Привет!
Да, это правда. Тогда вся статья становится неактуальна, как заметил первый комментатор. Однако как раз в начале подчеркнула, что тут рассмаривается именно кейс, когда коммиты не сквошатся при мердже в мастер. Например, мы с командой обоюдно пришли к этому, нам так удобнее. Поэтому нам эти правила и актуальны :)
Да, хуки - это вообще отлично! С ними все куда проще и приятнее.
Что правда, то правда. Но все равно пока остаётся небольшая часть, которую пока могут контролировать только разработчики.
Это, конечно. Хотя опять-таки, смотря какой git workflow используется. Если это пет-проект одного разработчика и ему так удобнее - то, почему бы и нет. Главное, чтобы всем, кто с этим работает, было комфортно.
Но в любом случае, при нашем git flow мы как раз в мастер не пушим никогда. У нас так же все через Merge Requests, а форс пуши только в свою feature ветку, пока она не вмерджена в мастер.
Привет!
Да, спасибо большое, что упомянул!
Это тоже очень полезная история. Я так же про это думала-думала, но в итоге оставила. Решила, что тут, в принципе, допустимо сказать, что это относится к `rebase --interactive`. Но я теперь подумаю над упоминанием и такого кейса.
Привет!
Спасибо большое, что рассказал! Не знала об этой команде, хотя судя по описанию, она очень полезна. Там, на самом деле, довольно много малоизвестных, но отличных команд и флагов к ним.
Да, это тоже правда :D
Привет!
Спасибо большое за комментарий!
Да, вы как раз и написали обо всём, что я хотела сказать :)
И отличное замечание о небольших проектах. Действительно, так как методологий git workflow бывает много, одна из них как раз и предполагает пуш сразу в мастер. Поэтому это всё скорее не про то, как правильно и неправильно, а про то, от чего будет больше пользы в определенном проекте и с чем самим разработчикам удобнее работать.
Привет!
Спасибо большое за комментарий!
Да, полностью с вами согласна, при описанном вами подходе, когда feature branch мерджится в master со сквошем всех коммитов, данная статья будет скорее неактуальна.
Однако git workflows бывают ведь разные и каждая команда вольна выбирать свой. Это дело вкусовщины и устоев команды. Например, у нас тот самый GitFlow Git workflow, о котором вы говорите, единственное отличие - мы не сквошим коммиты при мердже в master. Поэтому нам так важно, чтобы история коммитов, которая потом окажется в мастере, была чистой.
Я так же поддерживаю запрет коммитов напрямую в мастер (в обсуждаемых воркфлоу), поэтому сделала ремарку об этом в блоке про запрет пушей сразу в мастер. Там же и расписала, что весь код, оказывающейся в мастере, должен пройти ревью и тестирование - это как раз про pull (merge) реквесты.
А разработчик тоже, конечно, имеет права работать со своей веткой как ему нравится и удобно. Это отлично работает, если потом все его коммиты все равно сожмуться в один, как вы и описали. Но если в команде не принято мерджить в мастер со сквошем коммитов, то тут уже, после всех экспериментов разработчика, стоит привести историю коммитов ветки в аккуратный вид. Именно о том, как это проще сделать я и написала.
Это хорошее замечание, я добавлю заметку о том, для какого git workflow подойдет данная статья, сейчас это действительно не очень очевидно.
Если вдруг я что-то упустила или не верно поняла - пишите, я буду только рада улучшить материал :)
Большое спасибо!