#javascript #php #laravel #git
#javascript #php #laravel #git
Вопрос:
Я пытаюсь заставить себя использовать git для разработки своих веб-приложений, я разрабатываю один, поскольку все еще учусь. Мне было интересно, будет ли этот рабочий процесс хорошим началом для меня. В принципе, у меня есть ветка master, она также называлась бы производственной, если бы в ней находился только безопасный и работающий код, тогда у меня могла бы быть ветка develop, в этой ветке я выполнял бы всю свою повседневную работу, в этой ветке я мог бы добавлять новые функции, исправления, все в виде ветвей, и я предполагаю, что эти новые ветви от develop можно было бы объединить с master? или, может быть, объединен с develop и обратно в master? какое было бы лучшим решением?
Я открыт для предложений любого рода.
Комментарии:
1. Я бы сделал именно так, как вы сказали, но никогда не объединял бы какую-либо третичную (функциональную) ветвь напрямую с master. Всегда выполняйте слияние в develop и убедитесь, что оно работает с существующим там кодом, прежде чем перемещать его в производственную ветку. Кроме того, совершайте ранние и частые коммиты — в основном, как можно больше небольших коммитов. У меня самого нет большого опыта работы с git, но это то, что, как мне кажется, я знаю на данный момент.
2. Похоже, вы используете упрощенную версию git-flow atlassian.com/git/tutorials/comparing-workflows /…
3. вы можете создать ветви разработки и производства, перенести всю работу в ветку dev, убедившись, что она работает так, как задумано, затем объединить с производственной веткой
Ответ №1:
Да, это хорошее начало для веб-разработки Когда вы разработали и завершили функцию, вы можете объединить ветку разработки с веткой master. Наша компания и наша группа используют этот способ для разработки, Более того, у нас есть ветка для тестирования.Во всей основной ветке есть три ветки; ветка разработки и ветка тестирования, которые мы разрабатываем в ветке разработки.Когда мы завершаем функцию, это слияние с тестовой веткой. Когда тестировщик заканчивает свою работу, тестовая ветвь сливается с основной ветвью.
Ответ №2:
Я бы предложил иметь главную ветвь (заблокированную с правами слияния только для нескольких) и ветвь разработки, которая объединяется с master после завершения спринта или разработки. завершение.
- Для каждой новой функции вы можете создать ответвление от development и объединить его с development, как только вы убедитесь, что она готова к объединению. Например.
git checkout -b feature/search-feature - Для исправления ошибок, связанных с уже объединенной веткой, вы можете открыть ветку исправления ошибок с именем фактической ветки: Например:
git checkout -b bugfix/search-feature - Для исправлений, которые вы вносите на сервер после его развертывания, потому что вы решили, что что-то было сломано, у вас, вероятно, может быть префикс исправления. Например: исправление / неисправность-проблема
- Я настоятельно рекомендую вместо сообщений о фиксации отправлять сообщения со смыслом, в которых говорится «Исправления», «Исправленные проблемы», потому что, когда вы оглянетесь назад, чтобы просмотреть коммиты или выбрать вишню, это будет очень удобно. Например:
git commit -m "Fixed [your issue] in [your functionality]".
Ответ №3:
Я использую много 3 основных разветвленных. мастер, постановка и разработка.
Все новые функции будут объединены в разработку, которая потенциально может вызвать проблемы. Как только Sprint будет завершен, заморозьте код и объедините в staging, где выполняется окончательное тестирование. Теперь разработка продолжает жить своей собственной жизнью и не вносит никаких новых проблем в код на этапе тестирования. После тестирования затем объедините с master, который будет выпущен.
Таким образом, master всегда готов к исправлениям. Если происходят исправления, то объедините их из master в staging для разработки.