Як я можу переглянути попередній злиття в git?

У мене є гіт git (основна лінія, наприклад), і я хочу об'єднатися в іншу галузь розвитку. Або я?

Для того, щоб вирішити, чи дійсно я хочу об'єднати цю гілку, я хотів би переглянути якийсь попередній перегляд того, що буде робити злиття. Переважно з можливістю перегляду списку комітетів, які застосовуються.

Поки що найкраще я можу придумати - merge --no-ff --no-commitі тоді diff HEAD.

Я виявив, що найкраще рішення для мене полягає в тому, щоб просто виконати злиття і перервати його, якщо є конфлікти . Цей особливий синтаксис мені здається чистим і простим. Це стратегія 2 нижче.

Однак якщо ви хочете переконатися, що ви не зіпсуєте свою поточну гілку, або ви просто не готові до злиття незалежно від наявності конфліктів, просто створіть нову підгалузь із неї та об'єднайте:

Стратегія 1: Безпечний спосіб - злиття тимчасової гілки:

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

Таким чином ви можете просто викинути тимчасову гілку, якщо ви просто хочете побачити, що таке конфлікти. Вам не потрібно заважати "переривати" злиття, і ви можете повернутися до своєї роботи - просто замовте "mybranch" ще раз, і у вас не буде конфлікту злитого коду або злиття.

Це в основному сухий хід.

Стратегія 2: Коли ви напевно хочете об'єднатись, але тільки якщо немає конфліктів

git checkout mybranch
git merge some-other-branch

Якщо git повідомляє про конфлікти (і ТІЛЬКО, якщо в них є конфлікти), ви можете зробити:

git merge --abort

Якщо злиття успішно, ви не можете його скасувати (лише скинути).

Якщо ви не готові до злиття, скористайтеся вище безпечним способом.

[EDIT: 2016-листопад - я змінив стратегію 1 на 2, тому що, здається, більшість людей шукають "безпечний шлях". Стратегія 2 тепер більше зауважує, що ви можете просто перервати злиття, якщо злиття має конфлікти, з якими ви не готові мати справу. Майте на увазі, читаючи коментарі!]

• git log ..otherbranch
  • перелік змін, які будуть об'єднані в поточну галузь.
• git diff ...otherbranch
  • відрізняється від загального предка (злиття бази) до голови того, що буде злито. Зверніть увагу на три крапки , які мають особливе значення порівняно з двома крапками (див. Нижче).
• gitk ...otherbranch
  • графічне зображення гілок, оскільки вони були об'єднані востаннє.

Порожній рядок має на увазі HEAD, так що саме тому ..otherbranchзамість HEAD..otherbranch.

Дві та три крапки мають дещо інше значення для відмінності, ніж для команд, що перелічують версії (log, gitk тощо). Для журналу та інших двох крапок ( a..b) означає все, що є, bале немає, aа три крапки ( a...b) означає все, що є лише в одній з aабо b. Але diff працює з двома редакціями, і там простіший випадок, представлений двома крапками ( a..b), є простою різницею від aдо bі трьома крапками ( a...b) означає різницю між загальним предком і b( git diff $(git merge-base a b)..b).

Якщо ти схожий на мене, ти шукаєш рівнозначного svn update -n. Здається, що зробити трюк. Зауважте, що переконайтеся, що спочатку потрібно зробити git fetchтак, щоб місцева репорта мала відповідні оновлення для порівняння.

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

або якщо ви хочете відрізнятись від голови до віддаленого:

$ git fetch origin
$ git diff origin/master

ІМО це рішення набагато простіше і менш схильний до помилок (і, отже, набагато менш ризикований), ніж верхнє рішення, яке пропонує "об'єднати, то скасувати".

Більшість відповідей тут або вимагають чистого робочого каталогу та декількох інтерактивних кроків (погано для сценаріїв), або не працюють у всіх випадках, наприклад, минулі злиття, які вже вносять деякі видатні зміни у вашу цільову гілку, або вишні, які роблять те саме.

Щоб по-справжньому побачити, що зміниться у masterгілці, якби ви об’єдналися developв неї, прямо зараз:

git merge-tree $(git merge-base master develop) master develop

Оскільки це сантехнічна команда, вона не здогадується, що ви маєте на увазі, ви повинні бути явними. Він також не забарвлює вихід або не використовує ваш пейджер, тому повною командою буде:

git merge-tree $(git merge-base master develop) master develop | colordiff | less -R

- https://git.seveas.net/previewing-a-merge-result.html

(дякую Девіду Нормінгтону за посилання)

PS:

Якщо у вас з'являться конфлікти злиття, вони відображатимуться зі звичайними маркерами конфліктів у висновку, наприклад:

$ git merge-tree $(git merge-base a b ) a b 
added in both
  our    100644 78981922613b2afb6025042ff6bd878ac1994e85 a
  their  100644 61780798228d17af2d34fce4cfbdf35556832472 a
@@ -1 +1,5 @@
+<<<<<<< .our
 a
+=======
+b
+>>>>>>> .their

Користувач @dreftymac робить хороший момент: це робить його непридатним для сценаріїв, тому що ви не можете легко зрозуміти це з коду статусу. Маркери конфлікту можуть бути дуже різними залежно від обставин (видалено проти модифікованих тощо), що також важко сприймає. Остерігайся.

Якщо ви вже знайшли зміни, моя улюблена:

git log ...@{u}

Для цього потрібен git 1.7.x Я все ж вважаю. @{u}Позначення є «скорочена» для висхідного потоку гілки , так що це трохи більш універсальний , ніж git log ...origin/master.

Примітка. Якщо ви використовуєте zsh та розширений glog, вам, ймовірно, доведеться зробити щось на кшталт:

git log ...@\{u\}

Додаючи до існуючих відповідей, псевдонім може бути створений для показу розрізнення та / або журналу перед об'єднанням. Багато відповідей опускають те, fetchщо потрібно зробити спочатку перед "попереднім переглядом" об'єднання; це псевдонім, який поєднує ці два кроки в один (емілюючи щось подібне до mercurial's hg incoming/ outgoing)

Отже, спираючись на " git log ..otherbranch", ви можете додати таке ~/.gitconfig:

...
[alias]
    # fetch and show what would be merged (use option "-p" to see patch)
    incoming = "!git remote update -p; git log ..@{u}"

Для симетрії можна використовувати наступний псевдонім, щоб показати, що зроблено і що було б натиснуто, перед натисканням:

    # what would be pushed (currently committed)
    outgoing = log @{u}..

І тоді ви можете запустити " git incoming", щоб показати багато змін, або " git incoming -p" показати патч (тобто "diff"), " git incoming --pretty=oneline", щоб отримати короткий підсумок тощо. Потім ви можете (необов'язково) запустити "git pull " насправді зливаються. (Хоча, оскільки ви вже зібрали, злиття можна зробити безпосередньо.)

Так само " git outgoing" показує, що було б натиснуто, якби ви бігали " git push".

git log currentbranch..otherbranchнадасть вам список комітетів, які ввійдуть у поточну гілку, якщо ви зробите об'єднання. Звичайні аргументи для входу в журнал, які дають інформацію про коміти, дадуть вам більше інформації.

git diff currentbranch otherbranchдасть вам різницю між двома зобов'язаннями, які стануть одним. Це буде різниця, яка дає вам усе, що злиється.

Чи допомогли б вони?

Запит на витяг - я використовував більшість вже поданих ідей, але один, який я також часто використовую, - це особливо, якщо це від іншого розробника), виконуючи запит на витягнення, який дає зручний спосіб переглянути всі зміни в об'єднанні, перш ніж він займеться місце. Я знаю, що це GitHub не git, але це впевнено зручно.

Окрім того, що насправді виконують злиття у викиданні (див. Відповідь Касапо), здається, це не є надійним способом побачити це.

Сказавши це, ось метод, який гранично близький:

git log TARGET_BRANCH...SOURCE_BRANCH --cherry

Це дає справедливу вказівку, які коміти перетворять їх на злиття. Щоб побачити відмінності, додайте -p. Щоб побачити імена файлів, додати будь-який з --raw, --stat, --name-only,--name-status .

Проблема з git diff TARGET_BRANCH...SOURCE_BRANCHпідходом (див. Відповідь Яна Гудека) полягає в тому, що ви побачите різницю для змін вже у вашій цільовій гілці, якщо ваша вихідна гілка містить перехресні злиття.

Може, це може вам допомогти? git-diff-tree - порівнює вміст і режим крапок, знайдених через два об’єкти дерева

Я не хочу використовувати команду git merge як попередник перегляду конфліктуючих файлів. Я не хочу робити злиття, я хочу виявити потенційні проблеми, перш ніж об'єднатись - проблеми, які автоматично злиття можуть ховатися від мене. Я шукав рішення - як git виплюнути список файлів, які були змінені в обох гілках, які в майбутньому будуть об'єднані, відносно якогось загального предка. Після того, як у мене з’явиться цей список, я можу використовувати інші інструменти порівняння файлів, щоб далі розвідати речі. Я шукав кілька разів, і досі не знайшов того, що хочу в рідній команді git.

Ось мій спосіб вирішення, якщо він допомагає комусь іншому:

У цьому сценарії у мене є філія під назвою QA, яка змінила багато змін із часу останнього випуску продукції. Наш останній випуск продукції позначений "15.20.1". У мене є ще одна галузь розвитку під назвою new_stuff, яку я хочу об'єднати у гілку QA. Як QA, так і new_stuff вказують на зобов'язання, які "слідують" (як повідомляє gitk) тег 15.20.1.

git checkout QA
git pull
git diff 15.20.1 --name-only > QA_files
git checkout new_stuff
git pull
git diff 15.20.1 --name-only > new_stuff_files
comm -12 QA_files new_stuff_files

Ось кілька дискусій, які стосуються того, чому мені цікаво орієнтуватися на ці конкретні файли:

Як я можу довірити злиття Git?

/software/199780/how-far-do-you-trust-automerge