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

Question

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

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

Кто-нибудь еще испытывал это? Любые причины или решения?

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

Answer 1

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

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

коммит XXXXXXXX:

В файл foo добавлена ​​строка "bar".

... работа в процессе ...

много коммитов позже (скажем, около 100):

Строка "bar" больше не существует в этом файле !!

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

1.Я проверил историю файла с:

git log foo а также Гитк Фу

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

2. Я искал коммиты, которые могли бы удалить эту строку с помощью "git log -S", что-то вроде:

git log -S'bar '- foo

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

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

Answer 2

То же случилось и с моей командой.

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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