Почему git (bash) вставил кучу ерунды в мои новые файлы?

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

>>>>>>>>
HEAD
c0d3234k2jl423;lk4j232;l34jk32;l23j4

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

Но что же все-таки происходит? Я все еще довольно новичок в git и github. Как я могу избежать этого в будущем? Я использовал консоль git bash на Windows XP.

Также-поскольку это может быть связано - когда я пытался зафиксировать файлы ранее через мой интерфейс PhpStorm CLI, я нажимал "commit", и фиксация никогда не завершалась. Просто все пытался и пытался. Так что мне все время приходилось это прерывать. команда, затем войдите и вручную удалите индекс.файл блокировки, а также COMMIT_EDITMSG.swp-файл.

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

E138: can't write viminfo file u:_viminfo!
Press enter or type command to continue

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

2 4
github git-bash

2 ответа:

Это слишком долго для комментария, поэтому:

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

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

Итак, вот ускоренный курс с одной из тех диаграмм commit graph, которые вы научитесь ненавидеть: 

         H <- merge
        / \
you -> G   E <- github
       |   |
       F   D
        \ /
         C
         |
         B
         |
         A

Вот как может выглядеть история фиксации, если вы работали до C, а затем кто-то другой (или вы на другом компьютере) добавил D и E и толкнул их, а затем вы снова начали работать с C и сделали F и G. вы не можете толкать так, потому что ваш компьютер не работает. местная ветвь ничего не знает о D и E или о том, как они связаны с историей; у вас есть только A-B-C-F-G.

Но если вы сначала объединитесь, чтобы создать H, то теперь у вас есть ветвь с всеми коммитами от вас и github на ней, и github можно обновить, просто "переместив" его стрелку вверх. Вы не можете выполнить эту работу на удаленном компьютере, потому что она включает в себя изменение файлов для создания объединенных версий, а удаленная машина фактически не имеет физических копий ваших файлов. (Кроме того, у вас не было бы способа разрешения конфликтов.)

git log --graph --oneline --decorate это довольно полезный взгляд, который должен покажу вам, с чем вы сливались. Приведенная выше диаграмма будет выглядеть следующим образом вот так: 

* H (master)
|\
*| G
*| F
|* E (origin/master)
|* D
|/
* C
* B
* A

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

Если материал между маркерами конфликтов действительно был мусором, возможно, ваша IDE испортила и повредила файлы. git довольно надежен и никогда не должен уничтожать данные (если вы случайно не попросите его об этом, конечно).

2

В следующий раз попробуйте использовать инструмент для разрешения конфликтов, например git mergetool -t kdiff3. Это довольно быстрая перемотка вперед и интуитивно понятный, помогает много, когда есть множество мелких конфликтов.

ВизуальныеИнструкции для kdiff3.

1