Узнайте, в каком хранилище добавлен коммит

Question

У нас есть два хранилища git, содержащие два разных, но очень похожих проекта.

Первый проект является основным проектом (далее MAIN), а второй проект является производным от MAIN (DERIV в дальнейшем).

EDIT: Обратите внимание: это не разные ветви в одном и том же репо, но два отдельных репозитория. В каждом репо мы поддерживаем только одну ветвь master.

Мы работаем над этими двумя проектами параллельно, но основное предположение заключается в том, что каждое изменение MAIN также должно применяться к DERIV. Мы удовлетворены этим, издавая периодические оттяжки от MAIN до DERIV.

Вопросы:

1. git log При выполнении в DERIV, я могу видеть, для каждого коммита, в клоном которого репозиторий был добавлен?

   EDIT: Вопрос в том, возможно ли это, если оба РЕПО поддерживают одну ветвь master. Если нет, тогда возникает вопрос, будет ли использование разных имен для филиалов в двух репозиториях решить эту проблему.

2. Могу ли я узнать даты вылета из MAIN в DERIV?

   EDIT: Проблема с git log заключается в следующем: когда я работаю на основном проекте, я клонировать ГЛАВНОГО репо на локальную машину, делать какую-то работу (несколько фиксаций), вытащить из MAIN и разрешение конфликтов (если таковые имеются), нажмите MAIN/master. Последнее сообщение фиксации - Merge branch 'master' of MAIN. Когда я вытаскиваю из MAIN в DERIV и разрешаю конфликты, сообщение Merge branch 'master' of MAIN - то же, что и выше. Я хотел бы знать, в клоне которого было добавлено репо (добавлено слияние).

3. Могу ли я увидеть, кто выполнял тягу от MAIN до DERIV?
4. Считаете ли вы, что вытащить из MAIN лучший подход? Например, такие же результаты могут быть достигнуты с помощью набора вишни (и, возможно, переустановки).

Благодаря

Answer 1

[EDIT: следующий обновленный вопрос]

Если вы регистрируетесь как пультов ДУ, вы можете увидеть, какие коммиты зарегистрированы на MAIN и которые зарегистрированы на DERIV.

$ git clone gitserver:deriv.git 
$ cd deriv 
$ git remote add main gitserver:main.git 
$ git fetch main 

Вы должны увидеть ветку main/master в вашем репо, который покажет вам, какие коммиты являются частью MAIN и которые не являются.

[/ EDIT]

Короткий ответ:

1. да
2. нет, но это, вероятно, не имеет значения
3. нет, но это, вероятно, не имеет значения
4. да

о git журнале:

Я предполагаю, что вы начали свой DERIV репозиторий запустив git clone MAIN DERIV, и что вы хотите рабочий процесс, где Вы тянете из MAIN, но никогда не толкать.

В этом случае DERIV хранилище «знает» о существовании MAIN и GIT команд (в основном git fetch) позволяют интегрировать историю MAIN «s в DERIV.

Каждый раз, когда вы запускаете git fetch (git pull фактически git fetch с последующим git merge), вы будете импортировать MAIN «s историю в DERIV, и ее нынешние ветви будут видны и помечены с префиксом origin/.

• вы можете запустить git branch -r, чтобы увидеть список филиалов с MAIN
• вы можете запустить git log origin/branchname, чтобы просмотреть историю branchname на MAIN
• при запуске git log --decorate, при каждой фиксации будут отображаться с именами ветвей и теги, указывающие на него
• эти аннотации будут появляться графические инструменты, как gitk

Затем вы можете определить, какие ветви в ваших проектах DERIV имеют встроенные изменения от проекта MAIN.

Если у вас есть филиалы в DERIV отслеживания ветвей в MAIN (это поведение по умолчанию master), git status сообщит вам, если DERIV «ветвь s отсутствует коммиты из MAIN» ветви s.

Если вы в основном с помощью командной строки, две команды очень удобны:

git log --graph --decorate --pretty=oneline --abbrev-commit 
git log --graph --decorate --pretty=oneline --abbrev-commit --all 

Вы можете add them as shortcuts in your config file.

о том, кто тянул и когда

Вы увидите даты и автор MAIN «s совершившей, вы увидите, дату и автор слияний в DERIV» s совершает, когда будут конфликты с MAIN , Вы не увидите, кто именно втянул историю.

git fetch фактически (почти) безвредны команда, которая будет импортировать MAIN «s история и не лезьте с DERIV ветвей (что будет сделать, это добавить кучу коммитов в репозиторий, и переместить все origin/* ветви, импортируются).

тянуть против вишневого выбрать

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

Что еще?

git fetch/git merge/git pull определенно способ пойти, чтобы сохранить два хранилища в синхронизации. Что вам нужно, это набор правил для филиалов.

Может быть, вы заинтересованы только в некоторых отдельных отраслях MAIN (master, release, ...), а не в остальных (dev, test, tmp ...): вы можете настроить DERIV хранилище для импорта только некоторые по умолчанию (details here).

Удобно иметь локальные филиалы, отражающие удаленные ветви, но, возможно, вы не хотите, чтобы DERIV:master был «жестко связан» с MAIN:master.

Если вы хотите отменить связь master и origin/master, вы можете отредактировать файл .git/config и удалить раздел [branch "master"].

Если вы хотите создать локальную ветвь, которая отслеживает удаленную ветку с другим именем, вы можете запустить:

git branch main/v10 --track origin/v10 

main/v10 будет местный филиал, который отслеживает удаленный v10 ветвь.

Заключение

мерзавец ответ редко бывает полной без указания на The Book. Потратьте время, чтобы прочитать его, он имеет очень высокое соотношение relevant explanation/line of text. Chapter 3 касается разветвления и слияния.