Git изменения теряются - почему?

Question

Наша команда разработчиков использует git, и мы потеряли изменения в файлах, по крайней мере, недавно. Мы используем частные репозитории Github.

В текущем случае мы можем вернуться к журналам в Github и увидеть некоторые обновления, которые я сделал для файла. Позже другой член команды изменил другую часть файла и, похоже, уничтожил мои изменения. У меня их все еще есть.

Есть ли у кого-нибудь это? Любые причины или решения?

Я не думаю, что кто-нибудь делает какие-либо перегибы или что-то необычное - просто тянет и толкает.

Answer 1

Хотя я не могу говорить с вашей конкретной проблемой, я могу сказать, что вчера я испытал нечто очень похожее. У меня был дизайнер с некоторыми URL-адресами в коде и обновление некоторых изображений в приложении iPhone, которое я заканчивал, и не рассказывал мне об этом. Я подталкивал свои изменения, которые я сделал, которые касались некоторых из этих файлов (разные точки), и он отклонил как нелокальную перемотку вперед. Поэтому я вытащил, получил конфликты, разрешил их и толкнул. Задача решена. Тем не менее, я отменил его изменения кода в этом процессе.

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

Answer 2

Аналогичная вещь случилась с моей командой.

Занятый урок: когда вы тянете, вы должны быть осторожны в конфликтах слияния. Если возникают конфликты при нажатии, git не вносит слияния изменений в локальное репо и , вы должны сделать это после устранения конфликта. В противном случае, нажав, вы перезапишете удаленное репо с вашей локальной копией. НЕ содержит изменений, сделанных людьми в удаленном, прежде чем вы потянете. Это объясняет некоторые «странные файлы», которые вы могли бы увидеть незафиксированными, но вы уверены, что это не ваши изменения. Это указывает на конфликт слияния на «тянуть» и - снова - , вы должны зафиксировать эти изменения локально после разрешения конфликта и затем нажмите на удаленный.

Если у вас нет конфликтов при слиянии при ударе - никаких проблем с потерянными изменениями не возникает. Поскольку git извлекает, объединяет и фиксирует вашу локальную копию, а «push» затем распространяет эти объединенные изменения на удаленный.

Answer 3

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

Answer 4

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

Маленькая иллюстрация:

совершают XXXXXXXX:

линия "бар" был добавлен в файл Foo.

... работа продолжается ...

много фиксаций позже (скажем, около 100):

линии «бар» больше не существует в этом файле !!

Исследование:

1.I осмотрена история файла с:

журнал мерзавец Foo и gitk Foo

Я даже по сравнению с последовательной сгустки каждой фиксации с внешним инструментом (gvimdiff). Интересно, что я нашел две коммиты (назовем их YYY и ZZZ). Blob файла foo из commit YYY состоял из «бара», но blob из ZZZ этого не делал.
Когда я проверил commitdiffs этих коммитов с gitk (и gitweb), я заметил, что нет операции удаления строки «bar» в ZZZ. Возможно ли, что между ними было какое-то сражение и растворено в воздухе?
Или, может быть, фиксация ZZZ только что удалила мою строку и инструмент diff, встроенный в git (или gitk), сломан?

2.I искал фиксации, которые могли бы удалить эту строку «мерзавец войти -S», что-то вроде:

мерзавца войти -S'bar»- обув

Оказывается, что эта линия никогда не удалялся. На самом деле это было добавлено два раза. Первый раз, когда он был введен в проект и второй раз, когда он снова был добавлен в качестве срочного исправления.

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

Answer 5

Я предполагаю, что между коммиттерами существует другая конфигурация, возможно, кому-то не хватает конфигурации автокремфа.

Git как-то рассматривает совершенно разные две версии одного и того же файла, тем самым перезаписывая старый с более новыми изменениями из другой ветви.

Если трехстороннее слияние (по умолчанию рекурсивное) находит два совершенно разных дочерних элемента (то есть из-за неправильной конфигурации CRLF), объединенный результат будет самым последним, без конфликтов.

Answer 6

У нас была такая же проблема: Dev A сделал изменения. Dev B внес изменения в что-то еще. После того, как Dev B подтолкнул его изменения, изменения Dev A «исчезли». Изменение, которое Dev B сделал, было несколько недель назад, но, похоже, до сих пор никто не заметил потери изменений Dev A.

Настоящая причина изменения «исчезла» в том, что инструмент, который мы использовали для просмотра истории (TFS), показывал неправильную версию истории. Когда мы смотрели с помощью различных инструментов (SmartGit и SourceTree), мы увидели, что на самом деле произошло: кто-то перезаписал это изменение, пытаясь исправить конфликт слияния, и перезапись была на видном месте.

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

Мы использовали git в течение года и в 99% случаев, когда что-то «пошло не так» с git, это было фактически вызвано тем, кто действительно не понимал git.Единственный раз, когда он был «git», был проблемой CRLF, но на самом деле это было потому, что мы не знали git достаточно хорошо и (благодаря SO), с ним было легко справиться.

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