2013-09-03 7 views
3

Моя компания использует Kiln, поэтому разработчики могут использовать свой предпочтительный инструмент между Git и Mercurial. Я пользователь Git и никогда не использовал Mercurial.Как управлять ветвями с помощью Kiln с помощью Git?

Есть некоторые недочеты в использовании ветвей с печью. Когда я создаю новую ветку с использованием интерфейса Kiln, в действительности она создает новый репозиторий, а не ветку. Даже если Kiln отображает его как «ветвь», а не «репозиторий». И когда я клонирую репозиторий в Git, git branch -a не показывает мне удаленную ветвь, которую я только что создал. Мне нужно клонировать каждую псевдо-ветвь независимо.

С другой стороны, если я создаю ветку в Git и подтолкнуть его к удаленному серверу, он не создает филиал на печи, но какое-то «подотрасль» называется «голова» видимый во всех ветвях. Очень смущает. Но, по-видимому, нет никакого способа создать эту «суб-ветку», которая отлично работает с Git через интерфейс Kiln. Я также не знаю, хорошо ли они работают на Mercurial.

$ git branch -a 
* master 
    remotes/origin/HEAD -> origin/master 
    remotes/origin/feature2 
    remotes/origin/master 

Я убежден, что это связано с про-Mercurial "философии" печи. Я провел несколько исследований по Mercurial и выяснил, что система филиалов полностью отличается от Git. Это нормально, чтобы клонировать хранилище, чтобы создать ветку, а в Git это не имеет смысла. Mercurial имеет также «названные филиалы», которые нельзя удалить, а их использование не поощряется разработчиками Kiln. Могут ли мои «под-ветви» быть фактически «названными ветвями»? Проблема в том, что я могу удалить эти «подсечки», используя git push origin :sub-branch.

Ответ должен быть очевиден, так как разветвление является важным признаком как Mercurial, так и Git и Kiln, должно быть, простыми и изящными способами ведения ветви с использованием обоих инструментов. Но я не могу понять логику Килна. Я боюсь, что Kiln может быть слишком Mercurial-friendly и что поддержка Git может быть больше похожа на хак.

+1

Мы попробовали и отказались от "печной Ветви". Вместо того, чтобы облегчать ветвление в HG, это фактически делает разветвление намного сложнее IMO. Мы просто придерживаемся филиалов HG. –

ответ

1

На пользовательском интерфейсе Kiln, когда вы создаете ветку, это «клон-ветвь», а не ветка с именем Mercurial.

Если вы используете названные ветви в Mercurial, они будут автоматически переведены в ветви Git. Однако, когда вы передаете ветку Git, она не будет возвращаться к той же именованной ветке в Mercurial. Команда Kiln должна была найти лучший аналог для Git-to-Mercurial перевода филиалов Git, и они решили, что «закладка Mercurial» работает лучше всего. Поэтому, когда вы нажимаете на ветвь Git, она обновляет или создает соответствующую закладку Mercurial (https://www.mercurial-scm.org/Bookmarks, http://mercurial.aragost.com/kick-start/en/bookmarks/) с тем же именем ветки Git, и эта закладка будет находиться в ветке «default» в Mercurial. Я проверил бы с членами вашей команды, которые используют Mercurial, чтобы посмотреть, будет ли использование закладок в качестве аналога для филиалов Git.

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

+1

Итак, вы подтверждаете, что нет способа заставить Git и Mercurial работать вместе? Почему требование Kiln позволяет разработчикам использовать оба инструмента, если мы не можем поддерживать рабочий процесс нашего инструмента и должны придерживаться рабочего процесса другого? Неужели нет способа, чтобы Гит видел «клонов» как ветви? И к Меркуриалу, чтобы увидеть ветви Гита как «клонированные ветви»? –

1

Команда в Kiln обратилась к тому, как объединить хранилища в следующем сообщении. Это должно предоставить вам информацию, необходимую для объединения вашего филиала/репозитория Kiln. По существу, вы делаете тягу, а затем выталкиваете из одного хранилища в другой.

Kiln Branch\Repository Merging

Хотя мерзавец, кажется, не имеют каких-либо ветвления вопросы, которые можно было бы обычно слышать о в рт.ст.; Джоэл Спольский заявил, что решение о поддержке hg over git вышло из заявления/политики, сделанных Линусом Торвальдсом, чтобы ничего не делать в git, что благоприятствует пользователям Windows. Джоэл обратился к этому в презентации на FogBugz и Kiln в 2011 году. Вы можете прослушать это замечание в минуту 40:40 в следующем видео.

Joel Spolsky on Mercurial Choice

Назад в 2011 году можно было бы согласились с Mercurial решением, принятым Fog Creek, но вещи, которые явно продвинулись в мире мерзавца и принятия мерзавца достаточно очевидно, тяжело убедить Fog Creek создать печных Harmony который позволяет использовать hg или git.

Kiln Harmony