Почему при попытке сделать "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, например.

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

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

Как изменить дату создания коммитов?

Вам хочется поменять дату коммитов якобы они сделаны не вчера, а сегодня? Или наоборот. Из формулировки вопроса не очень понятно.

Как вернуть коммиты после rebase?

-git commit --amend --no-edit + git rebase --continue

Вы своим amend перенесли все правки из текущего коммита в предыдущий.
Последующий continue видит что текущий коммит стал пустой и не добавляет его в историю.

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

Как раз именно с этим и связано. Подробнее написал в ответе.