Вопросы для интервью | читы git -- совместный конфликт нескольких человек

Git
Вопросы для интервью | читы git -- совместный конфликт нескольких человек

предисловие

Чит-книга врывается во вселенную, так при чем здесь чит-книга? То естьgit秘籍, для начинающихgitтолько знаюgit add .,git commit -m 'commit message',git push origin mainЭти три движения! На самом деле, есть много git's move, достаточно, чтобы вы могли исследовать! Давайте освоим эти читы, чтобы отправиться во вселенную!

Давайте сначала вышлем вам полный список команд git!aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xODA4NzQzNS1iZjJhOTk2ZWY1MGEyMWIwLmpwZw.jfif git общая блок-схема src=http___www.1004619.com_p.php_p=http___img1.sycdn.imooc.com_59c31e4400013bc911720340.png&refer=http___www.1004619.jfif

Суть читов git — многопользовательский совместный конфликт

1. Что такое совместная разработка Git несколькими людьми

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

Как избежать конфликтов кода, когда так много людей разрабатывают совместно?

Мы сначала посмотрим на процесс совместной разработки, чем это!

2. Подготовка к совместной разработке несколькими людьми

  • Создать новый склад
  • Создайте ветку master, то есть загрузите начальный контент проекта в ветку master
  • Члены команды разделяют труд (содержание, ответственное за каждого члена, не должно максимально конфликтовать)

3. Стадия разработки

  • Каждый участник клонирует содержимое главной ветки удаленного хранилища.
  • Выполняйте работу, за которую вы отвечаете, в соответствии с разделением труда

4. Этап фиксации (этап генерации конфликта)

(1) После того, как каждый участник завершит свою работу, ему сначала нужно обратить внимание на изменения на удаленном складе.

Способ 1: потяните удаленную ветку (команда git pull)

git pull指令Его можно понимать как два шага:

  • получить удаленную ветку
  • Объединить выбранную удаленную ветку с локальной веткой

Способ 2: получить удаленную ветку (команда git fetch)

git fetch指令понимание:

  • Получить последнюю версию удаленной указанной ветки в локальную (то есть создать новую ветвь локально с последней версией удаленной указанной ветки)
  • После получения ветки вы можете сравнить и просмотреть содержимое удаленной ветки, а затем, если вы хотите нажать, вы можете выбрать слияние с полученной веткой, а затем нажать.

(2), получите последнюю версию удаленного хранилища и объедините ее локально

Проблемы с конфликтами возникают при слиянии: Конфликты слияния

Производственная ситуация (3 вида):

  • Два человека внесли изменения в разные файлы одного и того же проекта
  • Два человека внесли изменения в разные области одного и того же файла для одного и того же проекта.
  • В одну и ту же область одного и того же файла в одном и том же проекте были внесены разные модификации

Мышление: Итак, какая из трех вышеперечисленных ситуаций будет конфликтной?

Ответ будет раскрыт ниже:

Первые два могут быть автоматически объединены git, а третий случай не может быть объединен автоматически и должен быть объединен вручную (третий вызовет конфликты);

Вопрос 1: Что такое автоматическое слияние?

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

Вопрос 2: Что такое ручное слияние?

Когда Git не знает, какое из двух изменений оставить, ему нужен человек, чтобы принять это решение, и он может выбрать сохранение любого из двух изменений или сохранить их оба. Завершение вышеупомянутых решений — это то, для чего нужны ручные слияния.

Вопрос 3: Почему мне нужно выполнить слияние вручную?

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

(3) После слияния вы можете самостоятельно загрузить (git push) на удаленный склад.

5. Просмотр этапа

  • Администратор просматривает код и объединяет его с основной веткой, если проблем не обнаружено. Администратор должен завершить этот процесс как можно скорее, чтобы гарантировать, что участники получат последнюю версию.

  • Конфликты также могут возникать во время процесса слияния администратора, и администратору необходимо связаться с участниками, чтобы понять ситуацию, а затем выполнить слияние вручную.

  • Роль администратора:

Поддерживайте основную ветвь удаленного репозитория, включая следующее:

  • Проверьте код каждой ветки-члена на наличие проблем
  • Объединить код из ветки-члена в основную ветку
  • Когда возникает конфликт слияния, выполните слияние вручную

6. Разрешение конфликтов

1. Виды конфликта

логический конфликт

автоматическая обработка git (слияние/применение исправлений) выполняется успешно, но логика ошибочна.

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

Другой пример, значение возвращаемого значения функции меняется, но я все еще использую старое значение, эта ситуация автоматически обрабатывается успешно, но могут быть скрыты серьезные ошибки.

Такого рода проблемы в основном гарантируются автоматизированным тестированием. Поэтому лучше иметь возможность написать относительно полный автоматизированный тестовый пример.

Решением этого конфликта является исправление ОШИБКИ. На самом деле не разрешает конфликты, о которых сообщает git.

Контент конфликт

Два пользователя изменяют одну и ту же область одного и того же файла, и git сообщит о конфликте содержимого. Это то, что мы часто видим, и последующие решения в основном нацелены на такого рода конфликты.

конфликт дерева

Измените конфликт имени файла, называемый конфликтом дерева. Например, пользователь переименовал файл a.c, пользователь b переименовал тот же файл, что и b.c, а затем b, когда две фиксации слияния создают конфликты. Если доработать b.c, то решение будет следующим:

git rm a.c
git rm origin-name.c
git add b.c
git commit

При выполнении первых двух git rms будет выдано предупреждение «имя файла: требуется слияние», и вы можете их игнорировать.

Разница между git rebase и git merge при слиянии

1339683149_4793.jpg

Когда операция слияния сталкивается с конфликтом, текущее слияние не может быть продолжено. После изменения конфликтующего содержимого вручную добавьте модификацию и зафиксируйте. Операция перебазирования прервет перебазирование и предложит разрешить конфликт. После разрешения конфликта выполните git rebase --continue после изменения добавления или git rebase --skip, чтобы игнорировать конфликт.

2. Перебазировать

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

git pull и git pull --rebase

  • git pull = git fetch + git merge

  • git pull --rebase = git fetch + git rebase

git pull --rebase, здесь означает отменить каждый коммит (commit) в вашей локальной текущей ветке и временно сохранить их как патчи (patch) (эти патчи помещаются в каталог «.git/rebase»), затем обновить локальный текущую ветку в последнюю ветку «исходная» и, наконец, примените сохраненные исправления к локальной текущей ветке

конфликт 1

когда тыcommitПозже, при выполненииgit pull –rebaseПри возникновении конфликта выполните следующие действия, чтобы разрешить его:

  • 1 Сначала найдите конфликтный файл и разрешите конфликт
  • 2 Выполните git add xxx (xxx — это полный путь к файлу конфликта)
  • 3 Выполнить git rebase – продолжить (конфликт слияния)
  • 4 Выполните git pull --rebase
  • 5 Выполнить git push

конфликт 2

Когда у вас есть модификации локально, вы выполняете git stash, а затем загружаете последний код с сервера (git pull --rebase), возникает конфликт, разрешите его следующим образом:

  • 1 Найдите конфликтный файл и разрешите конфликт
  • 2 Выполните git add xxx (xxx — это полный путь к файлу конфликта)
  • 3 git commit
  • 4 git вытащить --rebase
  • 5 git push

Когда мультиплеер разрабатывается одной и той же удаленной ветвью, если вы хотите сгладить Push без автоматического создания Merge Commital, рекомендуется действовать в следующем порядке при каждой отправке:

//git stash 能够将所有未提交的修改（工作区和暂存区）保存至堆栈中，用于后续恢复当前工作目录。
git stash
git pull --rebase 
git push
//git stash pop 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。将暂存文件取出，与pull的文件对比
git stash pop

3. Откат (сброс и возврат)

git reset (сброс)

Разница между git reset --hard и git reset --soft

  • git reset --soft: вернуться к определенной версии (已经git add的), откатывается только информация фиксации, и она не будет восстановлена ​​до уровня файла индекса. Если вы все еще хотите отправить, просто зафиксируйте напрямую;

  • git reset --hard: полностью откатиться на определенную версию, локальный исходный код также станет содержимым предыдущей версии, а изменения, содержащиеся в отозванном коммите, будут смыты;

в:A а также Bявляется обычным коммитом, в то время какCа такжеD отправлена ​​ошибка. Теперь мы хотим поставитьCа также Dотвали. В настоящее время,HEAD указатель наD представить（5lk4er）. Нам просто нужно поставитьHEAD указатель перемещается на Bпредставить（a0fvf8）, цель может быть достигнута.

Итак, каков порядок? То естьgit resetЗаказ

1.git reset --hard
//git reset --hard <commit_id>

git reset --hard a0fvf8

После выполнения командыHEADуказатель переместится наBпредставить под

image.pngВ это время удаленный складHEAD Указатель остается прежним, по-прежнемуD Отправить дальше. Итак, если вы напрямую используете git pushкоманда, не сможет отправить изменения в удаленный репозиторий. В настоящее время вы можете использовать только -fВозможность принудительно отправлять коммиты в удаленное репо

git push -f

Очевидным недостатком отката кода таким образом является то, что он делает HEADУказатель перемещается назад, и последующие фиксации теряются. Если вдруг обнаружат в будущем,C а такжеDКакая замечательная идея, но они уже давно исчезли в длинной реке истории.

2. git сброс --мягкий

//git reset --soft <commit_id>
git reset --soft a0fvf8

пример:

Принцип: Функция git reset состоит в том, чтобы изменить позицию HEAD, то есть изменить позицию, на которую указывает HEAD, на предыдущую версию, как показано на следующем рисунке, предполагая, что мы хотим вернуться к версии 1:

image.pngПрименимые сценарии: если вы хотите восстановить ранее отправленную версию, и мы не хотим, чтобы версия была отправлена ​​после этой версии, вы можете использовать этот метод.

git вернуться (отменить)

git revertЭффект обратного действия создает новую версию с тем же содержимым, что и целевая версия, к которой мы хотим вернуться, ноHEADУказатель указывает на эту вновь сгенерированную версию, а не на целевую версию.

использоватьgit revertкоманду для реализации приведенного выше примера, мы можем сделать это:revert D,Опять такиrevert C(Если есть несколько коммитов, которые необходимо откатить, это нужно сделать от нового к старому.revert):

// 1 revert D
git revert 5lk4er
// 2 revert C
git revert 76sdeb

Затем генерируются два новых коммита:D'а такжеC' image.pngЗдесь требуется только два коммитаrevert, мы можем вернуться один за другим. А если их десятки? Откат по одному определенно неэффективен и подвержен ошибкам. Мы можем сделать массовый откат, используя:

git revert OLDER_COMMIT^..NEWER_COMMIT

В это время неправильная подачаCа такжеDОн все еще зарезервирован, и в будущем будет время, когда придет время сбросить банк. Более того, если вы сделаете этоHEADУказатель перемещается назад и может использоваться напрямуюgit pushКоманды отправляются в удаленный репозиторий. И именно такой подход поощряет компания.

примерПринцип: git revert используется для «отмены» определенной версии для достижения цели отмены модификации версии. Например, мы закоммитили три версии (версия 1, версия 2, версия 3), и вдруг обнаружили, что версия 2 не работает (например: есть баги), и хотим отозвать версию 2, но не хотим влиять коммит отзыва версии 3, мы можем использовать команду git revert, чтобы отменить версию 2 и создать новую версию 4. В этой версии 4 содержимое версии 3 будет сохранено, но содержимое версии 2 будет отозвано. Как показано ниже:

image.pngПрименимые сценарии: если мы хотим отозвать предыдущую версию, но хотим сохранить версию после целевой версии и записать весь процесс изменения версии, мы можем использовать этот метод.

Ссылка на статью:Git может восстановить предыдущую версию двумя способами: сброс и откат (подробное изображение и текст)

сайт практики команд git

Веб-сайт, который может сообщить мне, что происходит после выполнения каждой команды (вы можете воспроизвести его, если вам интересно)Изучите Git Branching, сайт для практики команд git

отображение страницы сайта image.png Например: попрактикуйтесь в вопросе

image.png Знакомство с git rebase image.png git rebase main не выполняется
image.png Выполнить git rebase main image.png git rebase bugfix не выполняется

image.png Выполнить git rebase bugFix

image.png Советы по работе с вопросами image.png Знакомство с интерфейсом ответа на вопросы image.png ОтвечатьВведя команду, мы можем заметить, что древовидная диаграмма справа изменится, что позволит нам лучше понять команду git.

image.pngСледующие все желающие могут ввести команду git, чтобы попробовать в соответствии с ответом, я не буду отвечать на них по очереди для всех! Если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение в разделе комментариев!

//新建并切换到bugFix分支
git checkout -b bugFix 
//提交一次
git commit
//切换到main分支
git checkout main
//提交一次
git commit
//再次切换到bugFix分支
git checkout bugFix
//rebase 到 main
git rebase main

Суммировать

Это также первое знакомство с git совместной работой нескольких человек, ведь студенты не сталкивались с этими проблемами в своей работе. Если есть какая-либо проблема, пожалуйста, помогите мне указать на нее, я изменю ее вовремя, заранее спасибо!

Некоторые из изображений выше украдены, если есть какие-либо нарушения, пожалуйста, свяжитесь со мной!

本人大三正在学习前端！

Категории