Как мне контролировать версии моего проекта на GitHub

Я пытаюсь провести столько времени , сколько я могу на GitHub в настоящее время (даже я единственный человек в команде на работе) , чтобы почувствовать , как это будет , как для реального мира корпоративного применения.

У меня один вопрос, связанный с управлением версией . Допустим, мы начали проект. Затем члены команды создали несколько филиалов и развивались там. Когда мы готовы к производству, мы объединили все филиалы с masterфилиалом. В конце мы живем с версией 1.0.

Теперь эта версия 1.0работает, и у нас есть некоторые проблемы, связанные с этой версией этого программного обеспечения. Мы хотели бы начать разработку для версии 1.1, чтобы исправить те проблемы, которые мы представили, спеша с проектом.

Теперь вопрос заключается в следующем:

Как мы должны контролировать управление версиями здесь?

Должны ли мы создать новую ветку для v1.0и сохранить версию 1.0программного обеспечения там и разрабатывать в некоторых ветках (или нет), объединять их с master, продолжать жить с версией 1.1?

Существует ли соглашение для подобных ситуаций?

— tugberk
источник

Ответы:

Я нашел (и начал принимать) следующую модель ветки :

Изображение с nvie.com

^{(изображение из статьи)}

В этой статье описано много хороших практик и строгих правил, я очень рекомендую это.

Точки интереса:

Основная ветка - это место, где вы отмечаете свои версии. Никакого развития не происходит здесь. В случае ошибки, которая была развернута в рабочей среде, вы исправляете ошибку в ветви исправлений, объединяетесь и помечаете новую версию.
Разработка происходит на ветке разработки и разработки. Лично я делаю исправление ошибок в ветке devel и функций в ветках функций.
Когда программное обеспечение начинает достигать выпуска, я разветвляюсь, чтобы выпустить ветку В ветке релиза я делаю последние штрихи. Увеличьте номера версий, измените метаданные и т. Д. И незначительные исправления. Когда он закончен, я объединяю его с мастером, помечаю и называю его версией.
Две основные ветви: мастер - это «священная ветвь»; его HEAD - это всегда последний производственный код, а разработка - это ночная ветка; его заголовок всегда отражает последние (но возможные нестабильные) дополнения к коду.

В вашем конкретном случае шаги будут зависеть от того, насколько поспешной была эта версия. Если бы это были упущены функции, я бы вернулся к разрабатываемой версии и повторил бы все заново. Если в развернутой версии есть ошибки, я бы отправился в ветку с исправлениями, исправил ошибки, объединил их и добавил тег v1.1. Если это и то и другое, я бы сначала исправил ошибки, а затем добавил функции, как описано.

— Тамас Селеи
источник

Очень информативно и подробно. А также идеальная практика. Это также имеет большой смысл. Наличие мастера для продюсера только облегчает обслуживание. Я так незнаком с пометкой ветки (или коммитом?). Можете ли вы дать мне некоторые подробности об этом? Как мы можем сделать в соответствии с моделью выше?

— Tugberk

В git целью тегирования является коммит. Это означает, что вы говорите: «вот этот коммит, и с этого момента я называю его« v1.3 »». На практике это означает, что вы переключаетесь на основную ветку, сливаетесь с (теперь стабильной) веткой devel, commit и tag. Затем вы можете перечислить все теги, вернуться к этому коду на тот случай, если вам нужно увидеть, что вошло в производство в прошлом выпуске. В тегах есть немного больше, чем это (что полезно для крупномасштабной распределенной разработки, такой как ядро linux). Если вам интересно, предлагаю прогитировать книгу .

— Тамас Селеи

ProGit - одна из книг, которую я обязательно прочту с нуля. Пока я читаю только те части, которые мне интересны, чтобы выполнить работу. Пока что мы разработали основную ветку, и я думаю, что я должен поддерживать это. Но я открою другую ветвь с именем productionи буду использовать ее как masterветку в соответствии с приведенной выше моделью.

— Tugberk

В то время как я пробую эту модель, я борюсь с одной вещью: есть несколько вспомогательных веток, которые обсуждались в данной статье, ветки функций и релизов. может быть несколько будущих ветвей. Например, FeedbackForm - это одна будущая ветвь, а ContactForm - другая. Это нормально для этой модели? Должно ли быть несколько веток релиза? и если да, то как мне их назвать?

— Tugberk

Прежде всего, вам не нужно следовать этому письму, просто установите правила, которые вы соблюдаете. Делайте то, что лучше для вас и стиля вашей команды. Во-вторых, да, несколько веток функций и версий нормальны, если у вас нет недолговечного проекта с одной функцией и одним выпуском :). Именование, согласно статье, является release- * и feature- *. Я полагаю, вы указали номер будущей версии вместо звездочки для выпуска и идентификатор трекера проблемы в случае ветвей функций.

— Тамас Селеи

То, что я наблюдал большую часть времени, это:

Мастер для вас продукт. Со временем вся ваша будущая версия x.0 будет на мастере.
Вы создаете тег / ветку для каждой версии в производстве, так что вы все равно можете поддерживать их для любого клиента, который в этом нуждается.
Объединение исправлений из одного или другого - это дело в каждом конкретном случае.

— xsace
источник

Благодарность! так вы думаете, что разумно сохранить ветку с именем v1.0, v1.2 разумно?

— Тагберк

@tugberk, пока соответствующее программное обеспечение существует в этой версии, имеет смысл держать ветки вокруг, чтобы вы могли быстро их разветвлять, если вам нужна определенная ветка исправлений. Когда программное обеспечение больше не существует в этой версии (больше не поддерживается, поэтому больше не может выполняться), имеет смысл выполнить окончательное объединение ветви и затем удалить ее. Вы даже можете создать окончательный пустой коммит (я делаю это часто в начале ветки), просто чтобы сказать «Закрытие ветки XXXX», иначе вы не сохраните историю ветки (reflog может немного помочь, но это для репозитория)

— Патрик Мевзек