LINUX.ORG.RU

Вопрос про Git. Он, правда, позволяет так легко потерять данные?

 , ,


9

7

Я тут на пробу пытаюсь парочку репозиториев перевести с привычного Mercurial на инопланетной логики Git в надежде разобраться с последним. И, ладно бы только логика работы, к ней можно привыкнуть. Но я уже несколько раз терял свои наработки с Git, чего с Mercurial не было никогда за всю историю. Пару раз терял так, что концов не найти, но вот сейчас всю цепочку отследить попробовать можно. Посему и прошу комментариев народа опытного.

Суть такая. Есть поднятый весной и так и не развитый репозиторий https://github.com/Balancer/bors-3rd-bootstrap3

Сейчас решил перекинуть туда код (со всей историей) по работе с bootstrap из ядра фреймворка, которое лежит в Mercurial на Bitbucket. Благо, есть такая прекрасная штука, как hg-git. Перенос файлов со всеми изменениями из репы в репу под Git возможен, но выглядит это чудовищно. Посему, решил вынести сперва отдельный маленький локальный репозиторий Mercurial с этими файлами, к нему подтянуть дерево Git, смержить средствами Mercurial и запушить в репу Git.

Сделать это было чуть дольше, чем написать предыдущий абзац, но работа небольшая, всё было проведено легко и непринуждённо. На GitHub'е появился объединённый модифицированный код. Всё прекрасно.

Дальше начинаются вещи непонятные. Я работал также с другой машины, там были мелкие правки (типа composer.json в корне). Решил всё объединить. Точную последовательность не помню, но, скорее всего обычные git pull && git push на другой машине.

После этого, чтобы точно убедиться, что изменения синхронизированы, провёл после git fetch (там --bare) на первой машине git push... И увидел странное:

To git@github.com:Balancer/bors-3rd-bootstrap3.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:Balancer/bors-3rd-bootstrap3.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Ну, что, Google в помощь, и первый же совет, который нахожу — воспользоваться ключиком «-f». Не вопрос. У нас же DVCS, даже если что-то не так, всегда можно откатить и т.п. Логика, привитая Mercurial'ом, ага...

Ничтоже сумняшеся, обновляю composer на другой машине и... вижу, что всех изменений, которые я переносил в эту репу нет. Удивляюсь. Вызываю git log --graph (вот почему в git по дефолту все команды такие длинные и несуразные?) — чистота. Всё в превозданном виде семимесячной давности, без переноса нового кода с основного репо.

Лезу на GitHub — и вот тут становится совсем интересно. Те изменения, что я накатывал и которые там были, теперь там отсутствуют o_O

Так вот, вопрос. Это я их не вижу, или это в Git так легко, одним движением руки можно убить безвозвратно серию коммитов с историей? o_O Если первое — то вопрос, как вернуть эти изменения. В основной репе я их уже успел прибить, но всегда можно откатить и повторить перенос. Придётся повозиться, но задача не столь сложная. Но хочется разобраться. Ибо если в Git так легко потерять изменения, то как с ним вообще люди живут?

★★★★★

Последнее исправление: CYB3R (всего исправлений: 1)

Ответ на: комментарий от KRoN73

Подделка истории — нафига?

Ненужный мусор в истории - нафига?

LamerOk ★★★★★
()
Ответ на: комментарий от KRoN73

Пойнт в том, что настоящая история никому не нужна. Нужна история, которая отражает ход разработки. Которую удобно грепать, бисектить, мерджить и так далее. И git позволяет вести любую историю. Нужно одно — забываем про все force-команды. Нужно другое — резко вспоминаем и пользуемся всем диапазоном возможностей.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от vurdalak

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

Т.е. до изобретения VCS в историю лезли кривыми ручками?

LamerOk ★★★★★
()
Ответ на: комментарий от KRoN73

Чем тебе мешает история, если это уже именно история? У меня много херни в истории, только жить-то не мешает.

Еще как мешает. Если я хочу узнать, что именно ты изменил, то зачем мне *твоя херня* ?

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Разница в том, что в git, как оказывается, историю сломать легко по ошибке.

4.2

LamerOk ★★★★★
()
Ответ на: комментарий от vurdalak

обсуждал с человеком гит, и он сказал что создаёт по 100500 веток и после мержа их удаляет. Нафига ветки тогда нужны вообще, я так и не понял.

Это - типичный воркфлоу не только для git'а, но даже для svn. Или даже более обще - это вообще обычный процесс разработки софта.

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Задача исправления истории — редакая и исключительная.

4.2

Это практически необходимый шаг перед коммитом в общую ветку или мержем девелоперского бранча с основым. Это - как помыть руки перед едой.

LamerOk ★★★★★
()
Ответ на: комментарий от KRoN73

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

Еще как должны. (D)VCS, не позволяющая «причесать» историю - это какое-то ненужное говно. Единственным оправданием тут может служить почтенный возраст.

и инструментарий для такого должен иметь надёжную защиту от случайных ошибок.

git её имеет.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Уже ниже рассказали, да. Я просто не знал, что в гите ветка может использоваться фактически как две разные сущности.

vurdalak ★★★★★
()
Ответ на: комментарий от LamerOk

Ты не понимаешь сути истории. Это не причёсанная кучка изменений, которую делают специально красивой. Это история изменений, таких как их делали и коммитили.

vurdalak ★★★★★
()
Ответ на: комментарий от LamerOk

Суть DVCS - верифицирующая, версионная, распределённая файловая система

Что и обеспечивает безопасность данных. Версионирование обеспечивает сохранность старых данных, распределённость — защиту от локальных потерь.

Т.е. - git.

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Bad_ptr

когда ты учился в школе ты был почти из россии, а учитель твой так и вообще из совка.

ага, да и сам я из совка. но в данный момент я там не проживаю, и кто такие «всякие Вербицкие» мне знать неинтересно.

waker ★★★★★
()
Ответ на: комментарий от vurdalak

Ты не понимаешь сути истории. Это не причёсанная кучка изменений, которую делают специально красивой. Это история изменений, таких как их делали и коммитили.

Понимаешь, есть разница между комитили и пушили (ну или мержили в глобальный репозиторий). Комит о котором говоришь ты - это пуш. До этого момента вся твоя история - черновик. А другим разработчикам твой черновик не нужен.

Dudraug ★★★★★
()
Ответ на: комментарий от KRoN73

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

Почему у тысяч пользователей гита все в порядке?

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

Почему у тысяч пользователей гита все в порядке?

Как «почему»? Почему у мух всё в порядке, знаешь?

iZEN ★★★★★
()
Ответ на: комментарий от Dudraug

Понимаешь, есть разница между комитили и пушили (ну или мержили в глобальный репозиторий). Комит о котором говоришь ты - это пуш. До этого момента вся твоя история - черновик. А другим разработчикам твой черновик не нужен.

Бывают случаи, что локальному репозиторию приходит капец. И тут Hg выручает тем, что в центральном репозитории хранится и твоя история изменений до последнего пуша. Информация никуда не пропадает — можешь легко по ней откатиться и разрешить конфликты (если они появились).

iZEN ★★★★★
()
Ответ на: комментарий от intelfx

Пойнт в том, что настоящая история никому не нужна.

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

iZEN ★★★★★
()
Ответ на: комментарий от Bad_ptr

«когда ты учился в школе ты был почти из россии, а учитель твой так и вообще из совка.»

Почти из россии быть нельзя. И России до 1991 года не существовало. А СССР даже на бумаге не признавал себя наследником Российской империи.

anonymous
()
Ответ на: комментарий от iZEN

Бывают случаи, что локальному репозиторию приходит капец. И тут Hg выручает тем, что в центральном репозитории хранится и твоя история изменений до последнего пуша. Информация никуда не пропадает — можешь легко по ней откатиться и разрешить конфликты (если они появились).

Ты в любом случае потеряешь информацию до последнего пуша. А эта «черновая» история никому нафиг не нужна. Она была нужна тебе до пуша, но она не несет никакой ценности после. В этом идея.

Dudraug ★★★★★
()
Ответ на: комментарий от iZEN

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

Тебе нужны комиты вроде тех что ниже?

1) первый черновой - ничо не работает, не собирается
2) собирается но есть бага
3) надо бы отрефакторить
4) готово
5) ай, добавил еще забытую фичу
После того как ты закончишь и будешь готов к пушу ты делаешь git rabase -i и сквашишь эти 5 изменений в однин комит. И потом пушишь его. Если твой локальный репозиторий накрылся зачем тебе эти 5 бесполезных комитов в истории?

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

Dudraug ★★★★★
()
Последнее исправление: Dudraug (всего исправлений: 2)
Ответ на: комментарий от Dudraug

«Россия является наследницей СССР какбы.»

Я про это и говорю. И не надо выть, что мол, не любят злые соседи. По Тришке и кафтан. Вот когда Россия официально откажется от советского наследства и признает наследие Российской Империи, тогда и можно будет говорить о чем-то.

anonymous
()
Ответ на: комментарий от Dudraug

Тебе нужны комиты вроде тех что ниже?

Мне нужны все коммиты. А иначе зачем вообще нужна история? Достаточно хранить несколько последних версий и всё.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Мне нужны все коммиты. А иначе зачем вообще нужна история? Достаточно хранить несколько последних версий и всё.

Не-не-не. Такая история как я привел выше нужна пока ты пилишь фичу, для того, чтобы всегда была контрольная точка к которой можно откатиться. Когда фича готова, то нет смысла тащить все черновые комиты в мастер. Они имеют смысл до тех пор пока фича не готова. Я, как и очень многие разработчики, придерживаются стратегии когда все ветки ребейзятся от origin/master (если есть необходимость в сохранение ветки ребейз постоянно повторяется после git fetch/git remote update). После чего я могу просто замержить ветку в мастер простым git merge --ff-only. В результате чего получу линейную историю и одни и те же комиты в своей ветке и мастере.

Случай когда твоя личная ветка сохраняет промежуточные коммиты подразумевает cherry-pick. А это на мой взгляд уже бардак. Когда в дополнительной ветке содержится история отличная от того что было запушено. Потому что в случае чего хрен поймешь как с этим потом работать. Но git позволяет работать и так, без rebase. Так что это совсем не аргумент против гита. В гите можно и так и так работать. А в hg, насколько мне известно, rebase отсутствует.

Dudraug ★★★★★
()
Последнее исправление: Dudraug (всего исправлений: 1)
Ответ на: комментарий от Dudraug

когда все ветки ребейзятся от origin/master

Естественно тут я имею в виду не именно origin/master, а ветки которые являются общедоступными.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

В гите можно и так и так работать. А в hg, насколько мне известно, rebase отсутствует.

В теме уже разбирали. Разница именно в том, что столь жёсткая (на мой взгляд) реструктуризация истории в git делается одним неловким движением, а в hg требует отдельных операций.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от vurdalak

Ты не понимаешь сути истории. Это не причёсанная кучка изменений, которую делают специально красивой. Это история изменений, таких как их делали и коммитили.

Ты не понимаешь сути истории. История не нужна сама по себе. История коммитов в VCS - это инструмент решения проблем настоящего. С её помощью решают проблемы двух типов - «что за билд стоит у клиента» и «э, посоны, а чё поменялось?».

В обоих случаях вечерний тупак, отреверченный утром никому не нужен - это мусор, белый шум.

LamerOk ★★★★★
()
Ответ на: комментарий от KRoN73

верифицирующая, версионная, распределённая файловая система

Что и обеспечивает безопасность данных.

Ну 4.2 же, ей-богу. Где из перечисленных мною трёх пунктов виден твой четвёртый?

То, что ты попутал (D)VCS с системой бэкапа, - это твой личный bias.

Mercurial как самостоятельная бэкап-система годится, git — да, ..., то есть много хуже.

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

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от anonymous

Сразу видно, программист на пхп.

Сразу видно, программист на пхахап.

ЛОР такой ЛОР.

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

Тьфу.

// Лично я на работе спокойно сижу на svn - простой и понятной как топор. Не стоит в 99% эта ваша распределённость того, чтобы из-за неё так выкаблучиваться.

hobbit ★★★★★
()
Ответ на: комментарий от anonymous8

Нет, DVCS не являются заменой бэкапов.

_D_VCS, судя по вашему разговору, не являются. А централизованная VCS, то бишь svn - вполне себе является. Причём таким бэкапом, откуда очень легко достать данные за любую дату. Разумеется, при условии, что сама БД svn бэкапится регулярно.

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

hobbit ★★★★★
()
Ответ на: комментарий от waker

/0

Охотно верю, что в гите это /0, но в svn зелёного новичка вполне можно пускать. Ибо _безвозвратное_ удаление данных там возможно только через эзотерические пляски с svnadmin, доступа к которому у него нет. Всё остальное обратимо.

hobbit ★★★★★
()
Ответ на: комментарий от intelfx

Пойнт в том, что настоящая история никому не нужна. Нужна история, которая отражает ход разработки.

Это надо сохранить, я считаю.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Два чаю господину! Гит такое гуано, с которым зачастую лучше не связываться. SVN вполне себе работающая и достаточно быстрая система для пары калек, пописывающих что-то изредка. git немного для других задач создавался, да и работать с ним значительно менее удобно, чем с теплым и ламповым SVN. Кстати, я тоже несколько раз прокакивал ребы git, с svn все значительно проще.

anonymous
()
Ответ на: комментарий от hobbit

ты не путай новичков с гуманитариями. гуманитарии тебе и в меркуриале все бранчи друг с другом смержат, и сделают push -f, а потом скажут что так и было.

waker ★★★★★
()
Ответ на: комментарий от anonymous

SVN

достаточно быстрая система

Дедушка, добро пожаловать в 21 век!

vurdalak ★★★★★
()
Ответ на: комментарий от anonymous

да практически тот же CVS, с небольшими отличиями. а CVS, бесспорно, для своего времени был неплох, но сейчас о нем даже вспоминать больно.

waker ★★★★★
()
Ответ на: комментарий от waker

Т.е. никакой конкретики. Ну ок, так и запишем «лишь бы поновее, а как работает - насрать». Типичная мысль потребляди.

anonymous
()
Ответ на: комментарий от waker

гуманитарии тебе и в меркуриале все бранчи друг с другом смержат, и сделают push -f, а потом скажут что так и было.

Только всегда можно будет откатить ревизию или достать старые данные.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Разговор идёт о том, что или придётся не делать временные коммиты и ветки на каждый чих, или иметь весь это треш в истории, при этом данный треш не добавляет «безопасности», но мешает работать с историей, поскольку вместо истории - лапша.

А ведь можно было почитать хотя б http://sethrobertson.github.io/GitBestPractices/

qnikst ★★★★★
()
Ответ на: комментарий от KRoN73

Только всегда можно будет откатить ревизию или достать старые данные.

И в гите можно. Настрой нормально гарбедж коллектор радуйся жизни.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

И в гите можно.

Не всегда. См. тему с начала. Или хотя бы последнюю страницу :) Собственно, тут холивор и идёт на этот счёт. Разрешать ли простое средство угробить историю, как это сделано в git (сторонники утверждают, что история должна легко правиться, чтобы не было мусора) или делать редактирование истории исключительной мерой, как это сделано в mercurial (история должна сохраняться кроме редких, исключительных случаев).

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Верно, не всегда. Если отработал gc, то уже не вытащить. Но

1) обычно это и не надо, ибо фейл рбейза ты скорее всего сразу ощутишь (а использовать ребейз без нормальной пост-проверки не стоит), а при merge и проблемы потери старых данных нет, на то он и merge. 
2) можно настроить gc заранее, чтобы он никгда (или совсем крайне редко) убирал "мусор".

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

Dudraug ★★★★★
()
Ответ на: комментарий от KRoN73

Только всегда можно будет откатить ревизию или достать старые данные.

если пушнуть на битбакет — хрена лысого ты достанешь, а не старые данные.

waker ★★★★★
()
Ответ на: комментарий от KRoN73

у тебя двоемыслие. смержить все бренчи и пушнуть с -f в меркуриале — это у тебя не «угробить историю». а push -f в гите — почему-то «угробить», несмотря на наличие reflog.

waker ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.