Объясните про Git?

Как можно смерджить ветки, если они будут содержать разный код? Получается Линусу нужно выбрать какую-то версию?

Если ты про сам принцип git, то да, условному Линусу придется выбрать версию, или объединить две самому, вручную.

Например было

printf(«Hello»);

Первый патч сделал

printf(«Hello World»);

А второй сделал

printf(«Hello!»);

Линус может либо выбрать что то из двух, либо сам сделать вот так:

printf(«Hello World!»);

В IDE есть инструменты для разрешения конфликтов: https://resources.jetbrains.com/help/img/idea/2024.3/conflict_resolution_tool...

git commit это наподобии Сохранить в блокноте?

Пишу в mcedit. Если б он умел выводить подсказки по функциям, структурам, было б вообще прекрасно :)

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

git commit это наподобии Сохранить в блокноте?

Да, а потом можно отменить коммит как Ctrl+Z.

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

Пишу в mcedit. Если б он умел выводить подсказки по функциям, структурам, было б вообще прекрасно :)

В CLion есть различные подсказки и встроенные советы по коду. И интерфейс для разрешения конфликтов git.

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

Если патч, который ты пришлёшь в список рассылки не будет ложиться на текущее состояние дерева (т.е. не будет совместим со всеми принятыми перед ним патчами), то его просто отклонят. Линус действительно мёржит ветки, но это ветки мейнтейнеров, содержащие принятые и проверенные патчи, а не всё подряд от левых чуваков

все конфликты решены мейнтейнерами

Нормальный мейнтейнер не будет решать никакие конфликты. Твой патч не ложится — значит, ты должен его отребейзить и решить конфликты сам. А вот при слиянии веток от разных мейнтейнеров конфликты могут легко возникнуть, если менялся общий код для разных подсистем, и заранее это предусмотреть не получится из-за масштабов проекта. Для этого нужен Линус.

почитай, как работает трехстороннее слияние (3-way merge).

Предположим что ты склонировал репозиторий ядра, отпочковал свою ветку branch от master, напилил туда своих коммитов, и шлешь их Линусу.

Линус пулит себе твою ветку, переключается на master и выполняет команду git merge branch. Эта команда

• находит коммит, который является наименьшим общим предком для последних коммитов в master и branch. Пусть это коммит base.
• начинает сравнивать все файлы в base и последних коммитах master и branch.
• если для какого-то файла master != base == branch, то гит применяет изменения из master
• если master == base != branch, то применяются изменения из branch
• если master != base != branch, то налицо конфликт слияния, который гит предлагает разрулить Линусу самостоятельно.

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

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

Версия (коммит) это, можешь считать, полная копия всего проекта. Ветки это связи между этими копиями, какая из какой произошла.

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

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

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

GIT - система контроля версий. Принцип в том, что часть кода из ветки удаляется,а часть заменяется. Ее используют в SF.net, в ядре итд. С помощью команд push итд.

https://git-scm.com/book/ru/v2