Предыдущий ролик Следующий ролик  

Видео урок: Стратегии для уменьшения конфликтов при слиянии

Git: обучение основам

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

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

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

Потому что каждый раз как вы это делаете, слияния будут становиться все меньше, и конфликты будут все меньше и более изолированными. Чем дольше вы ждете, тем больше будут конфликты при слиянии. Вместо того чтобы разрешать конфликт в трех файлах, вы вдруг получаете конфликт в 50 файлах. Вы потратите много времени, чтобы их разрешить, и это будет очень болезненный опыт. Лучше останавливаться и разрешать эти конфликты по мере поступления. Как вы могли догадаться, вы не можете делать несколько слияний за раз, мы делали слияние один раз. Давайте быстренько посмотрим и убедимся, что все чисто. Допустим, у нас есть основной бранч и бранч text_edits.

Мы внесли коммиты в оба этих бранча и сделали слияние. Но на данном этапе нам не нужно выбрасывать бранч text_edits. Мы и дальше можем вносить в него коммиты, а также другие коммиты в основной бранч, а затем снова сделать слияние. Мы можем вносить изменения в бранч text_edits, делать еще коммиты в основной бранч, а затем снова сделать слияние, вот что я имел в виду, когда говорил о частом слиянии. Последняя стратегия, возможно, самая важная, то есть по мере работы отслеживать изменения в основном бранче.

Что такое отслеживать изменения? Я имею в виду, что когда изменения происходят в основном бранче, стоит вносить эти изменения в ваш текущий бранч, так чтобы этот бранч был синхронизирован с основным, чтобы различия в них были небольшими. Давайте я вам покажу, что это значит. Итак, у нас есть основной бранч, есть бранч text_edits, мы делаем коммиты в оба эти бранча. В какой момент мы можем сказать - в основном бранче есть некоторые критические изменения, которые мы хотим иметь и в бранче text_edits. Я могу внести их в text_edits. Теперь text_edits снова синхронизирован с основным бранчем, затем будут еще изменения в основном бранче, еще изменения в text_edits, а потом я снова могу сделать слияние, чтобы посмотреть, что произошло в основном бранче, так что тепеь оба бранча синхронизированы.

А когда я решу, что хочу внести изменения из text_edits в основной бранч, их не будет очень много. Большинство изменений уже существуют в основном бранче, и таким образом уменьшится число конфликтов при слиянии. Мы называем этот процесс отслеживанием, и это очень хорошая стратегия. теперь вы уже неплохо разбираетесь в том, как работать с бранчами. Как их создавать, как добавлять в них коммиты, как переключаться между бранчами, как делать слияние. Это мощная возможность в Git, и вы будете часто ее использовать.