Существуют ли рабочие процессы, позволяющие использовать Git для записи logi c о том, как вносятся изменения, когда физическая механика изменений значительно отличается от этой логики c?
Context
* В конструкции 1040 * предполагается, что физический процесс разработки изменений имеет некоторое отношение к логическим изменениям, которые должны быть сделаны. Тем не менее, мой опыт показывает, что (кроме самого тривиального случая) это случается редко.
Один конкретный c пример случая, когда это вызывает у меня проблемы:
То, как я занимался разработкой в течение последних 10 с лишним лет, приводит к тому, что физическое состояние моих клиентов почти никогда не является чем-то разумным для принятия / отправки на проверку. Например, рабочее состояние клиента почти всегда на несколько шагов ниже, прежде чем я даже узнаю, каким будет первое изменение / фиксация, не говоря уже о том, чтобы выглядеть. И правки, которые заканчиваются в этом первом коммите, имеют тенденцию перемежаться во времени с другими правками, которые не включены. Таким образом, я в конечном итоге задним числом создаю коммит / PR в рабочем состоянии, а затем отправляю его на рассмотрение, пока продолжаю работать над остальной частью проекта / функции. Затем я извлекаю второй коммит / PR для следующей логической части работы и отправляю его на рассмотрение до завершения первого обзора.
Что мне делать, если я получу комментарии от этого первого обзора?
- Как минимум, я заканчиваю тем, что добавляю больше коммитов в первую ветку PR (что не имеет отношения к логике c изменения).
- Хуже; когда я сливаюсь / перебазирую / эт c. второй PR, который включает в себя последующие действия первого, эти изменения отображаются как часть его, где они на самом деле совершенно не имеют значения.
Подобные проблемы также возникают, когда изменения других людей объединяются.
Я признаю, что отслеживание механизма работы PR / обзора, возможно, имеет значение как часть PR / обзора , но это абсолютно не значение как часть истории источника. Во всяком случае, это просто отвлечение.
Я также допущу, что долгоживущие ветви (например, ветка 'v2.3. *') Также должны включать в себя историю слияния (например, когда исправления ошибок / функции возвращаются обратно). Но я довольствуюсь тем, что «функциональные ветви» (где вы выполняете некоторую работу, предназначенную для полного слияния обратно в ветку из ее истории) всегда должны быть достаточно маленькими и достаточно целенаправленными, чтобы логическое представление состояло в том, что они разветвляются и немедленно вернуться в ветку root, даже если физическая реальность, с которой эти недели или месяцы работы были объединены во время разработки.
ps Пока я профессионально работал программистом и использовал исходный код контроль более десяти лет (ближе к двум, если вы включите некоторые любительские вещи), это всегда было чем-то отличным от Git. Так что все, что я сделал git, было на GitHub, и либо с репозиториями, к которым я являюсь единственным коммиттером, либо к которым у меня нет доступа к коммитам. Возможно, это дает мне искаженное представление о том, как Git работает.