Что такое реобас в компьютере
Обновлено: 04.07.2024
Энтони Хеддингс
Энтони Хеддингс
Писатель
Энтони Хеддингс (Anthony Heddings) – штатный облачный инженер LifeSavvy Media, технический писатель, программист и эксперт по платформе Amazon AWS. Он написал сотни статей для How-To Geek и CloudSavvy IT, которые были прочитаны миллионы раз. Подробнее.
Слияние и перебазирование преследуют схожие цели, но осуществляются по-разному. И то, и другое помогает управлять работой с ветками и совместной работой с несколькими людьми, но они не взаимозаменяемы, и перебазирование может быть вредным, если оно не выполнено должным образом.
Что делать с перебазированием?
Перебазирование очень сложно, поэтому важно понимать, как работает git внутри, если мы собираемся разобраться в этом.
Git сохраняет ваш код в виде последовательности правок. Вы можете думать об этом как о цепочке, работающей в обратном направлении. Каждое редактирование или «фиксация» ссылается на идентификатор предыдущей фиксации и включает в себя то, что изменилось по сравнению с предыдущей фиксацией. Эта цепочка хранится только на вашем компьютере; ваш Git-клиент не общается ни с какими другими Git-клиентами, если только он не выполняет выборку или отправку (на самом деле получение — это просто выборка + слияние с вашей локальной веткой), и даже в этом случае он общается только с общим удаленным репозиторием.
С ответвлениями сложнее. При работе с ветками Git сохраняет только одну вещь: идентификатор коммита в конце ветки. Таким образом, вы можете думать о них как о головке воспроизведения на проигрывателе; вы помещаете головку ветки в определенную позицию, и она возвращается обратно по цепочке, «проигрывая» ваш код и получая окончательную версию. Всякий раз, когда вы фиксируете, ваш локальный клиент git автоматически перемещает указатель воспроизведения вперед к новому коммиту.
Если вы хотите объединить функцию с мастером, вы должны запустить:
При этом создается новый коммит слияния, и если возникнут какие-либо конфликты, вам придется решать их вручную. Команда git merge перемещает главную точку воспроизведения в новую фиксацию слияния и удаляет точку воспроизведения функции, так как в ней больше нет необходимости.
У этого метода слияния кода есть три проблемы:
- В главной ветке могут быть изменения, которые хотелось бы включить в ветку функций, особенно если разработка функции требует времени.
- Вынужденный проходить процесс слияния каждый раз, когда вы хотите работать с ветвями, раздражает.
- История коммитов беспорядочна, хотя это в основном эстетическая проблема.
Перебазирование пытается решить эти проблемы с разной степенью успеха. Перебазирование изменений там, где вы начали свою ветку. Вся ветвь поднимается и транспортируется в конец текущей главной ветки, где она соединяется с концом. Ветка master остается нетронутой и может продолжать получать коммиты.
Однако коммиты на самом деле не перемещаются, поскольку коммиты неизменяемы. Скорее, они копируются, что приводит к новым идентификаторам коммитов. Предыдущие коммиты остаются незанятыми, прячутся в ваших файлах Git, но их больше никогда не видно, так как указатель воспроизведения переместился куда-то еще.
Чтобы выполнить этот процесс из командной строки, выполните:
Это открывает ветку, извлекает текущие изменения в основную, а затем перебазирует ветку функций в главную ветку.
На данный момент код в ветке функций более актуален, что является единственной реальной функцией git rebase. Перебазирование не объединяет ветки, поскольку оно не создает каких-либо коммитов слияния и не перемещает точку воспроизведения мастера.
Если вы хотите выполнить слияние после перемещения, выполните:
Что будет выглядеть так, если указатель воспроизведения основного устройства заменит указатель воспроизведения функции:
Таким образом, перебазирование не решает проблему слияния, так как вам все равно придется выполнять слияние в конце, чтобы обновить основную ветку. Фактическая команда слияния в конце должна пройти без заминок, поскольку процесс перемещения требует от вас «слияния» изменений, что все еще может вызвать конфликты.И если вы все еще хотите продолжить работу над своей веткой, вам все равно нужно «слить» изменения.
Не перебазировать общие ветки
Помните, как перебазирование копий фиксирует и оставляет застрявшую точку воспроизведения? На самом деле это серьезная проблема, если вы работаете с общим кодом. Допустим, вы создали функциональную ветку и отправили ее в репозиторий, чтобы ваши коллеги могли ее протестировать. Это совершенно нормально, но если один из них захочет отделиться от вашей ветки, когда вы в конце концов перебазируете, вы получите следующее:
Ветка feature2 вашего коллеги теперь ссылается на старую цепочку коммитов. Ваш Git-клиент не может знать об этом, поскольку ветка feature2 хранится на компьютере вашего коллеги. Они также не могут узнать, что вы перебазировались, пока вы не отправите свои изменения.
При перебазировании он не копировал ветку feature2 при копировании всех коммитов. Даже если бы это было возможно, это не повлияет на локальный репозиторий Git вашего коллеги, что приведет к рассинхронизации всего. Решение здесь состоит в том, чтобы перебазировать функцию 2 на функцию в том месте, где она должна быть, но это беспорядочно даже по стандартам Git, и это всего лишь очень простой пример.
Суть в том, что не выполняйте перебазирование, если вы не работаете локально.
Когда перебазирование лучше слияния?
Если разработка вашей ветки займет некоторое время, перебазирование решит проблему «синдрома ветки», когда ваш код слишком устарел по сравнению с работающим мастером, и вам нужно обновить его, чтобы продолжить работу. Вообще говоря, вы должны попытаться избежать этой проблемы, насколько это возможно, но перебазирование может исправить ее, когда она возникает.
Если вы просто вносите небольшие, поэтапные, ежедневные изменения, вам следует вместо этого работать с локальной основной веткой и использовать запросы на извлечение, когда вы будете готовы внести свои изменения. В них используется модель тематических ветвей, созданная специально для хранения вашего кода до его одобрения для слияния.
Но если вы работаете еженедельно и в конечном итоге собираетесь делать несколько запросов на включение и несколько раз выполнять слияние, вы можете немного дольше работать над своим кодом, выполнять локальную перебазировку для обновлений и выполнять одно извлечение просьба в конце сократить количество тестов и общения с руководителями. Перебазирование — это в первую очередь локальная вещь, поэтому вы можете делать это в своих промежуточных ветках, не дожидаясь одобрения.
Если от вашей ветки больше никто не зависит, вы можете перебазировать перед слиянием веток, чтобы сделать историю коммитов чистой и одномерной. Тем не менее, можно возразить, что традиционное слияние, хотя и более уродливое, легче отслеживать и отлаживать, поскольку коммиты слияния полностью неразрушающие. В любом случае перебазирование необходимо выполнить непосредственно перед объединением ваших изменений, иначе вы можете столкнуться с проблемой обновления мастера до того, как ваши изменения будут одобрены.
- › Стоит ли использовать Git-клиент с графическим интерфейсом?
- › Как исправить, изменить или отменить коммиты Git (изменение истории Git)
- › CloudFoundry или Kubernetes: какую облачную платформу выбрать?
- › Как развернуть веб-сервер Caddy с помощью Docker
- › Что будет в React 18?
- › Как использовать Docker для упаковки приложений CLI
- › Что нового в TypeScript 4.6?
- › Как развернуть сервер GitLab с помощью Docker
Заставьте всех думать, что вы пишете идеальный код с первого раза (и упростите проверку и слияние ваших исправлений).
Разработка программного обеспечения — это беспорядок. Так много неправильных поворотов, опечаток, которые нужно исправить, быстрых хаков и ляпов, которые нужно исправить позже, ошибок, которые вы обнаружите в конце процесса. С контролем версий у вас есть безупречная запись каждого неправильного поворота и исправления, сделанного в процессе создания «идеального» конечного продукта — патча, готового к отправке вышестоящим. Как и кадры из фильмов, они немного смущают, а иногда и забавляют.
Было бы здорово, если бы вы могли использовать контроль версий, чтобы регулярно сохранять свою работу в контрольных точках, а затем, когда у вас есть что-то, что вы готовы отправить на проверку, вы могли бы скрыть всю эту личную черновую работу и просто отправить сингл, идеальный патч? Встречайте git rebase -i, идеальный способ переписать историю и заставить всех думать, что вы создаете идеальный код с первого раза!
Что делает git rebase?
Если вы не знакомы с тонкостями Git, вот краткий обзор. Под прикрытием Git связывает различные версии вашего проекта с уникальным идентификатором, который состоит из хэша уникального идентификатора родительского узла и разницы между новой версией и ее родительским узлом. Это создает дерево ревизий, и каждый, кто проверяет проект, получает свою собственную копию.Разные люди могут развивать проект в разных направлениях, каждый из которых может начать с разных точек ветвления.
Программирование и разработка
Есть два способа обратно интегрировать вашу работу с веткой master в исходный репозиторий: один — использовать git merge, а другой — использовать git rebase. Они работают по-разному.
При использовании git merge в ветке master создается новая фиксация, включающая все изменения из источника, а также все ваши локальные изменения. Если есть какие-либо конфликты (например, если кто-то еще изменил файл, с которым вы также работаете), они будут отмечены, и у вас будет возможность разрешить конфликты до фиксации этого коммита слияния в ваш локальный репозиторий. Когда вы отправляете свои изменения обратно в родительский репозиторий, вся ваша локальная работа будет отображаться как ветка для других пользователей репозитория Git.
Но git rebase работает иначе. Он перематывает ваши коммиты и снова воспроизводит эти коммиты с кончика основной ветки. Это приводит к двум основным изменениям. Во-первых, поскольку ваши коммиты теперь ответвляются от другого родительского узла, их хэши будут пересчитаны, и любой, кто клонировал ваш репозиторий, теперь может иметь поврежденную копию репозитория. Во-вторых, у вас нет фиксации слияния, поэтому любые конфликты слияния идентифицируются по мере того, как ваши изменения воспроизводятся в основной ветке, и вам необходимо исправить их, прежде чем продолжить перебазирование. Когда вы отправляете свои изменения сейчас, ваша работа не отображается в ветке, и создается впечатление, что вы записали все свои изменения из самой последней фиксации в основную ветку.
Однако у обоих этих вариантов есть обратная сторона: все могут видеть все ваши наброски и правки, когда вы решали проблемы локально, прежде чем вы были готовы поделиться своим кодом. Именно здесь на сцену выходит флаг --interactive (или -i для краткости) для git rebase.
Введение в git rebase -i
Большое преимущество git rebase в том, что он перезаписывает историю. Но зачем останавливаться на том, чтобы просто притворяться, что вы разветвились в более поздней точке? Есть способ пойти еще дальше и переписать то, как вы пришли к готовому к предложению коду: git rebase -i, интерактивный git rebase.
Эта функция является "волшебной машиной времени" в Git. Флаг позволяет вам вносить сложные изменения в историю изменений при выполнении перебазирования. Вы можете скрыть свои ошибки! Объедините множество небольших изменений в один первоначальный патч! Измените порядок отображения элементов в истории изменений!
Когда вы запускаете git rebase -i, вы получаете сеанс редактора со списком всех коммитов, которые перебазируются, и рядом вариантов того, что вы можете с ними сделать. Выбор по умолчанию — выбрать.
- Pick сохраняет фиксацию в вашей истории.
- Reword позволяет изменить сообщение фиксации, например, исправить опечатку или добавить дополнительный комментарий.
- Правка позволяет вносить изменения в фиксацию в процессе воспроизведения ветки.
- Squash объединяет несколько коммитов в один.
- Вы можете изменить порядок коммитов, перемещая их в файле.
Когда вы закончите, просто сохраните окончательный результат, и перебазирование будет выполнено. На каждом этапе, когда вы решили изменить фиксацию (с помощью переформулировки, редактирования, подавления или при возникновении конфликта), перебазирование останавливается и позволяет вам внести соответствующие изменения, прежде чем продолжить.
Приведенный выше пример приводит к тому, что "Однострочное исправление ошибки" и "Интегрировать новый заголовок везде" объединяются в один коммит, а "Новый заголовок для веб-сайта с документацией" и "О, опечатка. Исправлено" - в другой. Как по волшебству, работа, выполненная в других коммитах, осталась в вашей ветке, но связанные коммиты исчезли из вашей истории!
Это упрощает отправку чистого патча в вышестоящий проект с помощью git send-email или путем создания запроса на включение в родительский репозиторий с вашим недавно приведенным в порядок набором исправлений. Это имеет ряд преимуществ, в том числе то, что ваш код легче просматривать, легче принимать и легче объединять.
Разветвление означает отделение основной ветки, чтобы вы могли работать отдельно, не затрагивая основной код и других разработчиков. При создании репозитория Git по умолчанию нам назначается главная ветка.Когда мы начинаем делать коммиты, эта ветка master продолжает обновляться и указывает на последнюю фиксацию, сделанную в репозиторий.
Ветвление в Git выглядит следующим образом:
Перебазирование
Перебазирование в Git — это процесс интеграции серии коммитов поверх другого базового совета. Он берет все коммиты ветки и добавляет их к коммитам новой ветки. Перебазирование Git выглядит следующим образом:
Технический синтаксис команды rebase:
git rebase [-i | –interactive] [параметры] [–exec cmd] [–onto newbase | –keep-base] [восходящая [ветвь]]
Использование:
Основная цель перебазирования — поддерживать более прямую и четкую историю проекта. Перебазирование приводит к совершенно линейной истории проекта, которая может следовать от конечной фиксации функции до начала проекта, даже не разветвляясь. Это упрощает навигацию по вашему проекту.
Стандартная и интерактивная перебазировка
Git rebase находится в интерактивном режиме, когда команда rebase принимает аргумент —i. Это расшифровывается как Interactive. Без каких-либо аргументов команда выполняется в стандартном режиме.
Чтобы добиться стандартного перемещения, мы следуем следующей команде:
Приведенная выше команда эквивалентна следующей команде и автоматически берет коммиты в вашей текущей рабочей ветке и применяет их к заголовку ветки, которая будет упомянута:
Принимая во внимание, что при интерактивном перемещении вы можете изменять отдельные коммиты по мере их перемещения в новую ветку. Он предлагает вам полный контроль над историей коммитов ветки.
Чтобы добиться интерактивного перемещения, мы следуем следующей команде:
Эта команда выводит список всех коммитов, которые собираются переместить, и запрашивает перебазирование всех коммитов по отдельности, а затем их перебазирование в соответствии с введенными вами вариантами. Это дает вам полный контроль над тем, как выглядит история вашего проекта.
Слияние и перебазирование
И слияние, и перебазирование используются для объединения веток, но разница заключается в истории коммитов после интеграции одной ветки в другую. При слиянии Git коммиты от всех разработчиков, которые сделали коммиты, будут в журнале git. Это действительно хорошо для новичков, потому что голову можно откатить, чтобы зафиксировать от любого из разработчиков. Принимая во внимание, что в git rebase коммит только от одного разработчика будет отмечен в журнале git. Продвинутые разработчики предпочитают это, потому что это делает историю коммитов линейной и чистой.
Команда для слияния задается так:
Это создает новую фиксацию в объединенной ветке, которая связывает воедино истории обеих веток, давая вам структуру ветки, которая выглядит следующим образом, в отличие от перебазирования того, что мы видели выше:
Примечание. После выполнения перебазирования мы по умолчанию находимся на последнем коммите перебазированной ветки.
Энтони Хеддингс
Энтони Хеддингс
Писатель
Энтони Хеддингс (Anthony Heddings) – штатный облачный инженер LifeSavvy Media, технический писатель, программист и эксперт по платформе Amazon AWS. Он написал сотни статей для How-To Geek и CloudSavvy IT, которые были прочитаны миллионы раз. Подробнее.
Слияние и перебазирование преследуют схожие цели, но осуществляются по-разному. И то, и другое помогает управлять работой с ветками и совместной работой с несколькими людьми, но они не взаимозаменяемы, и перебазирование может быть вредным, если оно не выполнено должным образом.
Что делать с перебазированием?
Перебазирование очень сложно, поэтому важно понимать, как работает git внутри, если мы собираемся разобраться в этом.
Git сохраняет ваш код в виде последовательности правок. Вы можете думать об этом как о цепочке, работающей в обратном направлении. Каждое редактирование или «фиксация» ссылается на идентификатор предыдущей фиксации и включает в себя то, что изменилось по сравнению с предыдущей фиксацией. Эта цепочка хранится только на вашем компьютере; ваш Git-клиент не общается ни с какими другими Git-клиентами, если только он не выполняет выборку или отправку (на самом деле получение — это просто выборка + слияние с вашей локальной веткой), и даже в этом случае он общается только с общим удаленным репозиторием.
С ответвлениями сложнее. При работе с ветками Git сохраняет только одну вещь: идентификатор коммита в конце ветки.Таким образом, вы можете думать о них как о головке воспроизведения на проигрывателе; вы помещаете головку ветки в определенную позицию, и она возвращается обратно по цепочке, «проигрывая» ваш код и получая окончательную версию. Всякий раз, когда вы фиксируете, ваш локальный клиент git автоматически перемещает указатель воспроизведения вперед к новому коммиту.
Если вы хотите объединить функцию с мастером, вы должны запустить:
При этом создается новый коммит слияния, и если возникнут какие-либо конфликты, вам придется решать их вручную. Команда git merge перемещает главную точку воспроизведения в новую фиксацию слияния и удаляет точку воспроизведения функции, так как в ней больше нет необходимости.
У этого метода слияния кода есть три проблемы:
- В главной ветке могут быть изменения, которые хотелось бы включить в ветку функций, особенно если разработка функции требует времени.
- Вынужденный проходить процесс слияния каждый раз, когда вы хотите работать с ветвями, раздражает.
- История коммитов беспорядочна, хотя это в основном эстетическая проблема.
Перебазирование пытается решить эти проблемы с разной степенью успеха. Перебазирование изменений там, где вы начали свою ветку. Вся ветвь поднимается и транспортируется в конец текущей главной ветки, где она соединяется с концом. Ветка master остается нетронутой и может продолжать получать коммиты.
Однако коммиты на самом деле не перемещаются, поскольку коммиты неизменяемы. Скорее, они копируются, что приводит к новым идентификаторам коммитов. Предыдущие коммиты остаются незанятыми, прячутся в ваших файлах Git, но их больше никогда не видно, так как указатель воспроизведения переместился куда-то еще.
Чтобы выполнить этот процесс из командной строки, выполните:
Это открывает ветку, извлекает текущие изменения в основную, а затем перебазирует ветку функций в главную ветку.
На данный момент код в ветке функций более актуален, что является единственной реальной функцией git rebase. Перебазирование не объединяет ветки, поскольку оно не создает каких-либо коммитов слияния и не перемещает точку воспроизведения мастера.
Если вы хотите выполнить слияние после перемещения, выполните:
Что будет выглядеть так, если указатель воспроизведения основного устройства заменит указатель воспроизведения функции:
Таким образом, перебазирование не решает проблему слияния, так как вам все равно придется выполнять слияние в конце, чтобы обновить основную ветку. Фактическая команда слияния в конце должна пройти без заминок, поскольку процесс перемещения требует от вас «слияния» изменений, что все еще может вызвать конфликты. И если вы все еще хотите продолжить работу над своей веткой, вам все равно нужно «слить» изменения.
Не перебазировать общие ветки
Помните, как перебазирование копий фиксирует и оставляет застрявшую точку воспроизведения? На самом деле это серьезная проблема, если вы работаете с общим кодом. Допустим, вы создали функциональную ветку и отправили ее в репозиторий, чтобы ваши коллеги могли ее протестировать. Это совершенно нормально, но если один из них захочет отделиться от вашей ветки, когда вы в конце концов перебазируете, вы получите следующее:
Ветка feature2 вашего коллеги теперь ссылается на старую цепочку коммитов. Ваш Git-клиент не может знать об этом, поскольку ветка feature2 хранится на компьютере вашего коллеги. Они также не могут узнать, что вы перебазировались, пока вы не отправите свои изменения.
При перебазировании он не копировал ветку feature2 при копировании всех коммитов. Даже если бы это было возможно, это не повлияет на локальный репозиторий Git вашего коллеги, что приведет к рассинхронизации всего. Решение здесь состоит в том, чтобы перебазировать функцию 2 на функцию в том месте, где она должна быть, но это беспорядочно даже по стандартам Git, и это всего лишь очень простой пример.
Суть в том, что не выполняйте перебазирование, если вы не работаете локально.
Когда перебазирование лучше слияния?
Если разработка вашей ветки займет некоторое время, перебазирование решит проблему «синдрома ветки», когда ваш код слишком устарел по сравнению с работающим мастером, и вам нужно обновить его, чтобы продолжить работу. Вообще говоря, вы должны попытаться избежать этой проблемы, насколько это возможно, но перебазирование может исправить ее, когда она возникает.
Если вы просто вносите небольшие, поэтапные, ежедневные изменения, вам следует вместо этого работать с локальной основной веткой и использовать запросы на извлечение, когда вы будете готовы внести свои изменения. В них используется модель тематических ветвей, созданная специально для хранения вашего кода до его одобрения для слияния.
Но если вы работаете еженедельно и в конечном итоге собираетесь делать несколько запросов на включение и несколько раз выполнять слияние, вы можете немного дольше работать над своим кодом, выполнять локальную перебазировку для обновлений и выполнять одно извлечение просьба в конце сократить количество тестов и общения с руководителями. Перебазирование — это в первую очередь локальная вещь, поэтому вы можете делать это в своих промежуточных ветках, не дожидаясь одобрения.
Если от вашей ветки больше никто не зависит, вы можете перебазировать перед слиянием веток, чтобы сделать историю коммитов чистой и одномерной. Тем не менее, можно возразить, что традиционное слияние, хотя и более уродливое, легче отслеживать и отлаживать, поскольку коммиты слияния полностью неразрушающие. В любом случае перебазирование необходимо выполнить непосредственно перед объединением ваших изменений, иначе вы можете столкнуться с проблемой обновления мастера до того, как ваши изменения будут одобрены.
- › Стоит ли использовать Git-клиент с графическим интерфейсом?
- › Как исправить, изменить или отменить коммиты Git (изменение истории Git)
- › CloudFoundry или Kubernetes: какую облачную платформу выбрать?
- › Как развернуть веб-сервер Caddy с помощью Docker
- › Что будет в React 18?
- › Как использовать Docker для упаковки приложений CLI
- › Что нового в TypeScript 4.6?
- › Как развернуть сервер GitLab с помощью Docker
Читайте также: