Что правильнее: git merge master VS git rebase?

1. «Контроль версий» ≠ «бэкап всего подряд»

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

В Git философия другая:

• долговечность обеспечивается не тем, что коммиты никогда не переписываются, а тем, что важные состояния помечаются именованными ссылками: ветками, тегами, релизными ветками;
  
• всё остальное считается рабочим черновиком, который может жить ограниченное время.
  

Если состояние важно «на 100%» (релиз, хотфикс, состояние «как в проде на дату X»), его фиксируют тегом или отдельной веткой.
Тогда rebase в личных ветках эту официальную версию не трогает вообще.

2. Про «уничтожение истории» и старые коммиты

Вы говорите:

когда вы сделали ребейз и поменяли базу, этого коммита уже нет в ветке

Тут мы просто используем разные уровни абстракции.

• Ветка — указатель на коммит. Rebase двигает указатель, а не «вычищает сейф».
  
• Объекты-коммиты живут в хранилище до тех пор, пока их не уберёт сборщик мусора — и это происходит в любом случае, независимо от того, был rebase или нет, если до них нет ссылок.
  

То есть «вечного архива всех когда-то созданных коммитов» в Git нет по определению, даже без rebase.
Чтобы превратить что-то в вечную версию, это надо осмысленно пометить (ветка, тег, ссылка в баг-трекере).

Фактически вы обижаетесь не на rebase, а на сам дизайн Git:
хранилище отделено от витрины, и витрину задают ссылки.

3. Где мы реально расходимся

Разница в ожиданиях:

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

Отсюда политика:

• защищённые ветки (main, release/*) не переписываются — здесь мы полностью согласны;
  
• личные и feature-ветки до merge можно причесывать rebase’ом или squash’ем — это не официальная история, а черновики.
  

Вы всё время спорите с ситуацией «кто-то делает rebase общей ветки».
Но это никто и не предлагает — это действительно вред и так делать нельзя.

Обсуждается другое:
feature → несколько грязных коммитов → интерактивный rebase → чистая линейная история → merge в main без переписывания main.

Тут нет «потери версий месяц назад»: важные версии живут в тегах и релизных ветках.

4. «Это не контроль версий, а косметика»

Контроль версий — это:

• понимание, что и когда изменилось;
  
• возможность найти версию, ушедшую в релиз или хотфикс;
  
• воспроизведение состояния репозитория.
  

Rebase по feature-веткам этому не мешает:

• релизы помечаются тегами;
  
• хотфиксы лежат в защищённых ветках;
  
• SHA релизных коммитов никто не переписывает.
  

А вот читать историю после rebase проще:
вместо пятнадцати «fix typo» и «oops» — три нормальных осмысленных шага.
Ревью такой истории всегда легче.

5. Про «месяц назад» и «отказ от контроля»

Ваш пример:

— Можно вернуться к версии, которую мы видели месяц назад?
— Нет, но есть похожая…

Если версия была важна, её фиксируют тегом или SHA. Тогда ответ будет:

Нужен прод на 2025-10-31? Вот тег v1.2.3, checkout.

Если же речь о промежуточном черновике без ссылки и без контекста — это не «версия», а случайное состояние.
Git никогда не гарантировал бессмертия таким объектам.

6. Итог

• В защищённых ветках никто не делает rebase. Тут мы полностью согласны.
  
• В feature-ветках до merge rebase и squash — нормальная, рабочая практика, которая не мешает контролю версий, если версия определяется ссылкой (тегом), а не каждым промежуточным коммитом.
  
• Git устроен так, что объекты живут отдельно, а историю задают ссылки.
  Спор о «правильности» rebase — это спор о вкусе команды, а не о корректности инструмента.
  

Вы выбираете модель «каждый коммит неприкасаем».
Я выбираю модель «официальная история аккуратная, мусор не тянем в музей».
Обе модели рабочие — просто применяются в разных местах.

Какие технологии/ИИ есть для клонирования русской речи?

vgxot, а е́сли вручну́ю проставля́ть ударе́ния, он понима́ет?

Почему при попытке сделать "git push" выдает ошибку?

Dmitry, ну тут очевидно, что это только-что созданная тематическая ветка. Скорее всего даже пустая, а на гитлабе её ещё нет → значит нет прав на создание ветки.

Почему при попытке сделать "git push" выдает ошибку?

Да, замените картинку обычным текстом. Он легко из терминала копируется и ретушировать бы не пришлось..

Что правильнее: git merge master VS git rebase?

Сами же дальше пишете "удаление", а тут какая-то "витрина".

Вы путаете хранилище и указатель. Ветка в Git — не сейф, а стрелка на коммит. При rebase вы двигаете стрелку, а не трогаете объекты. Коммиты остаются в базе — те же SHA-1, те же данные.

«Витрина» — это метафора для текущей истории ветки. Если вам нужен «архив всех опечаток» — Git его хранит. Но показывать его в основной истории — всё равно что выставлять в музее черновики с зачёркнутыми словами вместо финальной рукописи.

Повторюсь, ребейз это про "красивую" картинку

Если для вас история проекта — «картинка», то вы явно не пишете код, а коллекционируете артефакты. Для разработчиков rebase — не косметика, а хирургия:

• убирает шум (промежуточные фиксы, неудачные эксперименты);
  
• сохраняет логику (каждый коммит — осмысленный шаг);
  
• упрощает ревью (линейная история читается как книга, а не как лабиринт).
  

когда вы сделали ребейз и поменяли базу, этого коммита уже нет

Потому что ветка — ярлык, а не склад. Коммиты никуда не деваются: reflog и object database всё помнят.

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

Git — это инструмент для управления историей, а не для её мумификации. Если вам нужно, чтобы каждый коммит был «неприкасаемым артефактом», — да, Git вам не подходит.

Но тогда, может, вам стоит перейти на Mercurial? Он как раз для тех, кто боится переставлять стрелки и верит, что «история должна оставаться такой, какой её написали в первый раз». Git управляет историей. Mercurial её хранит. Поэтому одни делают релизы, а другие пишут манифесты о «неприкасаемости коммитов».

Мы же продолжим работать с инструментом, который позволяет делать историю полезной, а не просто «честной».

Что правильнее: git merge master VS git rebase?

Созданные коммиты уничтожаются и записываются новые.

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

Если вы всегда "на стреме" и записываете хеш аварийного коммита

Зачем мне быть на стрёме? Гит никогда ничего не удаляет и все ходы записаны в журнале. Легким движением руки можно легко откатиться на момент до неудачного слияния и rebase.

За исключением ситуации, когда прошло время и неиспользуемые коммиты git уже вычистил

Мне трудно представить такую ситуацию, что через месяц захочется покопаться в мусоре и снова пересобрать старые косяки. Обычно проблемы видны сразу.

все это, запрещают делать в важных ветках, где нужен контроль версий.

Контроль версий происходит во всех ветках. А важные мы защищаем от удаления.
Так как rebase это именно удаление и пересоздания на новом месте. Если это делать с общей веткой, то придется всех коллег заставлять тоже удалить у себя эту ветку и создать на новом месте, куда она перекинется. Никто не будет этим страдать и поэтому защищают ветки.

Что правильнее: git merge master VS git rebase?

а сам факт уничтожения истории в системе контроля версий порождает вопрос, а зачем тогда вообще контроль версий?

Чтобы управлять историей, а не хранить её в виде археологических слоёв.
Rebase не «уничтожает» историю, а переписывает её так, чтобы она оставалась линейной и читаемой.
Git — не архив, а инструмент. И да, rebase — часть нормального рабочего процесса, если понимать, когда и зачем его применять.

если чтото не так смержили при ребейзе выковыривать придется из удаленных

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

ребейз не применим, если вы не один пользуетесь веткой. А если один, то всё на вашей совести

Как раз наоборот: когда вы работаете с веткой один и ленитесь причесать историю через интерактивный rebase перед отправкой в вышестоящий репозиторий — вот тогда это действительно остаётся на вашей совести. ))

Как в Eclipse делать автоматический pull исходной ветки перед созданием новой из нее?

Павел, пользуются. Вон 1С почему-то выбрали Eclipse, чтобы лепить из него свою IDE.
Ещё рассказывали, что в Apple на нем пишут Java-код.
Не спрашивайте зачем ))

1С EDT: можно ли в качестве удаленного репозитория использовать расшаренную по локальной сети папку?

1. Не надо использовать расшаренную папку в качестве репозитория

Всё так. Git создан для работы в локальной файловой системе.
Но в вопросе такого и не предполагалось ))
Коммитим, конечно же, всегда локально.

любой сервер на linux, к которому можно подключиться по ssh

По сути та же шара, просто сетевой протокол другой. Тоже будет работать нормально.

Как безопасно, выборочно извлечь файлы/папки из одной ветки (сохраняя историю) и переместить в другую?

Почему не стоит использовать git filter-branch

• Устарел инструмент. Рекомендуемая замена — git-filter-repo.
  
  
• Медленно. Параметр --tree-filter запускает команду для каждого коммита, на больших репозиториях это крайне долго.
  
  
• Риск порчи истории. Легко удалить не тот путь или получить некорректное дерево.
  
  
• Переименования не учитываются автоматически. Историю по файлу можно «порезать».
  
  
• Лишние артефакты. После раздельных фильтраций и последующего merge получаются синтетические коммиты, которых не должно быть.
  
  
• Полная перепись SHA. Неизбежно в любом фильтре, но filter-branch чаще ломает ссылки, теги и подписи; чинить неприятно.
  

Как безопасно, выборочно извлечь файлы/папки из одной ветки (сохраняя историю) и переместить в другую?

Получу отдельную ветку для m.txt

Для чего? Историю изменения одного файла можно просмотреть в любой момент командой log или в нормальном GUI от JetBrains. Для чего ещё вам может понадобиться такая ветка?

Сама задача разрешима, и даже есть в голове пару способов это сделать. Но сначала хочется проверить у себя.

Как безопасно, выборочно извлечь файлы/папки из одной ветки (сохраняя историю) и переместить в другую?

historydev, но вы нарисовали как раз объединенную историю.
Вы хотите из трех историй изменения файла собрать одну, с итоговым четвертым состоянием файла, в котором будут изменения из всех веток.
Задача немного прояснилась, но не совсем понятно зачем вам эта синтетическая история понадобилась. Что оно вам даст?

Как безопасно, выборочно извлечь файлы/папки из одной ветки (сохраняя историю) и переместить в другую?

Какое содержимое m.txt должно быть в ветке W? Финальная версия из X, из Y или объединённое состояние?

При подключении к windows сервер через RDP с Mac OS не передается микрофон в чем проблема?

Semenov88, Какой макбук и какая macOS?
И что именно вы называете штатным приложением макбука? Не припомню такого.
Помню как-то было приложение от Microsoft, глючное и кривое, и было альтернативное от сторонней компании.
Потом Microsoft их выкупили и переименовали в Microsoft Remote Desktop. Сейчас эту программу переименовали в Windows App.

Можно ли обновить макос на sonoma вместо sequoia?

netovich, разумеется все обновления продолжат приходить

При подключении к windows сервер через RDP с Mac OS не передается микрофон в чем проблема?

Я так работаю. С макбука или с телефона подключаюсь к рабочему Windows.
Проставлено чтобы звук проигрывался на клиенте и обязательно пробросить микрофон.

Но на звонках получается эхо с моим голосом. Не понял как побороть пока.

Как удалить старые конфиги Homebrew?

Достаточно сделать
brew cleanup --verbose

Как исправить ошибку "src refspec master does not match any"?

Странно задавать новые вопросы в ответах к другим вопросам.

Почему в idea intellij сменился вид записи, и как его вернуть назад?

Среда разработки сама не правит ваш код, если вы сами не попросили.
Проверяйте настройки
Preferences ➜ Tools ➜ Actions on Save

Editor ➜ Code Style ➜ снимите галочку Enable EditorConfig support

как вернуть все как было с учетом того что я не могу изменять этот код.

Откатить нежелательные правки вытащив исходный файл из истории Git, например.

Как загрузить пакет с приватного репозитория?

Елена, чтобы написать ваше решение как ответ. Почему то вы сами это не стали делать. Вопрос не должен оставаться без решения.