Наскоро преминахме от CVS на Git и използваме Vincent Driessen's успешен модел на разклоняване на Git с master клон и а develop клон, който се обединява отново master, Започнахме с един проект в Git и сега имаме два отделни проекта, използващи общ код в подмодула (common). Наскоро другият проект се е променил develop че не сме подготвени и докато не актуализираме нашия собствен код, не можем да върнем никакви промени develop защото не искаме другите промени.
Мислех за разклоняване develop в специфични за проекта клонове, които се обединяват отново develop, но собственикът на common не искат специфични за проекта клонове, защото:
ние ще трябва да вземем череши ангажименти от главния
developклон в за да получите корекции или характеристики, които се отнасят и за двете.
Би било по-добре да се елиминира develop клон изцяло и просто се сливат директно от специфични за проекта клонове обратно към master, или правим ли всичко това погрешно?
Отговори:
1 за отговор № 1Наскоро другият проект се е променилда разработим, че не сме подготвени и докато не сме актуализирали нашия собствен код, не можем да извършим никакви промени, за да се развием, защото не искаме другите промени.
Това означава, че двата проекта имат различни жизнени цикли на развитие и всеки от тях трябва да има свой собствен развиващ се отрасъл.
Но ако common не може лесно да се актуализира и от двата проекта, което означава, че трябва да актуализирате common себе си (в отделен от него проект)
Преди да се слеете develop клон на главното длъжностно лице develop един, ще трябва да се слеете common от главния develop клон към вашата версия на common, разрешаване на всеки конфликт и обединяване common както и.
По този начин common собственикът на проекта няма да трябва да избира или интегрира нищо.