Случайно удалил файлы

Сочувствую. Но всего этого можно было избежать, просто сделав git checkout -b some_name, и уже там делать git revert. А так, это потенциально опасная для данных команда, и лучше, имхо, её применять именно для отдельных коммитов. А ещё лучше – пользоваться git stash, git restore some-file.

Это не гит, а revert в данном случае - откат локальных правок, а не коммитов. Избежать можно, добавив в revert проверку игнорлистов, что конечно будет сделано.

Но внимательнее относиться к «потом закоммичу» тоже следует.

Нормальный GUI типа Git Extensions делает stash автоматом.
И на мой взгляд использовать git из командной строки без весомой на то причины - неправильный подход.

использовать git из командной строки

Дак тут и нет гита вообще жи..)

И на мой взгляд использовать git из командной строки без весомой на то причины - неправильный подход.

Я думаю автор пишет код в ed.

С телетайпа, чтоб совсем тру? Ну не нащелкивать же тумблерами на панели, действительно...

У меня для исходников написан инструмент, периодически жму хоткей, получаю очередную копию с индексом 1, 2, 3 и т.д. Можно настроить с временем в имени, можно в текущей папке относительный путь для проекта, можно в абсолютный путь для всех.

Такие инструменты называются системами контроля версий. Только обычно они кроме делания копий могут ещё и удобную навигацию по ним делать потом и некоторый анализ. Тоже пишу такую штуку. А ещё есть уже написанные другими людьми: cvs, svn, git и другие. Но у них есть разные недостатки.

Только обычно они кроме делания копий могут ещё и удобную навигацию по ним делать потом и некоторый анализ

Тогда чего у тебя файлы пропадают? Уж исходники то не скачать, поэтому я за каждым добавленным функционалом 1-4 часа работы делаю бэкап. Сравнить я могу любой программой сравнения. Доверять какой-то проге без сомнений, которая может слить в трубу я бы не стал не проверив на чём то не значащем. А то что я сам писал уверенно пользуюсь не думая какую подставу мне может сделать чей-то комбайн.

Пропали потому что я сознательно настроил всё так чтобы конкретно эти файлы не «копировались». Это не недостаток системы, это скорее недостаток того как я настроил. Если бы я ничего не настраивал и использовал работу по умолчанию - их копии бы были. Впрочем, вариант делать копии с этих файлов мне всё равно пока что не нравится, по другим причинам.

А то что я сам писал уверенно пользуюсь не думая какую подставу мне может сделать чей-то комбайн.

Так я тоже сам пишу чтобы не зависеть от чьих-то странных решений.

Я думал, такие динозавры уже вымерли. CVS придумали около 30 лет назад* и уже в 2000 году на программистов, которые его не использовали для разработки, смотрели странно. А сейчас 2026.

* Ого, в 1990, 36 лет назад.

Хорошо по эпохе сочетается с приложениями на Basic.

Да, а учитывая

А то что я сам писал уверенно пользуюсь не думая какую подставу мне может сделать чей-то комбайн.

и

Так я тоже сам пишу чтобы не зависеть от чьих-то странных решений.

возможно, увидим, битву двух ёкодзун.

Почему битву? Может он как увидит моё vcs так и перейдёт на него.

Нет, он будет писать, что не нужно, ты - что нужно и непременно твоё, а твоё будет идти вразрез с его мировоззрением «не думая какую подставу мне может сделать чей-то комбайн», ну и завертелось :))

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

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

Ещё пример, я в исходник встраиваю поддержку многоязычности и обновляю оригинал я русскоязычный исходник, так вот когда я добавляю функционал, новые константы, новые параметры из ini-файла и потом встаёт вопрос, как мне новьё импортировать в многоязычный исходник, методом сравнения, где вместе с обновлениями идёт куча переведённых строк и чуть ли не заново весь исходник штудируешь или прогой встройки языка, но там тоже нюансы, много ручной работы добавлено. В общем я старый исходник просто забываю, он лежит не для того чтобы делать контроль версий, а во первых добавленная фича лажает и я смотрю как было в старой версии, то есть конкретный функционал, во вторых случайно выключился комп во время сохранения и от файла остался бинарник с забитыми нулями. Всё, никакой контроль версий мне не нужен.

Всё, никакой контроль версий мне не нужен.

Да и интернет не нужОн :)

Наказали за ретроградство. Выводы делать будешь из этого или до следующего revert?

Я ж уже написал - revert я пофикшу чтобы он учитывал игнорлисты.

При чём тут ретроградство вообще непонятно.

Минутка философии. Не закоммичено - значит не очень нужно. Не в git, а в какой-то нёх - значит вообще не нужно.

Может он как увидит моё vcs так и перейдёт на него.

Может. Если расскажешь в чём преимущество. Простота иногда понятней и надёжней (копирование файлов, которое может понять даже не программист, я и предлагал не программистам на других форумах). На оф.форуме моим функционалом тоже не пользуются, хотя когда я рассказал о своём варианте чел поднял тему и обновил свой функционал, но он работает с проектами, то есть файл-проект и куча файлов и делает снимок всех файлов. Я не делаю проекты, у меня всегда один исходник и инклуды, для меня проект пока кажется излишним функционалом, на самолёте за хлебом, если до расту до исходников, которым нужен вид проекта, тогда может и попробую его функционал, или свой напишу под текущую ситуацию.

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

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

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

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

И на мой взгляд использовать git из командной строки без весомой на то причины - неправильный подход.

Почему?

К сожалению с рекавери у Linux традиционно всрато, в отличие от.

Инструменты для восстановления случайно удаленных файлов делятся на две категории: первая категория не подходит, потому что не восстанавливает пути; а вторая категория не подходит, потому что ей ну вот срочно нужен отмонтированный раздел.

Бикапи это конечно клёва, но если твой бикап делается в 12:00, а тупой девелопер случайно файлы в 11:45 - не спасут. А учить вебмакак делать бэкап перед началом своей работы - практически нереально.

- - -

Почему не сделать нормальный, человеческий механизм восстановления нативной тулзой для ФС - ума не приложу. Наверное у разрабов ext4\xfs одна болезнь с чудаками из Oracle\и прочих MariaDB - те тоже в упор не хотят делать нативные инструменты для восстановления недозаписанных innodb.

Для гита есть гуи?! А нахрена?

Но в комментарии, на который я отвечал, написано именно про git. Кроме того я такого же мнения и по остальным VCS. Всегда использовал GUI в первую очередь.

Применительно к git - там немало команд с неочевидным поведением, осложненных тем, что ключи по умолчанию - небезопасны/отличаются от типичных ожиданий пользователя. GUI помогает избежать «выстрела в ногу». В первую очередь пользователям, которые привыкли работать с GUI, но по каким-то неведомым причинам с git пытаются работать через интерфейс командной строки.

Применительно к VCS вообще - командная разработка обычно всё-таки ведется через приложения с GUI. Почему работа с VCS тут должна быть исключением?

Признаю, что интерфейс гита неудобен и GUI действительно помогает. Но это дефолтный интерфейс. Мне всегда казалось, что это lingua franca. Если понимаешь его — понимаешь других разработчиков, гайды в интернете, можешь поделиться командой. В общем, деваться некуда.

Базовый набор команд можно ограничить. Все эти soft/hard reset — я ни разу ими не пользовался.

командная разработка обычно всё-таки ведется через приложения с GUI

Вроде, вообще не обязательно. Только веб нужен.

Все эти soft/hard reset — я ни разу ими не пользовался.

git reset --hard очень полезная команда, когда ты случайно сильно намусорил/напортил в рабочей копии и хочешь всё откатить без лишних вопросов.

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

Я полагаю, что следует владеть терминологией git в рамках git reference, но при этом не стоит использовать shell-команды в повседневной работе. Банально, забудешь амперсанд в строке заэкранировать, и последстия будут весьма неожиданными ;-)

Вроде, вообще не обязательно. Только веб нужен.

Гм, а веб это не GUI? Или ты в багтрекер через lynx ходишь?

Чем это лучше последовательности

mkdir -pv project_name
cd project_name
git init
git add . # создаём структуру будущего проекта -- дерево каталогов
nano main.c # пишем первый исходник
git add main.c
git commit -m "main.c: initial version" # фиксируем изменения

И тут понимаем, что накосячили в main.c. Есть несколько вариантов решения. Можно создать целую новую ветку командой git checkout -b main-fixes, внести исправления в файл там, а потом влить изменения в основную ветку. Но можно отменить изменения с помощью git reset, внести правки и закоммитить их, причём, можно сделать как «мягкую» отмену изменений (ключиком ‘–soft’), при этом файл останется как есть, отменится только то, что он был записан в коммит, так и «жёсткую» (ключиком ‘–hard’), при этом файл вернётся к указанному предыдущему сохранённому состоянию и отменится его запись в коммит. Можно задать глубину отмены, при этом состояние, которое было, будет сохранено в reflog, и при необходимости можно восстановить это состояние. Git – мощная штука, и тем, кто работает с кодом, просто необходимо уметь пользоваться им. Читайте документацию, а не изобретайте костыли на велосипеды.

нажать хоткей

Чем это лучше последовательности

Эм, очевидно же чем. Хоткей нажимается за 1 секунду. Хотя я не сторонник хоткея (лично для себя).

Увы, такое рано или поздно происходит с большинством пользователей ПеКа.

Лично я не одну ночь провёл, пытаясь восстановить утраченные данные. И под оффтопом, и под онтопом.

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

Лично я не одну ночь провёл, пытаясь восстановить утраченные данные. И под оффтопом, и под онтопом.

Вот этого не приходилось делать, в смысле, ночью не спать. Не, я там понимаю, если надо презентацию перед важными клиентами там или спонсорами делать, и ночью за 8 часов до начала файл ppt пропадает, как не было…

я их пока не коммитил

А нужно было, а то мало ли что)

IDE могут иметь историю локальных правок с возможностью отката, не раз выручало.

Дык я спал на креслах. Ставишь комп «в процесс», ужинаешь и на массу. Ну, пару раз выгоняла охрана.

Дык я спал на креслах. Ставишь комп «в процесс», ужинаешь и на массу. Ну, пару раз выгоняла охрана.

...ночью за 8 часов до начала файл ppt пропадает, как не было...

Было и такое, да.

Для гита есть гуи?! А нахрена?

А как под виндой работать? :)

Я глянул что он советует - это расширение для виндового проводника.

Эм, очевидно же чем. Хоткей нажимается за 1 секунду

На хоткей можно что угодно повесить.

Так вот он и повесил, и не набирает пачки каких-то команд вручную.

Я не спорю, что можно обвешать гит костылями и сделать чтобы с ним было всё просто. Но это дополнительная доработка, да и костыли выглядят некрасиво.

Ты свою систему контроля версий пилишь что ли? Когда покажешь, что получилось?

Уже долго кажется что вот скоро, но времени к сожалению не сильно много. А так, уже год как использую для деплоя в проде, и полтора месяца назад перешёл на неё для версионирования её собственного кода (перед этим хранил её исходники почти что методом AZJIO, чтобы не привязываться к другим vcs, остальной свой код тоже бы перевёл, но нужно делать конвертер из svn ещё). Но пока нет некоторых существенных фич, а так же код местами слишком черновой для публикации.

Так вот он и повесил

Так он повесил что-то своё. Чем это принципиально отличается от повесить туда git? Это я к тому, что хоткей - это не аргумент в данном случае.

Не, для винды я понимаю, но и там я нашел павершелл для юзеров, даю им скрипты для работы с гитом. А на линуксе то нахрена, если в консоли в две секунды команду прописать? И открывается одним хоткеем в том же дельфине по F4 и yakuake.

А представляешь сколько шума было бы, если бы это сделал ИИ? :))

Сочувствую.

представляешь сколько шума было бы, если бы это сделал ИИ? :))

«А если бы он вёз патроны??» (с)

А как под виндой работать? :)

Желающие работать из консоли могут использовать cygwin в т.ч. прямо из Git Extensions ;-)

Я глянул что он советует - это расширение для виндового проводника.

Git Extensions то? Нет, это не расширение для Windows explorer, а отдельное приложение.
Хотя какая-то интеграция с WE там вроде бы тоже есть.

Из кроссплатформенных GUI фронтендов к git я бы отметил EGit.