2 ветки с одним именем

Емнип, имена веток в области экземпляра репозитория глобальны. Удалить A-C не вариант?

git branch -D topic && git checkout -b topic master

backbone

Удалить A-C не вариант?

хм, а коммиты удаляются в таком случае?

Дело в том что меня смущает то что такие варианты впринципе возможны:

                     A---B---C                N---O---P topic
                    /         \              /
               D---E---F---G---H---I---J---K---L---M master

Есть сомнения, что вы понимаете, что хотите. Считайте, что ветка — это путь файлу, это разделяемый ресурс, её имя означает вполне конкретный указатель в области данного проекта. Как вы собираетесь указывать на уникальные ресурсы с одним и тем же именем? Для указания ревизии можно использовать SHA1-ключ, но всё же ветка с осмысленным именем, чем именно эта ветка отличается от другой похожей, предпочтительней.

Да, неименованная ветка (detached head) это потерянный ресурс, считай, удалённый файл. Содержимое ещё может быть на разделе и потенциально восстановимо, но ФС или git-gc могут в любой момент всё почистить.

хм, а коммиты удаляются в таком случае?

Да, но удаление одной ветки ни в коем случае не трогает остальные ветки. Другими словами нельзя удалить то, что никогда не было в master. Тут больше вопрос к вам — нужны ли вам коммиты A-C в ветке master?

Dendy

Да, неименованная ветка (detached head) это потерянный ресурс, считай, удалённый файл.

Я могу насодавать кучу неименованных веток локально и могу перемещаться по ним использую контрольные суммы коммитов. Что я делаю не так?

Я просто хотел чтобы эти коммиты были сохранены в удаленный реп.

Я могу насодавать кучу неименованных веток локально и могу перемещаться по ним использую контрольные суммы коммитов. Что я делаю не так?

git help gc

Some git commands may automatically run git gc; see the --auto flag below for details.

При разростании дерева git gc будет запущен автоматом, если стоит gc.auto и все неименованные ветки исчезнут навсегда. Сам регулярно наблюдаю этот эффект после нескольких вызовов git rebase.

хм, а коммиты удаляются в таком случае?

Если до удаления ветки было произведено слияние с другой веткой, то коммиты останутся (git branch -d предупредит об удалении «несмерженной» ветки).

Слияние C+G->H в принципе возможно и после создания I, но это очень плохо для всех и потребуется перестраивать историю, поэтому либо производить сливание topicC->masterM, именуя topicP по-другому, либо слияние G+C->H, git branch -d topic; commit I, J, K, git checkout -b topic.

Кстати, удачная модель ветвления для Git, по-моему, действительно хорошая статья.

Cчитайте, что ветка — это путь файлу

Git как VCS оперирует не файлами.

Кстати, удачная модель ветвления для Git, по-моему, действительно хорошая статья.

Удваиваю. Вот, кстати, оригинал, там же можно скачать PDF: http://nvie.com/posts/a-successful-git-branching-model/

В pdf только картинка, хотя возникла очень дельная мысль распечатать и повесить...

а что смущает? иерархия коммитов? ну делайте rebase на мастер перед мержем, будет все линейно.

Кстати, удачная модель ветвления для Git, по-моему, действительно хорошая статья.

Все они кажутся удачными, пока не попробуешь очереди патчей.

x0r

а что смущает? иерархия коммитов?

Смущает то чтобы сделать новую ветку с назавнием как у старой несмерженной невозможно. Нужно либо удалять старую либо делать merge.

x0r

ну делайте rebase на мастер перед мержем, будет все линейно.

Я пытаюсь сохранить историю всех действий в удаленном репе, не плодя названия веток. А rebase какраз все портит.

Все они кажутся удачными, пока не попробуешь очереди патчей.

Угу, теоретики блин.

Я пытаюсь сохранить историю всех действий в удаленном репе, не плодя названия веток. А rebase какраз все портит.

/0

Зачем тебе инфа о слияниях? Линейная история это прекрасно.

К примеру, какой-то патч можно логически разделить на несколько шагов для упрощения понимания. Не часто такое происходит и маловероятно, что кто-то будет разбираться после принятия патча спустя длительное время, но всё же...

Гм, вы не путаете rebase со сквошем, случаем?

Вроде не путаю, rebase изменяет последовательность коммитов, при необходимости отрбрасывая некоторые. squash «сжимает» группу коммитов в один. Возможно, что-то ещё, но это только то, что мне известно.

Имел в виду, что информация о слиянии поможет определить, что группа коммитов относится к реализации отдельной «фичи». Это из той статьи.

*   commit 4 (HEAD, develop)
|\  Merge: 1 3
| | 
| |     Merge branch 'featureA' into develop
| |   
| * commit 3
| | 
| |     Feature A step2.
| |   
| * commit 2
|/   
|       Feature A step1.
|  
* commit 1 (master)
  
      Initial commit.

Имел в виду, что информация о слиянии поможет определить, что группа коммитов относится к реализации отдельной «фичи».

Ах да, знаю. Есть такие любители длинных бород из fix, typo, тупанул, поправочка и т.д. в основной репе.

Потом очень весело наблюдать за их попытками забисектиться.

Ах да, знаю. Есть такие любители длинных бород из fix, typo, тупанул, поправочка и т.д. в основной репе.

Я о другом, Джеймс Боттомли на лекции говорил: «По возможности разбивайте патч на группу осмысленных шагов, чтобы принимающему было легче понять суть изменений.».

«fix, typo, тупанул» в главной репе быть не должно, конечно.

Потом очень весело наблюдать за их попытками забисектиться.

Ну и понятное дело, в мастер-ветке «поломатых» ревизий быть не должно.

Зачем тебе инфа о слияниях? Линейная история это прекрасно.

Человек, мне ненужна информация о слияниях, мне нужны коммиты из несмерженных веток. И чтобы названий этих веток было минимум.

То что ты изобразил мержится fastforward'ом. rebase позволяет объединить 2 ветки в одну, причем чем-то придется пожертвовать. Им никогда не пользуются когда ветки хранятся на общем ресурсе и я небуду.

То что ты изобразил мержится fastforward'ом.

В той статье указывается, зачем используется git merge --no-ff, вроде кратко пересказал ту мысль.

По поводу rebase, если это временная ветка, то, думаю, ничего страшного в этом нет. Мне удобнее сделать reset --soft, подправить все накопленные изменения и после сделать один коммит или разбить на несколько шагов. После - смержить в develop с --no-ff (можно git pull --rebase, merge ff...) и удалить featureA.

Кароч, я решил создать ветку trash куда буду мержить ненужные ветки. Вот я молодец. Надо будет написать статью с тегом [история успеха]

По возможности разбивайте патч на группу осмысленных шагов, чтобы принимающему было легче понять суть изменений

Очень спорно. Оценивать зависимые изменения по нескольким патчам не самое приятное занятие.

Если не взаимозависимые, то определённо должно упрощать. Это фича Б, для неё нам потребовалось добавить фичу А, которая даёт возможность создавать фичи типа Б.

Смущает то чтобы сделать новую ветку с назавнием как у старой несмерженной невозможно.

абослютно не ясно как вы тогда будете например чекаутить такие ветки.

Я пытаюсь сохранить историю всех действий в удаленном репе

не ясно зачем вам имена веток, история и так будет иерархичная.

Это фича Б, для неё нам потребовалось добавить фичу А, которая даёт возможность создавать фичи типа Б.

Дык, это и есть отдельные патчи, они даже не обязательно должны последовательно в истории идти, не говоря уж об отдельной ветке.

x0r

абослютно не ясно как вы тогда будете например чекаутить такие ветки.

елмн, я ж всё написал. Просто по контрольной сумме, а контрольную смму посмотрю в дереве. И то это если понадобится.

Они связаны, A сделан для реализации B. A в отсутствие B несёт неиспользуемый функционал и может быть отброшена. К примеру, A содержит множество простейших вспомогательных функций для B, а B - изменение на верхнем логическом уровне и занимает пару строк, а C добавляет в файлы gettext перевод для этих функций.

Можно сделать 3 патча, можно даже разбросать по истории, но то, что изменения связаны по смыслу и ясно видно разделение их по логическим уровням делает понятной их суть читающему. Мне так думается.

A содержит множество простейших вспомогательных функций для B, а B - изменение на верхнем логическом уровне и занимает пару строк, а C добавляет в файлы gettext перевод для этих функций.

Это всё должно идти одним патчем. Иначе ад и израиль.

Ну не знаю... Мне удобнее посмотреть патч в 2 строчки, чтобы понять, какой функционал он несет. Тем более, что в мастер это и будет 1 ревизия.