Я снес свой проект к ебб

почему не делал push?

это же не какой-то сраный svn, где постоянно нужно делать svn ci. В git же локальный репозиторий и все дела, пальцы в перстнях, тёмные очки.

Поддержу тезис о своевременном push.

Но так зачастую и случается: подготовил красивый патч на локалхосте (дня так за два), собрался коммитить, и решил «для красоты» выкосить временные файлы. Бац.. и у тебя резко испортилось настроение.

Для того, чтоб делать бекапы вручную — надо быть очень организованным. Я бы предпочёл автоматический бекап (например Dropbox). В VCS не всегда успеваешь закоммитить.

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

более интересный способ, родом из plan 9:

$ find -printf 'rm %p\n'
...
$ find -printf 'rm %p\n' | sh

(чтобы было совсем почти как в plan 9:

frm(){t=`mktemp`;find "$@" -printf 'rm %p\n" >$t;$EDITOR $t;. $t;rm -f $t;}

посмотри ещё foremost http://mydebianblog.blogspot.ru/2007/01/1-foremost.html

я обычно пишу

find блаблабла -print. И только после проверки -delete

Если бывает нужен не -delete, а -exec, то сначала -exec echo чтототам, а после проверки -exec чтототам

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

Я бы предпочёл автоматический бекап

А если ты о том, чтобы запускать такой скрипт вручную, то он ничем не лучше git push.

идиома с | sh при её последовательном применении полезна тем, что универсальна и не зависит от того, find у тебя или что-то другое. в plan 9 существенная часть вещей, которые хотят сделать что-то плохое, печатает соответствующие команды, не выполняя их.

ты шо, делая пуш некомпилируемых сорцов ты делаешь у хвостострела еще один волос седым на заднице, так нельзя

у скрипта преимущество: он сам может раскидывать бекап на несколько компов (хоть в друпбокс), он не зависит от git, и не требует коммита (а значит и рожать адекватное сообщение к коммиту)

photorec из testdisk и ext4magic в помощь, если не хочется все переписывать.

Ви таки предлагаете туда-сюда патчи незакомиченные на флешке таскать? И потом на месте каждый раз это мержить/откатывать-накатывать?

а то и с VCS не надо форкать/мержить/разруливать конфликты/откатывать а потом накатывать в случае успеха?

идиома с | sh при её последовательном применении полезна тем, что универсальна и не зависит от того, find у тебя или что-то другое.

Но геморройна необходимостью экранирования, особенно пробелов в именах :\

Ладно, убедил.

честно говоря, это проблема posix и find: даже у ls (во всяком случае, gnu) есть режим более-менее адекватного вывода:

$ touch /tmp/'"'
$ ls -Q /tmp/'"'
"/tmp/\""

а вот gnu find, по-моему, так не может.

думаю, ты прав, и это и определяет непопулярность этой идиомы за пределами plan 9, где квотированию как-то уделяется больше внимания (например, в стандартной библиотеке си есть функции для этого: http://plan9.bell-labs.com/magic/man2html/2/quote)

Если правильно и вовремя коммитить, то не надо (только перед мержем в мастер)

не только коммитить, но и pull-ить, а то мердж будет занятным 8)

Не раз в былые годы сталкивался с таким факапом. После одного даже получилось сделать на порядок более лакончиный и красивый патч, просто попробовав другой подход к решаемой проблеме. Сейчас же спасаюсь автоматическим снапшотом каждые 15 минут (zfs). Теперь в случае чего максимум теряются последние 15 минут. Сами снапшоты хранятся месяц, удобно.

testdisk

Не панацея.

скрипт наклепал? под Linux у тебя это zfs? может и мне такое замутить? думаю...

'zfs snapshot data/mydata@`date +%m%d%Y`' в кроне это уже скрипт? :D

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

В этом топике полно знатоков, которые считают, что работу нужно бэкапить путем push.

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

ЗЫ любой тимлид бьет валенком своих программеров если они не соблюдают git work flow проекта, где черным по белому прописано о централизованном хранении кода на сервере. ибо там бекапить проще, чем рабочии тачки девелоперов. Да и отслеживать прогресс намного удобнее.

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

rsync, wuala, MEGAsync, duplicity... да дахрена еще чего. Зачем пушить не готовый код? Зачем использовать для бэкапа тот же иснтрумент что и для управления версиями?

У меня бэкапится все с помощью deju-dup раз в неделю (это глобальный бэкап на случай ядреной войны), еще один бэкап где-то раз в месяц на локальный диск, на случай запрета интернета госдурой (не то чтобы я думаю что ядреная война более вероятна чем запрет интернета, просто вряд ли после него моя работа кому-то понадобится), на основной машине всегда работают Wuala и MEGAsync. MEGAsync синхрит все это с ноутом. Wuala там тоже есть но он отключен от синхронизации - его копии потребуются если будут проблемы с копиями из MEGAsync. А в svn летит только готовый код.

Пушить только готовую (хотя бы к review) работу - это хорошая практика.

Почему бы не иметь ветку-WIP и пушить в неё всё что угодно любой степени готовности, в т. ч. с целью бэкапа? Если VCS не распределённая и/или не позволяет переписывать историю (force push) — тут да, уже ССЗБ.

Почему бы не иметь ветку-WIP и пушить в неё всё что угодно любой степени готовности,

Нет проблем - имей, пушь. Только зачем?

Оперативнее, чем бэкап по крону или ещё как-нибудь самостоятельным средством.

Почему бы не иметь ветку-WIP и пушить в неё всё что угодно любой степени готовности,

Нет проблем - имей, пушь. Только зачем?

Оперативнее, чем бэкап по крону или ещё как-нибудь самостоятельным средством.

double_facepalm.jpg

То, что последовательность коммитов должна как-то отражать выполняемое задание, ты, похоже, не думаешь. Ты реально так работаешь или в просто хочешь победить в споре о том, что VCS - это инструмент бэкапа?

Я же ровно двумя сообщениями выше сказал, что «бэкап средствами VCS» — это ветка-WIP, в которой относительно твоей topic branch всегда один коммит.

В терминах Git:

git checkout topic
<work>
git checkout -B topic-WIP
git add -A .
git commit -m "WIP"
git push -f origin topic-WIP

Я реально так работаю, да. А в topic branch у меня всегда чисто (ради чего иногда приходится по полчаса разбирать свой собственный дифф, если так получилось, что работал над двумя вещами одновременно, но логически они должны быть в разных коммитах).

Этакий stash вручную, который можно запушить на удалённый сервер. Считаешь, это плохо?

Поддерживаю. DVCS - для контроля версий, а бэкап удобнее осуществлять другими способами. Пушить сырую цепочку ревизий совсем не обязательно. Я, например, могу неделями ничего не пушить. Но я регулярно пользуюсь двумя удобными командами: hg bundle и scp. :)

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

Думаешь, поэтому squash/amend. Короч, в git ветки не грех и уже можно. Только старые не забывать удалять.

Фрибсд. Под линуксом не знаю как с zfs, может и можно. Скрипт готовый http://marcin.studio4plus.com/en/zfs-file-history/howto.html . Удобен тем, что удаляет старые снапшоты и прореживает не очень старые. Например, у меня пятнадцатиминутные снапшоты хранятся три дня, снапшоты старше трёх дней прореживаются, остаются по два на каждые сутки, через месяц и они удаляются.

ХЛЕБАТЬ ТЫ ПЛОХ

Это ты круто придумал, надежно и профессинально. Ну а я себя коммитить часто надрессировал...

Для того, чтоб делать бекапы вручную — надо быть очень организованным

...или однажды потерять результат двухнедельной работы :)

собрался коммитить, и решил «для красоты» выкосить временные файлы.

Use .gitignore, Luke!

почитал две страницы комментов, первые штук 10 были по делу а остальное срач :) я свою ежедневную работу пушу не только на гитхаб но и на внешний хард. С хардом возможно только физическое уничтожение так как в случае поломки отдельных компонентов его можно восстановить почти со 100% гарантией, так что это вполне надёжно. было бы у меня несколько хардов скидывал на них и прятал в разных местах :) я помню как потерял работу за 2 дня и срал в штаны как следует и с тех пор я не лишен паранойи. Никому на 100% не доверяй свой код, даже таким гигантам как гитхаб :)

Повторюсь. Буратины должны страдать.

TestDisk

кто-нибудь из гуру линуксового LVM может сказать, почему нельзя для того же самого использовать lvm-снапшоты?

Use .gitignore, Luke!

Вообще да, согласен. Но он не всегда спасает: в процессе работы бывает валяются ненужные скрипты, картинки, дампы, ... (добавлять их все под игнор нет смысла, ибо они единоразовые)

Сколько идиотов, не отличающих CVS от резервного копирования.

Столько идиотов, не отличающих промежуточные коммиты (да да, любую активность можно разбить на вполне себе осмысленные этапы) от резервного копирования.

Но он не всегда спасает: в процессе работы бывает валяются ненужные скрипты, картинки, дампы

Выбирай:

1) Создать и заигнорить директорию shit/ 2) Игнорить непроектные файлы по маске 3) Не хранить всякое дерьмо в SCM-директории

не гуру lvm, но учитывая через какую жёппу оно делает снэпы, может поплохеть уже через день, если каждые 15 минут лепить.

Воспользуйся тайм-машиной.

Повторюсь. Буратины должны страдать.

Я тебе так скажу: кто не работает, тот не ошибается.

Но он не всегда спасает: в процессе работы бывает валяются ненужные

скрипты, картинки, дампы

Выбирай:

Я что? Я ничего. Моя практика: добавлять в игнор регулярно-используемые временные файлы. Весь остальной хлам обычно где-то в /tmp.

Да, меня уже трижды упрекнули за этот пример (про мусор в VCS директории). Хотя основная мысль была более философской: человек не идеален, и ошибки имеют место быть. Конкретизируя: ручной бекап не всегда получается сделать, а автоматический — настроить.

И твой ответ как раз в наталкивает на правильный ответ: надо вырабатывать привычку (делать правильно). Но не следует заходить слишком далеко: развитие привычки требует время и, следовательно, создает неудобство пользователям. По этому, где это возможно, стоит уменьшить потребность в развитии привычки. Это один из постулатов usability.

Так по идиотски ошибаются только лохи. Буратины должны страдать. У умных людей и backup всегда есть, и постоянные коммиты во временный branch, и файловая система со снапшотами.

Для этого есть временные бранчи, недоумок, и git branch -D.