В git, как я могу найти версию, в которой была создана ветка?
UPDATE: пример репозитория, https://github.com/so-gitdemo/so-gitdemorepo
В контексте репликации github. Как я могу легко найти rev "b0430cee"? Я знаю, что могу просто посмотреть, но реальный пример того, что этот репозиторий имитирует, есть дюжина коммиттеров и несколько других ветвей. Не так просто провести осмотр.
Как я могу найти ревизию создания ветки, когда ветвь была объединена несколько раз?
Мне известен этот вопрос: Как определить, когда была создана ветвь Git?
Решение не работает для ветки, которая была объединена несколько раз. Обычно мы объединяем исправления ошибок с ветки выпуска в основную ветку. Возможно, мы даже ошибаемся в этой части... новичок в git.
Представьте себе следующее простое. Реальная вещь МНОЖЕ больше совершает работу с мастером/филиалом от нескольких людей. Есть также несколько ветвей релиза (думаю, 1.0, 1.1, 1.2, 1.3)
Future dev ?
|
|
Merge 1.0 back * ? Potential future fixes
|\ |
| \|
| \
New work * |
| * Emergency bug fix
| |
Merge 1.0 back * |
|\ |
| \|
| * Another bug fix
| |
| |
New feature * * First bugfix on branch 1.0
| /
| /
|/
* Feature
|
|
|
* Some feature
|
|
|
* The past (master)
Мы все еще новичок в Git и разрабатываем лучший способ управления релизами и веткими, и мы решили, что нам нужно ретроактивно добавить некоторые теги в репо. Например, тег 1.0 для начала ветвей 1.0 и более поздних 1.0.1 для выпусков исправлений.
Вопрос о дополнительном бонусе: какой лучший способ добавить теги, которые я хочу? и на какой ревизии я должен пометить? первая фиксация на новой ветке? или первая общая фиксация перед фиксацией ветки?
Ответы
Ответ 1
Поскольку вы добавили репозиторий git... я работал удаленно, чтобы проверить что-то.
Как я могу легко найти rev "b0430cee"?
В этом случае эта симпатичная oneliner сделала для меня работу:
git rev-list --reverse --topo-order --left-right --boundary 1.0...master |
grep "^>" -B1 |
head -1 |
cut -c2-
Если вы хотите получить 469c14a1fa8a40237700 (New feature work
), это работает для меня:
git rev-list --reverse --topo-order --left-right --boundary 1.0...master |
grep "^>" |
head -1 |
cut -c2-
НТН
Ответ 2
Меня бросают взад и вперед по тому, что вы просите, читая вопрос.
Если вам действительно нужен только корень ветки, я думаю, вам нужно что-то вроде
git rev-list --merges --boundary branch1 branch2 | tail -1
Если вы хотите убедиться, что ветки на самом деле связаны
git rev-list --left-right --merges --boundary branch1 branch2 |
grep '^-' |
tail -1 |
cut -c2-
Однако вероятность того, что вы хотите
git merge-base branch1 branch2
Кроме того, следующее следующее будет полезно в следующий раз, когда вам понадобятся красивые диаграммы ласточкинских хвостов:
git show-branch # [--mergebase] branch1 branch2
Вы можете получить немного больше контроля с помощью git log:
git log --graph --left-right --merges --boundary HEAD MP26/MP26
> commit 0118d9979d1d27f08fa14cddfffa3e9c2cd5fe9c
|\ Merge: 8958c53 e1cd319
| | Author: Seth Heeren <[email protected]>
| | Date: Fri Feb 18 12:05:49 2011 +0100
| |
| | Merge branch 'MP26' into tmp
| |
| o commit e1cd31926d01c08092a95226ac7b49bbea19ac92
| Author: Seth Heeren <[email protected]>
| Date: Thu Feb 17 16:39:17 2011 +0100
|
| xxxxx
|
o commit 8958c534b034cbb28bf1e853de0bfec0a9b0ddbb
Author: Seth Heeren <[email protected]>
Date: Fri Feb 18 12:05:30 2011 +0100
fixup
Git log также поддерживает параметр --decorate
, если вам нравится отображение имени ветки с git show-branch
Ответ 3
Возможно, я неправильно понимаю вопрос, но ветки определяются фиксацией на их конце, и каждый предок этой фиксации содержится в ветке. Например, предположим, что emergency-bug-fix
- ветвь с концом в Emergency bug fix
на диаграмме - самая старая фиксация на этой ветки будет The past (master)
. "Версия, в которой была создана ветка", не является четко определенной концепцией, если вы просто посмотрите на график фиксации.
Если вас просто беспокоит, когда ветка была создана в определенном репозитории, вы можете использовать "reflog" - например, посмотрите на последнюю строку на выходе:
git reflog show emergency-bug-fix
Однако результаты этой команды будут отличаться от репозитория в репозитории, в зависимости от того, когда был создан ref, например, путем извлечения или нажатия. Кроме того, по умолчанию reflog истекает через 90 дней, он может не иметь такой информации. Если у вас есть благословенный центральный репозиторий, вы можете сделать попытку там же, и это может дать вам фиксацию, где этот ref был сначала создан в централизованном репозитории. Я не думаю, что решение, которое вы хотите, однако.
Как вы правильно разобрались, лучше всего просто пометить точки в графе фиксации, которые вас интересуют. Магнус Skog answer рассказывает вам, как для этого.
Ответ 4
Очень легко добавлять теги ретроактивно в git. Все, что вам нужно сделать, это передать хэш-код sha1 команде тега git (спасибо Sehe):
git tag 1.0 abcd1232
git push origin 1.0
Трудно ответить на ваш второй вопрос, так как трудно определить, что является "лучшим". На работе у нас есть ветка разработки, с которой все работают, и когда мы решаем, что хотим выпустить, мы создаем ветвь релиза, например. rel-1.0, и эта ветвь живет, пока мы не решим, что с ней все пошло. Затем мы объединяем его в master, tag с 1.0 и удаляем ветвь release. Поэтому тег для нас всегда должен считаться святым и стабильным, каким он может быть. Таким образом, в нашем случае это всегда фиксация слияния, которая создается, когда мы объединяем ветвь release в master.