BitBucket - Просмотр изменений вручную в коммите слияния - PullRequest
0 голосов
/ 17 апреля 2019

BitBucket имеет хороший запрос Pull Request (PR) для просмотра изменений кода, связанных с фиксацией.Но иногда мы оказываемся в ситуации, когда у нас есть две относительные долгоживущие ветви, например, «разработка» и «будущее-выпуск», которые могут немного отличаться.Когда приходит время для слияния future_release с development, требуются некоторые ручные усилия для устранения проблем, связанных с расхождением этих ветвей.

Предположим, что все изменения кода до слияния как в "velop ", так и в" future_release "имеютуже прошел экспертную оценку и не нуждается в повторной проверке.

Есть ли какой-нибудь хороший способ, используя пользовательский интерфейс BitBucket Pull Requests или иным образом, специально просматривать ручные изменения кода, которые были сделаны как часть самого слияния, для разрешения конфликтов и, возможно, других несоответствий?

1 Ответ

1 голос
/ 19 апреля 2019

Bitbucket в настоящее время не имеет способа увидеть, какие изменения были внесены в коммит слияния как часть разрешения конфликтов слияния.Однако это не так сложно сделать в командной строке.

Подумайте об этом следующим образом: кто-то попытался выполнить слияние, и из-за конфликтов он остался в «незакрытом» состоянии.Они внесли некоторые изменения, чтобы разрешить конфликты, зафиксировали эти изменения, а затем они получили новый коммит слияния в результате.Если вам известен этот коммит слияния, то вы знаете две вещи, которые они пытались слить (потому что они являются родительскими коммитами коммита слияния).Таким образом, вы можете перевести себя в то же самое состояние, в котором они находились, и затем провести различие между этим состоянием и их результирующим коммитом слияния.

Вот скрипт bash, который делает именно это для вас:

#!/bin/bash

# Pass the merge commit as the only argument to the script
COMMIT="$1"
# Create a temporary directory where we'll use a copy of the repo
TMP_REPO="$(mktemp -d)"

# Clone the original repo into the temporary directory, and setup the
# original repo as an "alternate" using --shared
git clone --quiet --shared . "${TMP_REPO}"
cd "${TMP_REPO}"

# Checkout the first parent of the merge commit (this is the "destination"
# commit of the merge)
git checkout --quiet "${COMMIT}^1"
# Merge the second parent (the "source" of the merge) of the merge
# commit into the first, creating "unmerged" state with conflicts
printf "GIT MERGE OUTPUT:\n\n"
git merge --quiet --no-commit "${COMMIT}^2"
# Stage everything in the working tree, including all unresolved conflicts
git add .
# Commit the changes
git commit --quiet --message "Commit all merge conflicts"

printf "\n==================================================\n\n"

# Do a diff between the commit you just created and the original merge commit
git diff --find-renames "HEAD..${COMMIT}"

rm -rf "${TMP_REPO}"

Запустите его из своего репозитория git, передав в качестве единственного аргумента хеш коммита слияния, например:

$ /path/to/script.sh d29ce0c1420b18c7e8f1ce2bf3667f6609bf215d
GIT MERGE OUTPUT:

Auto-merging numbers.txt
CONFLICT (content): Merge conflict in numbers.txt
Automatic merge failed; fix conflicts and then commit the result.

==================================================

diff --git a/numbers.txt b/numbers.txt
index 18ac646..a4ab7d4 100644
--- a/numbers.txt
+++ b/numbers.txt
@@ -1,9 +1,4 @@
-<<<<<<< HEAD
+two
 four
-five
 six
-=======
-seven
 eight
-nine
->>>>>>> d29ce0c1420b18c7e8f1ce2bf3667f6609bf215d^2
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...