git вернуться к предыдущему коммиту, а затем обратно?

бранчи отменили уже?

Сделай отдельный worktree для компиляции

И в чём проблема?

У негросетей спроси. Цельную ветку создавать из-за такой херни

Это из-за того что git reset раннее делал. Сделал git reset --hard.

Всё получилось, благодарю!

Самый простой способ, как чуть выше подсказали, сделать отдельный каталог с рабочим кодом и отдельный для сборки. Это избавит от головной боли с жонглированием стешами, бранчами и прочим, если хочется тупо тудой-сюдой переключаться. Используй worktree или просто склонируй то же самое в другом каталоге. Разницы нет, тот же коммит в другой руке.

git switch -

а оно уже перестало быть экспериментальной фичей?

Git не позволяет сделать checkout, потому что у тебя есть несохранённые изменения, которые будут перезаписаны при переключении на id1. У тебя есть два варианта.

Вариант номер раз:

# убираем под ковер текущие изменения (stash - убрать в стол, грубо говоря")
git stash push -m "temp before switching to id1"
git checkout id1

# Билдим че там у тебя есть, допустим через мейк
make

# Потом копируем куда-нить бинарь
cp path/to/binary /tmp/my_binary_id1

# Вернуться обратно и восстановить изменения
git checkout id2
git stash pop

Второй вариант: тупо идти вперед. Можно потом потереть лишний коммит.

git add .
# WIP = work-in-progress
git commit -m "WIP: изменения перед сборкой id1"
git checkout id1

git switch -

а оно уже перестало быть экспериментальной фичей?

Не знаю, но мне это сам гит предлагает в ситуации с отстегнутой башкой.

Рекомендую почитать любое руководство или книгу по Git. Их сейчас 100500 на любом языке, любого уровня сложности, хоть по базам, хоть как воссоздать Git из «говна из палок» (написать git на bash, работать с репозиторием через команды cat и echo).

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

Это просто основы основ git, то, что вообще не требует особого напряжения извилин. А если тебе придётся столкнуться с rebase или bisect, скажем, то на твоём уровне тебе просто не хватит познаний, чтобы понять, как с ним работать.

git switch

reset --hard потрет все к чертям. Не знаю, может тебе это и нужно было. Но еще для таких случаев полезен git stash

$ git stash
$ git checkout COMMIT
$ cc hackery.c
$ git checkout BACK-TO-BRANCH
$ git stash pop

Я недолюбливаю git stash. В частности, за то, что он не синхронизируется.

Например, я на рабочем ноуте сделал git stash, забыл вручную как-то синкануть, уехал на дачу, открываю свой репозиторий - а изменений-то и нет.

Потому, в последнее время я делаю чаще так:

git switch -c branch-for-unfinished-changes
git add .
git commit -m WIP
git push

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

Как вариант. Для каждой проблемы свой инструмент.

Просто checkout же, зачем switch ещё?

Для разнообразия и расширения кругозора.

Я подобным образом и работаю, под сборочные дела отдельного юзера завёл, а код под гитом у основного юзера. Делаю коммит, например, и дальше git format-patch, копирую патчи в сборочное дерево, правлю PKGBUILD и собираю. Но от жонглирования бранчами это не помогает, обычно работа идет параллельно с несколькими бранчами :) Когда добьюсь желаемого, солью все наработки в master и сделаю один большой патч.

Мне нравится идея с отдельным юзером.

У меня сборка промежуточных билдов вынесена вообще на неттоп. Там крутится импровизированный CI/CD на башскриптах и имитация воркспейсов как в дженкинсе. Грубо и топорно, но надежно как швейцарские часы ))

лучший совет в топике. но глядя на то, как тс не осилил бранчи, это будет вообще неприподъёмной задачей..

Это из-за того что git reset раннее делал. Сделал git reset –hard.

Сто бед — один ресет) Главное помнить, что git reset это одна из тех немногих команд в гите, которые могут привести к необратимой потере данных.