#git #version-control
#git #контроль версий
Вопрос:
Я все еще немного новичок в системах контроля версий.
В настоящее время у меня есть две ветви: master и develop . Вчера я работал над веткой develop и понял, что то, что я сделал, было неправильным, поэтому мне пришлось вернуться к какому-то более старому коммиту.
Проблема в том, что в недавних коммит я добавил пару новых модульных тестов и значительно улучшил некоторые ключевые классы инфраструктуры модульного тестирования, которые я захочу сохранить в своем проекте, даже после возвращения к более старому коммиту.
Это заставило меня осознать, что, возможно, то, что я должен был сделать с самого начала, — это создать ветку, связанную со всеми теми функциями, которые «связаны с проектом» и не обязательно связаны с «текущей функцией». Я прав?
Как вы справляетесь с такими вещами в своих повседневных рабочих процессах с помощью git?
Ответ №1:
Я хотел бы порекомендовать вам статью «Успешная модель ветвления Git«, в которой используются ветви функций, ветви разработки, ветви выпуска и исправления для представления различных целей. И еще одно расширение Git, которое может вас заинтересовать, — это gitflow, оно обеспечивает высокоуровневые операции с репозиторием для модели ветвления, упомянутой в статье.
Комментарии:
1. Хотя это отличная статья, я не уверен, что она подойдет для кого-то, кто новичок в системах контроля версий. Это похоже на описание того, как построить дом, когда студент все еще осваивает молоток и дрель.
2. @Грег, я не согласен. Люди, новички в управлении версиями, в любом случае «строят дом». Их программное обеспечение будет иметь ту же сложность, и у них все равно будут те же изменения, которые они хотят отменить. Наличие правильной модели ветвления может значительно упростить эти задачи. Это больше похоже на то, что кто-то сказал им, что с помощью этих инструментов построить дом стало проще, но они не могут понять, почему им все время приходится сносить и перестраивать стены. Хорошая модель ветвления похожа на план, который позволяет избежать трудноизлечимых ошибок в первую очередь, хотя в краткосрочной перспективе может показаться проще просто начать работать.
Ответ №2:
В этом конкретном случае я бы создал новую ветку (называемую ImproveUnitTests) из master, а затем выделил бы из коммитов, относящихся к этой теме, которые вы сделали из development. Затем ваши ImproveUnitTests могут быть легко объединены обратно в master самостоятельно.
Для повседневных задач я использую МНОЖЕСТВО веток. Если я разрабатываю featureX и вижу, что мне нужно исправить что-то еще, я переключусь обратно на свой мастер и создам новую ветку, просто чтобы исправить это. Затем объедините мою ветку «fixit» в master и выполните перебазировку featureX с этого.
Ответ №3:
Если я вас правильно понял, вы хотите отменить свои изменения, но некоторые из них сохранить. В этом случае я бы переключился на master и выбрал те изменения, которые были хорошими (изменения в модульном тестировании), а затем просто вернул ветку разработки и был бы счастлив 🙂