Git соглашение, чтобы указать выбрасывать ветви - PullRequest
5 голосов
/ 05 марта 2010

Сценарий:

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

A и B взламывают, человек C видитактивность на github и клонах, желающих узнать, что происходит.Тем временем А и В заключают свое ужасное решение, и удаляет ветку .Но человеку С удается превратить идею в нечто великое и он хочет поделиться.Ад слияния начинается, когда у ветви Си больше нет общего предка с целью слияния.


Мне интересно посмотреть, как этот сценарий должен был быть обработан.

  • Есть липринятое соглашение об именах для ветвей, чтобы указать, что - даже если нажата - эта ветка вполне может быть полностью стерта.Способ для человека А указать, что «если вы откажетесь от этого, я не могу гарантировать продолжение счастья» .
  • Или есть даже способ (команда) в git, который позволяет мне тег разветвляется как выбрасывание?
  • Просто никогда, независимо от обстоятельств, не принято изменять историю мерзавцев, если кто-то мог извлечь из нее?
  • Должен ли человек А потратить время на то, чтобы правильно настроить свою рабочую станцию, чтобы позволить человеку Б оторваться от него?Таким образом, уходя в темноту, не давая кому-либо еще знать, над чем он работает.
  • Возможно, единственное жизнеспособное решение - это доброе старомодное общение;просто поговорите с вами, сверстники.

И если ничего не помогает, какова правильная стратегия для человека С в этом случае?Как правильно применить изменения, когда ваша работа выполняется в отключенном графе?

Ответы [ 3 ]

4 голосов
/ 05 марта 2010

Официального соглашения пока нет.

Один хороший пример одноразовой ветки (упомянутой в этой статье на Git rebase с марта 2010 года) - это branch pu of git.git .

Подробная информация о Git :

Ветвь "pu" часто не ускоряется, поскольку некоторые коммиты в ней были полностью удалены с момента последнего извлечения.

Если вы хотите отследить его, добавьте знак плюс (+) к соответствующей строке в файле .git/config, например:

[remote "origin"]
        fetch = +refs/heads/pu:refs/remotes/origin/pu

Что говорит git, что нужно решить эту проблему, просто пропустив проверку ускоренной перемотки вперед ( перезаписывая ваш старый реф с новым ).
Или вы можете просто полностью удалить эту строку, если вообще не хотите отслеживать ветку pu.

Вполне возможно, что в будущих версиях git мы могли бы захотеть пометить некоторые ветви "это, как ожидается, будет перемотано" явно и сделать операцию клона, чтобы заметить, чтобы дать вам знак плюс автоматически.

Таким образом, одна идея состоит в том, чтобы активно предотвращать (с помощью хуков) любой толчок к тем ветвям, которые их выбрасывают:

  • только для чтения
  • обновляется только одним администратором.
2 голосов
/ 05 марта 2010

Ад слияния начинается, когда у ветви С больше нет общего предка с целью слияния.

Конечно, главная ветвь А имеет предка (в своей истории) для удаленной ветки.

C может подтолкнуть ветвь к github, где A сможет снова ее вытянуть. Что в этом плохого? или C может выполнить слияние / перебазирование в новой ветви (поверх мастера A) и, опять же, позволить A вытащить его.

обновление (ответ на комментарии).

Удаление ветки на самом деле не переписывает историю, по крайней мере не таким плохим способом, который предотвращает слияние.

Я предполагаю, что у человека А была такая история:

a--b--c--d--e--f--g    master
      |
      x--y--z   experiment

Так что после удаления ветки у него все еще есть коммиты от a до c, вероятно, это выглядит как:

a--b--c--d--e--f--g--h--i--j--k    master

Человек С предположительно имеет:

a--b--c--d--e--f--g    master
      |
      x--y--z--w--v--q   experiment

Это вполне разумный сценарий, когда объединение не должно быть таким уж плохим.

Например, человек С может вытащить из мастера А и объединить в нем эксперимент.

0 голосов
/ 05 марта 2010

Каждый сопровождающий несет ответственность за свой форк.Вы не можете предполагать, что другой коммиттер имеет коммит или нет что-то великое.

Вы можете увидеть информацию, если коммиттер и Автор не одно и то же лицо.

Если вы не хотите какой-то патчвы можете вернуть его в свой собственный форк.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...