Конвенция мерзавца указать выбрасывает ответвления

Сценарий:

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

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


Я - сувениры, чтобы видеть, как этот сценарий должен был быть обработан.

  • Есть ли принятое соглашение о присвоении имен для ответвлений, чтобы указать, что - даже при том, что продвинутый - это ответвление может быть полностью oblitered. Путь к человеку, чтобы указать, что, "если Вы вытягиваете от этого, я не могу гарантировать продолженное счастье".
  • Или есть ли даже путь (команда) в мерзавце, который позволяет мне вид ответвлений тега, как выбрасывают?
  • Это просто никогда, независимо от обстоятельств, которые, как принимают, изменили историю мерзавца, если кто-то, возможно, вытянул от него?
  • Человек A должен был не торопиться для надлежащего конфигурирования его рабочей станции, чтобы позволить человеку B вытянуть непосредственно от него? Таким образом идя в темноте, не сообщая никому больше, что они продолжают работать.
  • Возможно, единственным эффективным решением является старая добрая сформированная коммуникация; просто говорите, Вы взаимодействуете.

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

5
задан Mizipzor 5 March 2010 в 10:23
поделиться

3 ответа

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

Наверняка у мастер-ветви A есть предок (в истории) удаленной ветви.

C может выложить ветку на github, откуда A может ее снова взять. Что в этом плохого? Или, C может сделать слияние/ребазирование в новой ветке (поверх основной ветки A) и, опять же, позволить 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

У человека C предположительно есть:

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

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

Например, человек C может взять из мастера A и слить в него эксперимент.

2
ответ дан 14 December 2019 в 13:33
поделиться

Формальной конвенции пока не существует.

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

В Git FAQ подробно описано:

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

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

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

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

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

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

  • только для чтения
  • обновляемыми только одним администратором.
4
ответ дан 14 December 2019 в 13:33
поделиться

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

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

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

0
ответ дан 14 December 2019 в 13:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: