Стандарт рабочих процессов Git для работы с несколькими проектами в ветке разработки
Я провел около двадцати минут или около того, поэтому я подумал, что это стоит того, чтобы поместить это здесь. Тем не менее, это напрямую связано с ответом пользователя137673. Мне было очень полезно сделать что-то вроде этого:
#! /usr/bin/env python
import signal
timeout = None
def main():
inp = stdinWait("You have 5 seconds to type text and press <Enter>... ", "[no text]", 5, "Aw man! You ran out of time!!")
if not timeout:
print "You entered", inp
else:
print "You didn't enter anything because I'm on a tight schedule!"
def stdinWait(text, default, time, timeoutDisplay = None, **kwargs):
signal.signal(signal.SIGALRM, interrupt)
signal.alarm(time) # sets timeout
global timeout
try:
inp = raw_input(text)
signal.alarm(0)
timeout = False
except (KeyboardInterrupt):
printInterrupt = kwargs.get("printInterrupt", True)
if printInterrupt:
print "Keyboard interrupt"
timeout = True # Do this so you don't mistakenly get input when there is none
inp = default
except:
timeout = True
if not timeoutDisplay is None:
print timeoutDisplay
signal.alarm(0)
inp = default
return inp
def interrupt(signum, frame):
raise Exception("")
if __name__ == "__main__":
main()
1 ответ
ОБНОВЛЕНО - вопрос был изменен, чтобы указать, что проблема связана с состоянием нескольких функций, а не нескольких проектов, как было первоначально заявлено. Оригинальный ответ сохраняется ниже.
Есть много конкурирующих рабочих процессов, которые работают для разных команд / проектов. Один довольно популярный рабочий процесс - это gitflow; вероятно, он лучше подходит для более крупных проектов, так как может показаться излишним для небольших / простых проектов, но, опять же, для него есть достойная инструментальная поддержка.
В gitflow master - это «то, что было выпущено», а develop - «то, что потенциально может быть выпущено прямо сейчас, если бы мы сделали релиз прямо сейчас» - так что вы не объединяете функцию с [ 112], пока он не прошел тестирование качества.
Это поднимает вопросы о том, как выполнить наилучшее тестирование. Очевидно, вам нужно будет протестировать версию develop после объединения функций в / перед выпуском, и возможно, что эти тесты не пройдут, и вам придется либо удержать релиз для исправления, либо откатить одну или несколько функций назад. Целью было бы свести к минимуму, как часто это происходит.
С хорошей инфраструктурой вы могли бы потенциально развернуть данную ветвь функции в среде QA, когда будете готовы протестировать эту функцию. Чтобы получить наилучший возможный тест, вы можете либо объединить разработку в функцию до теста (возможно, затем отменить объединение позже), либо переместить функцию в develop перед тестом (если вы не возражаете против регулярного переписывания ветвей функций) , Итак, если «все высвобождаемое плюс эта одна дополнительная функция» проходит тестирование, одна дополнительная функция становится «чем-то высвобождаемой», и вы можете объединить ее с develop.
На практике в большинстве проектов, которые я видел, компромисс в некотором смысле, полагаясь на предположение, что функции не будут мешать друг другу (что, конечно, чрезмерно оптимистично, но все же может работать в большинстве случаев).
Стандарт в Git должен поместить каждый проект в свой собственный репозиторий (несмотря на недавнюю и, тем не менее, ошибочную) тенденцию «monorepos». Ситуация, которую вы описываете, является отличным примером того, почему.
Это не значит, что Вы не могли разработать какую-либо стратегию ветвления, которая дает тот же эффект от одного репо - но то, что вы, вероятно, получите, если сделаете это, - это отдельные «логические репо», каждый из которых содержит свой собственный отдельный набор ветвей в пределах «одного репо».