कई वेबसाइटों के साथ गिट में संरचना

Question

मेरे पास एक वेबसाइट है जो मैं गिट में रखती हूं। यह एक एएसपीनेट वेबफॉर्म वेबसाइट है (लेकिन यह शायद इस प्रश्न के लिए महत्वहीन है)।

वेबसाइट का उपयोग हमारे ग्राहक द्वारा 2 (भविष्य में 4) वेबसाइटों के लिए किया जाता है। अधिकांश कार्यक्षमता साझा की जाती है। लेकिन web.config जैसी कुछ चीजें और प्रत्येक वेबसाइट के लिए सीएसएस वाला फ़ोल्डर अद्वितीय है।

यहाँ कोड

 
|--BackOffice 
| \--UI 
|--BackOffice.UI 
| \--WebControls 
|--BackOfficeTests 
|--Deployment 
| \--db 
|--BusinessLogicLayer 
| |--bin 
| |--obj 
| \--Properties 
|--scripts 
|--Website 
| |--admin 
| |--App_Browsers 
| |--App_Code 
| |--App_Data 
| |--Styles 
| |--web.config 

क्या इस के लिए एक अच्छा संरचना Git में होगा की एक सरलीकृत संस्करण है?

उदाहरण के लिए बैकऑफिस कोड पूरी तरह से साझा किया जाएगा। वेबसाइट स्टाइल फ़ोल्डर और web.config फ़ाइल को छोड़कर साझा की जाएगी।

क्या आपके पास ऐसी संरचना के लिए एक अच्छा सुझाव है जो विलय और शाखाओं को लंबे समय तक बाधित नहीं करता है?

मैं बहुत की तरह एक संरचना बनाने के लिए प्रयास किया है:

 
Master 
|--Site1 
|--Site2 

लेकिन मैं बहुत ज्यादा cherrypicking पूर्वानुमान जब एक और को एक शाखा से कोड का स्थान बदलना एक submodule ठीक होगा या यह चीजों को मुश्किल होगा?

संपादित करें: मेरी वास्तव में बड़ी समस्या यह है कि मैं सीधे अपने गिट रेपो से तैनात करना चाहता हूं। और यदि मैं इन निर्देशिकाओं/फ़ाइलों में छोड़ देता हूं तो उन्हें विलय के दौरान विलय कर दिया जाएगा, जब तक कि मैं कुछ जटिल चीजें नहीं करता (तब मैं टीम को हर किसी को ऐसा करने नहीं देता)। या मुझे इन फ़ाइलों को अनदेखा करना होगा और उन्हें कहीं और से प्राप्त करना होगा ...

Answer 1

यह मानते हुए कि अपने गुरु शाखा अपने पूरे परियोजना में शामिल हैं:

|--BackOffice 
| \--UI 
|--BackOffice.UI 
| \--WebControls 
|--BackOfficeTests 
|--Deployment 
| \--db 
|--BusinessLogicLayer 
| |--bin 
| |--obj 
| \--Properties 
|--scripts 
|--Website 
| |--admin 
| |--App_Browsers 
| |--App_Code 
| |--App_Data 
| |--Styles 
| |--web.config 

अब, किसी भी बदलाव के जो सभी वेबसाइटों के लिए आम है, इस शाखा करने के लिए प्रतिबद्ध हो जाता है।

विभिन्न साइटों के लिए अलग शाखाएं बनाएं। उदाहरण:

मास्टर शाखा से

,

git checkout -b site1 
git checkout -b site2 
git checkout -b site3 
git checkout -b site4 

अब जब भी आप किसी भी साइट विशिष्ट फ़ाइलों को बदलना चाहते हैं, अर्थात शैलियाँ फ़ोल्डर या web.config, इन शाखाओं में करते हैं।

अब तैनाती का हिस्सा आता है। मान लीजिए कि आप साइट 1 को तैनात करना चाहते हैं, स्थानीय सिस्टम पर मास्टर के आधार पर एक अस्थायी शाखा बनाएं, इसमें साइट 1 शाखा को मर्ज करें और इसे तैनात करें। अंत में अस्थायी शाखा हटा दें।

git checkout -b temp 
git merge site1 

अपने कोड को टैर या ज़िप करें और इसे तैनात करें। उसके बाद,

git checkout master 
git branch -D temp 

तुम भी है कि है कि यदि आप जिस तरह से तैनाती का पर्दाफाश नहीं करना चाहते किया जाता है करता है एक छोटा सा खोल स्क्रिप्ट बना सकते हैं। इस स्क्रिप्ट deploy.sh उदाहरण के लिए फोन की सुविधा देता है: अब

#!/bin/bash 

if [ ! $1 ]; then 
     echo "Please pass in the name of the site you want to deploy." 
     exit 1 
fi 

#Check if we are on master branch 
git status | grep "On branch master" 
if [ $? -ne 0 ]; then 
     echo "You are not on master. Please execute 'git checkout master'" 
     exit 1 
fi 

#Check if the entered site for deployment actually exists 
git branch | grep $1 || { echo "No branch $1 exists for deployment."; exit 1; } 

#Update from remote 
git checkout -b temp 
git merge $1 
tar -cvf deploy-$1.tar ./deploy.sh * 
[ $? -ne 0 ] && echo "Some problem archiving the files..." && exit 1 
git checkout master 
git branch -D temp 

echo "Please use deploy-$1.tar file to deploy the site. Thanks." 

exit 0 

जब आप कहते हैं ./deploy.sh site2, इस स्क्रिप्ट पर्दे के पीछे सब गंदे काम करते हैं और आप एक टार फ़ाइल जो आप कर सकते हैं दे देंगे उत्पादन सर्वर पर तैनाती।

मुझे उम्मीद है कि यह सहायक है ...

Answer 2

ए submodule साझा बैकऑफिस कोड के लिए एक अच्छा समाधान है, प्रत्येक साइट पेरेंट रेपो के रूप में कार्य करती है।

लेकिन यह कॉन्फ़िगरेशन फ़ाइलों को संबोधित नहीं करता है।

उन लोगों के लिए, एक संभावना content filter है, लेकिन इसमें विभिन्न ग्राहकों के लिए चर के मानों को संग्रहित और धक्का देना शामिल होगा।

क्लाइंट-विशिष्ट शाखाओं में उन कॉन्फ़िगरेशन फ़ाइलों को पैरेंट रेपो में रखना सर्वोत्तम होता है।

Answer 3

मैं अलग "साइट" और "आम" निर्देशिका, रणनीतिक बिंदुओं पर "आम" युक्त सिमलिंक और एक या दोनों एक submodule, इसलिए तरह से कर सकता है:

Project 
|==.git 
|--Site 
| |--.git 
| \--Website 
|  |--Styles 
|  \--web.config 
\--Common 
    |--.git 
    |--BackOffice 
    | \--UI 
    |--BackOffice.UI 
    | \--WebControls 
    |--BackOfficeTests 
    |--Deployment 
    | \--db 
    |--BusinessLogicLayer 
    | |--bin 
    | |--obj 
    | \--Properties 
    |--scripts 
    \--Website 
     |--admin 
     |--App_Browsers 
     |--App_Code 
     |--App_Data 
     |--Styles -> ../../Site/Website/Styles 
     \--web.config -> ../../Site/Website/web.config 

केवल लेआउट कि होता नहीं है यही कारण है कि सेवा - उदाहरण के लिए, यदि अलग-अलग साइटों को चुनना आसान हो और चुनना आसान हो, तो आप अपने वर्तमान लेआउट को संरक्षित कर सकते हैं, "सामान्य" सबप्रोजेक्ट और सिम्लिंकिंग जो आप इसका उपयोग अपरिवर्तित करते हैं, को जोड़कर,

जितना अधिक मैं इसे और अधिक देखता हूं I आखिरी एक बेहतर की तरह।