Git основы базы данных

Ответ 1

Пусть начнется с самого начала. Вот схема вашего исходного состояния:

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (next, origin/next)

Когда вы проверили next и rebased next на origin/master, он создал 6 новых коммитов после двух, уже находящихся на origin/master. Эти новые коммиты имеют "master commit # 2" (C на моей диаграмме) как их предок, а не их первоначальный предок, где origin/master и origin/next расходятся (A на моей диаграмме), поэтому их хэши будут разными, Полагаю, именно поэтому вы увидите, что next имеет 8 разных коммитов из origin/next: 2 из origin/master и 6 "перефразированных" коммитов, которые были на origin/next.

После git checkout next ; git rebase -i origin/master у вас должно получиться следующее:

A-B-C  (master, origin/master)
 \   \
  \   D'-E'-F'-G'-H'-I' (next)
   \
    D-E-F-G-H-I  (origin/next)

Вы можете видеть, что next имеет 8 коммитов, которые не находятся на origin/next, а origin/next имеет 6 коммитов, которые не находятся на next. Предоставлено это только согласно хэшам SHA-1 коммитов. Фактическое содержимое должно соответствовать очень близко, если вы git diff origin/next next - diff должен просто показать изменения от B и C (как указано на диаграмме).

Когда вы выполняете git pull --rebase, все еще находясь на next, он извлекает изменения из источника (удаленный origin/next) и переустанавливает текущую ветку (next) на этот пульт. Это приведет к появлению изменений в next, но не в origin/next после origin/next в новой ветке next. Он должен выглядеть следующим образом:

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (origin/next)
             \
              B'-C' (next)

Если это то, что вы хотели, чтобы график истории выглядел так, вы преуспели.

Однако, я подозреваю, что вы действительно хотели, чтобы все выглядело как средняя диаграмма, особенно если next - это ветвь функции, в которой вы работаете над следующей частью проекта, а master - для стабильного кода и небольшой ошибки исправления. Если это так, тогда вы должны были сделать git push вместо git pull --rebase, чтобы удаленный образ отображал вашу версию истории, а не наоборот.

Ответ 2

Начните с очень простых шагов для восстановления вашей ветки с помощью мастера; Имя;

git-rebase

Сводка

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
        [<upstream>] [<branch>]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
        --root [<branch>]
git rebase --continue | --skip | --abort | --edit-todo

Описание; Предположим, что существует следующая история, а текущая ветка - "образец":

 A---B---C sample
         /
    D---E---F---G master

С этого момента результат любой из следующих команд:

git rebase master
git rebase master sample

:

A'--B'--C' sample
                 /
    D---E---F---G master

ПРИМЕЧАНИЕ. Последняя форма - это всего лишь короткая рука git checkout sample, за которой следует git rebase master. Когда выборки для переустановок будут оставлены выданными ветвями.

Если ветвь вверх по течению уже содержит изменение, которое вы сделали (например, поскольку вы отправили по почте патч, который был применен вверх по потоку), то это сообщение будет пропущено. Например, запустите 'git master rebase master в следующей истории (в которой A и A вводят один и тот же набор изменений, но имеют различную информацию об участниках):

A---B---C sample
         /
    D---E---A'---F master

приведет к:

 B'---C' sample
              /
D---E---A'---F master

Все это было схематическое понимание процесса переучета. После того, как вы разрешите конфликты, найденные после ввода git rebase master разрешите конфликты и введите git add -u, чтобы добавить измененные коды в репозиторий. после этого выполните команду git rebase --continue и продолжите разрешение конфликтов и повторите команду;

git add -u 

и

git rebase --continue 

пока конфликты не будут найдены. Наконец, последняя команда будет,

git push --force origin sample(your branch name)