#git #branch #workflow
Вопрос:
Я хочу сохранить историю новой функции в git.
Идея состоит в том, чтобы изменить основную ветвь только по запросу на слияние, и чтобы каждая ветвь имела имя функции.
Это нормально? Или каждая фиксация должна содержать ссылку на функцию?
Мой вопрос возник из-за того, что несколько ветвей могут работать с одним и тем же файлом, и при смешивании в master коммиты могут быть смешаны, насколько я понимаю. С другой стороны, вы также можете удалить ветви. итак, после объединения ветвей feature_ в master и их удаления, как я узнаю, какая фиксация (изменения) соответствует какой функции?
Другими словами, если я переношу функции в ветвях, как я вижу историю, которая добавляет функцию в удаленную ветвь? если фиксации двух ветвей объединены на ведущем устройстве. Как я узнаю, к какой ветви принадлежит каждое коммит?
Комментарии:
1. Когда ветвь функции уходит, объединенные фиксации остаются. Они-это история.
2. нецелесообразно сохранять ссылки на ветвь в каждом коммите. Ветви часто перемещаются.
3. если фиксации двух ветвей объединены на ведущем устройстве. Как я узнаю, к какой ветви принадлежит каждое коммит?
4. Фиксация не «принадлежит» ветви. Ветвь-это всего лишь указатель на одну фиксацию, временная метка.
5. хорошо, я выражаюсь по-другому. После объединения ветвей feature_ в master и их удаления, как я узнаю, какая фиксация (изменения) соответствует какой функции?
Ответ №1:
Как я узнаю, к какой ветви принадлежит каждое коммит?
На этот вопрос нет ответа, потому что в git (в отличие от некоторых других систем управления версиями) отдельные коммиты не «принадлежат» ветви. Ветви в git-это, по сути, временные и подвижные указатели на коммиты, используемые при разработке для отслеживания различных потоков работы, их объединения и т. Д.
История в git полностью состоит из самих коммитов. Это включает в себя сообщения о фиксации, вот почему так важно писать хорошие сообщения о фиксации. Давайте перефразируем ваш вопрос:
Как мне узнать, для какой функции был создан каждый коммит?
Обратите внимание, что это совершенно другой вопрос: вы больше не спрашиваете о механизме создания фиксации, а о причине ее создания. Это то, о чем хорошее сообщение о фиксации может рассказать вам двумя способами:
- Хорошо написанное сообщение о фиксации объяснит причину изменения без необходимости большого количества внешнего контекста.
- Стандартизированный формат сообщений о фиксации может помочь вам увидеть группы фиксаций в журнале, например, путем включения имени проекта или номера задачи в начале каждого сообщения.
Комментарии:
1. Итак, чтобы узнать, с какой функцией связана каждая фиксация, должен ли я ссылаться на функцию в каждой фиксации? Это не ясно из рабочих процессов, которые я прочитал в git nvie.com/posts/a-successful-git-branching-model Это подразумевает, что достаточно использовать ветви и запрос на слияние, но я не понимал, как это сделать … потому что из того, что вы говорите, это невозможно сделать
2. @user60108 Просматривая эту статью, я вижу, что в ней говорится, что использование коммитов слияния позволяет увидеть, как коммиты группируются по функциям. Это правда, потому что вы можете получить диаграмму , которую она там показывает, из реального репозитория (используя
git log --graphили большинство инструментов графического интерфейса; но, как ни странно, не Github). Чего вы обычно не можете сделать, так это дать этому «пузырю» в графике фиксации имя — вы можете оставить ветвь, указывающую на одну из фиксаций, но тогда у вас будет очень длинный список ветвей в вашем репозитории. Гораздо надежнее рассматривать сообщения о фиксации как основной источник «почему».3. Я играю с bitbucket, и даже если я удалю ветку на вкладке запрос на слияние, я увижу историю изменений, связанных с этой функцией. Это полезно, но большая ошибка в том, что вы не видите, с какой функцией связана фиксация.
4. @user60108 Понятие «функция» существует только в вашем рабочем процессе и в том, как вы концептуализируете свой проект. В git нет поля под названием «имя функции»; есть названия филиалов, которые должны быть дешевыми и в основном временными; и есть сообщения о фиксации, которые являются неизменяемыми.
5. Я понимаю, что, я исходил из предположения об использовании функции по ветвям, это git worflow, который чаще всего предлагается в Интернете