Исправление разделяемой части кода при разработке функций с использованием GIT

Question

У меня следующая проблема.Допустим, у меня есть dev ветвь моего решения.Однажды у меня появилась идея разработать новую функцию.Поэтому я создаю новую ветку feature / my-new-feature из dev .Во время разработки этой функции я понимаю, что было бы намного проще создать ее (а также код, как правило, было бы лучше), если бы я реорганизовал (возможно, значительно) некоторые общие службы / классы или даже интерфейсы.

Что бы вырекомендовать делать в таком случае?

Вчера у меня был такой момент, и я начал вносить эти существенные изменения в мою ветку feature / my-new-feature .К сожалению, это была не единственная функциональная ветка, которая у меня была.После некоторой перебазировки, слияния и записи в моем хранилище стало довольно грязно.Ну, код работает, но мой график фиксации и график ветвей ... если честно, даже я не знаю, что там происходит.

Если вы найдете время, чтобы ответить, пожалуйста, сделайте это с примерамикоманды git.Я не очень опытный с мерзавцем.Вчера несколько раз я был удивлен результатами моих мерзавцев.

Answer 1

Я бы предложил следующий метод работы, который мы используем на работе. Мы начинаем с отрасли master, которая является нашим стабильным производством. Если мы хотим создать новую функцию, мы создадим новую ветку feature/whatever. Мы вносим наши изменения и, в конце концов, перебазируем их поверх последней ветки master, используя git rebase -i origin/master. Это открывает интерактивный режим, в котором вы можете легко перефразировать, переупорядочивать, сквош и даже удалять коммиты. Это, однако, меняет вашу историю, и если вы уже один раз выдвинули ее на удаленную страницу (в ветви функций), вам нужно принудительно протолкнуть ваши изменения, иначе git не примет их.

После этого мы объединяем ветвь с веткой master.

Если по какой-то причине материал должен быть реорганизован, мы в основном решаем сделать это в отдельной чистой ветке (от последнего мастера), используя описанный выше метод, и объединить ее сначала с мастером. Можно также просто зафиксировать эти исправления в их локальной ветке, а затем снова добавить их в их функциональную ветвь, однако мы склонны делать наши слияния, чтобы освоить относительно небольшой размер.