В git как найти ревизию, на которой была создана ветка? - PullRequest
17 голосов
/ 19 мая 2011

ОБНОВЛЕНИЕ: пример репозитория, 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 для выпусков исправлений.

Дополнительный бонусный вопрос: Как лучше всего добавить нужные теги?и на какую ревизию я должен пометить?первый коммит на новой ветке?или первый общий коммит перед коммитом ветки?

Ответы [ 4 ]

6 голосов
/ 19 мая 2011

Так как вы добавили 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-

HTH

6 голосов
/ 19 мая 2011

Я немного расстроен тем, что вы спрашиваете во время чтения вопроса.

Если вы действительно хотели получить только корень ветки, я думаю, вы хотели что-то вроде

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 <seth.heeren@xxxx>
| | Date:   Fri Feb 18 12:05:49 2011 +0100
| |
| |     Merge branch 'MP26' into tmp
| |
| o commit e1cd31926d01c08092a95226ac7b49bbea19ac92
|   Author: Seth Heeren <seth.heeren@xxxx>
|   Date:   Thu Feb 17 16:39:17 2011 +0100
|
|       xxxxx
|
o commit 8958c534b034cbb28bf1e853de0bfec0a9b0ddbb
  Author: Seth Heeren <seth.heeren@ocwduo.nl>
  Date:   Fri Feb 18 12:05:30 2011 +0100

      fixup

Журнал Git также поддерживает опцию --decorate, если вам нравится отображение названия ветви с git show-branch

2 голосов
/ 19 мая 2011

Возможно, я неправильно понял вопрос, но ветки определяются коммитом в их конце, и каждый предок этого коммита содержится в ветке.Например, предположим, что emergency-bug-fix - это ветвь с наконечником Emergency bug fix на диаграмме - самый старый коммит в этой ветке будет The past (master).«Редакция, в которой была создана ветвь» не является четко определенной концепцией, если вы просто посмотрите на граф фиксации.

Если вы просто обеспокоены тем, когда ветвь была создана в определенном хранилище,вы могли бы использовать «reflog» - например, посмотрите на последнюю строку в выводе:

git reflog show emergency-bug-fix

Однако результаты этой команды будут отличаться от репозитория к репозиториюв зависимости от того, когда ссылка была создана там, например, путем извлечения или нажатия.Кроме того, по умолчанию срок действия reflog истекает через 90 дней, он может больше не иметь этой информации.Если у вас есть благословенный центральный репозиторий, вы можете сделать то же самое там, и это может дать вам коммит, где этот реф был впервые создан в централизованном репозитории.Однако я не думаю, что это то решение, которое вам нужно.

Поскольку вы правильно разработали, лучше просто пометить точки на графике коммитов, которые вас интересуют. MagnusОтвет Скога говорит вам, как это сделать.

0 голосов
/ 19 мая 2011

Очень легко добавлять теги задним числом в git. Все, что вам нужно сделать, это передать хэш sha1 команде git tag (спасибо Sehe):

git tag 1.0 abcd1232
git push origin 1.0

Трудно ответить на ваш второй вопрос, так как трудно определить, что является "лучшим". На работе у нас есть ветвь разработки, с которой все работают, и когда мы решаем, что хотим выпустить, мы создаем ветку релиза, например, rel-1.0 и эта ветвь живет, пока мы не решим, что с ней покончено. Затем мы объединяем его с master, помечаем 1.0 и удаляем ветку release. Поэтому тег для нас всегда должен рассматриваться как святой и как можно более устойчивый. Так что в нашем случае это всегда коммит слияния, который создается при слиянии ветки релиза с master.

...