TL; DR
Не используйте для этого REST API. 1 Git не имеет его. Используйте git branch --merged. Но знайте, что он на самом деле делает .
1 Если вы его используете, знайте, что он почти наверняка просто использует git branch --merged, или внутренний эквивалент. Также имейте в виду, что API REST на хост-сервере A отличается от API на хост-сервере B, которое отличается от API на хост-сервере C. Хост-сервер D не имеет API для этого. Но Git может сделать это изначально, и это будет работать независимо от вашего хост-сервера.
Long
Ветви, в Git, не существуют.
ОК, это явно не так: они существуют . Но, что очень важно, они не имеют значения . Только коммиты действительно имеют значение. Имена ветвей в основном служат для find коммитов. Слияние выполняется путем слияния коммитов, даже если вы используете имя ветви в процессе. Так что хитрость заключается в том, чтобы сначала задать вопрос о коммитов . Только позже, после у вас будет этот ответ, если вы начнете задумываться о названиях ветвей.
Из-за этого вообще невозможно сказать, какая ветка была объединена. Но легко определить, объединен ли конкретный commit . И ветвь name , например master или develop, всегда , идентифицирует ровно один коммит. Просто указанный c коммит, который master идентифицирует , меняет с течением времени. То же самое делает c коммит, который идентифицирует develop, и то же самое делает c коммит, который идентифицирует feature2, и т. Д.
Наглядно эти вещи могут выглядеть так:
I--J <-- feature1
/
...--H <-- master
\
K--L <-- feature2
Здесь ни feature1 , ни feature2 не объединены в master. Это связано с тем, что коммит, идентифицируемый по имени feature1, т. Е. Commit J - J, заменяет его фактический идентификатор ha sh, представляющий собой большую некрасивую строку букв и цифр, а не предок коммит H, который является коммитом, идентифицированным именем master. Однако master является объединенным в feature1, потому что commit H является предком commit J. Точно так же master объединяется в feature2.
Если мы теперь используем:
git checkout master
git merge --ff-only feature1
git merge --no-ff feature2
в командной строке, и все работает, мы получаем новый коммит слияния M, так что имя master теперь указывает на этот коммит слияния:
I--J <-- feature1
/ \
...--H M <-- master
\ /
K--L <-- feature2
Обратите внимание, что все, что мы сделали, было добавление коммит к чертежу: новый commit M указывает на существующие коммиты J и L. Имя ветви master теперь идентифицирует коммит M, а не коммит H.
Поскольку J и L оба являются предками M, но M не является предком либо ветви feature1 и feature2 теперь объединены в master. Обратите внимание, что на этом этапе мы можем удалить имя feature1:
I--J
/ \
...--H M <-- master
\ /
K--L <-- feature2
Commit J по-прежнему является предком коммита M, поэтому коммит объединено. Но ветка feature1 больше не существует. Для значения Git не имеет значения, но теперь список имен ветви, которые идентифицируют коммиты, являющиеся предками M, больше не включает feature1. Мы можем сделать то же самое с feature2:
I--J
/ \
...--H M <-- master
\ /
K--L
Теперь мы можем создать новое имя ветви, такое как feature/short, которое указывает на фиксацию J:
I--J <-- feature/short
/ \
...--H M <-- master
\ /
K--L
Commit J по-прежнему является предком коммита M, поэтому ветвь feature/short объединяется с самой веткой master.
Git - не GitHub и не GitLab просто старый Git - может сказать вам, какие имена веток указывают на коммиты, которые являются предками какого-то другого имени ветки:
git branch --merged master
сначала находит коммит M, затем перебирает все имена веток - в этом случае , feature/short - единственное оставшееся имя ветви - чтобы увидеть, является ли коммит, который идентифицирует эти имена ветвей, предком коммита M. На данный момент это верно для feature/short, поэтому git branch --merged выведет список feature/short.
Если мы git checkout feature/short и добавим в него новый коммит, то получим:
I--J---N <-- feature/short
/ \
...--H M <-- master
\ /
K--L
Коммит N - это , а не предок коммита M поэтому ветка feature/short является , а не объединена с веткой master. Запущенный git branch --merged master больше не будет отображать список feature/short.
Имена удаленного отслеживания
Для этого из собственного репозитория Git, а не из какого-либо API хостинг-сервиса, вы будете нужен клон репозитория Git от хостинг-сервиса. Когда вы создаете такой клон, если вы не используете --mirror, 2 , ваши Git будут переименовывать их ветви. Вместо имен ветвей будет иметься серия имен удаленного отслеживания , вида origin/master, origin/develop, origin/feature1 и т. Д.
После копирования их фиксация в вашем хранилище и переименование их имен веток в ваши имена для удаленного отслеживания, ваш собственный Git создаст одно имя ветки в вашем хранилище, указывая на один из существующих коммитов, которые вы получили от них. По умолчанию ваш Git создаст ваш master, указывающий на тот же коммит, что и их origin/master. Однако со временем их имена ветвей изменятся: они будут указывать на новые, более совершенные коммиты. Вам нужно будет выполнить:
git fetch
или:
git fetch --prune
, чтобы ваш Git получил их новые коммиты и обновил имена для удаленного отслеживания. Использование --prune гарантирует, что ваш Git удалит старые, устаревшие имена для удаленного слежения: например, после того, как их Git удалил свои feature/short, ваш Git продолжит иметь origin/feature/short пока вы не сделаете выборку с включенной обрезкой. Затем ваш Git заметит, что они не имеют feature/short и удалят ваш origin/feature/short.
. То, что вы хотите сделать здесь, это использовать:
git branch --merged -r origin/master
Опция -r указывает git branch искать ваши имена для удаленного слежения , а не имя ветви 1212 *. origin/master говорит вашему Git использовать коммит, который идентифицирует ваш origin/master - их master с момента вашего последнего получения обновления. Так что теперь вы получите список типа origin/feature1 и origin/master в качестве имен для удаленного отслеживания, которые указывают на коммиты, которые являются предками коммита, на который указывает origin/master.
2 Вряд ли вы захотите использовать --mirror.