Я предполагаю, что вы скачали CakePHP 2.0.0, разархивировали его, а затем запустили что-то вроде git init, git add ., git commit, чтобы создать репозиторий. Возможно, вы сделали некоторые изменения поверх этого (если вы этого не сделали, просто выбросьте его, клонируйте репозиторий github и поработайте над этим).
Важно то, что у вас есть хранилище, которое началось с zipball.
Теперь, когда вы добавили и извлекли github, github кратко предупредил вас: «Предупреждение: нет общих коммитов». Это означает, что между репозиторием на Github и вашим локальным репозиторием нет корня коммитов.
a1 -- b1 -- c1 -- d1 -- e1 -- f1 master
r1 -- s1 -- t1 -- u1 -- v1 -- w1 github/tags/2.0.4
Когда речь идет о слиянии, между двумя хранилищами нет никакой связи. Конфликты вызваны тем, что они оба , по-видимому, добавляют одни и те же файлы с различным содержанием.
Простейшим способом решения этой проблемы является rebase ваша работа поверх тега 2.0.4. Вы делаете это, перебрасывая все кроме первого коммита, в который вы добавили zip-файл. Допустим, ваш первый коммит - a1, а ваша ветвь - master.
Сначала сделайте метку у своего хозяина. Если что-то идет не так, как надо, вы можете восстановить этот тег.
git tag tmp/master master
Затем сделайте ребаз.
git rebase --onto tags/2.0.4 a1 master
Каждый коммит будет переписан как коммит из релиза 2.0.4.
a1 -- b1 -- c1 -- d1 -- e1 -- f1 tmp/master
r1 -- s1 -- t1 -- u1 -- v1 -- w1 github/tags/2.0.4
\
- b2 - c2 - d2 - e2 - f2 - g2 - h2 master
Думайте о ребазе, как о сохранении каждого коммита в виде патча и повторном применении их в другой ветке. Вы берете разницу между a1 и b1 и фиксируете ее поверх w1, делая новый коммит b2. Затем diff b1 против c1 и зафиксируйте это поверх b1, делая c2. И так далее.
Если ваш первый коммит не был неизмененным zip-файлом, не все потеряно. Вы можете использовать ту же процедуру, но вы должны восстановить эту первую часть работы. Сначала вам нужно извлечь diff между вашим первым коммитом и чистой версией 2.0.0.
git diff tags/2.0.0 a1 > first_commit.patch
Затем создайте новую ветку из тега 2.0.4 для хранения вашей новой работы.
git checkout tags/2.0.4
git checkout -b newmaster
Примените и передайте патч.
git apply first_commit.patch
git commit -a
Теперь newmaster содержит 2.0.4 плюс ваш первый кусочек работы.
Теперь rebase мастер, как и раньше, но поверх новичка, а не прямо на 2.0.4.
git tag tmp/master master
git rebase --onto newmaster a1 master
Вы можете удалить newmaster.
git branch -d newmaster
PS Все это становится более понятным, если вы можете визуализировать хранилище. В OS X GitX (L) - отличный способ увидеть репо.