A Git és a GitHub alapjai a Microsoft Learn dokumentációjához

  • Cikk

Áttekintés

A Microsoft Learn dokumentációjának közreműködőjeként több eszközzel és folyamattal is együttműködhet. Más közreműködőkkel párhozamosan dolgozhat ugyanazon a projekten, olykor ugyanazon a tartalmon, akár egyidejűleg. Mindezt a Git és a GitHub szoftver teszi lehetővé.

A Git egy nyílt forráskódú verziókövető rendszer. Az ilyen jellegű projektekben való együttműködést a tárházakban lévő fájlok elosztott verziókövetésével valósítja meg. A Git lényegében lehetővé teszi több közreműködő egy adott időszakban egy adott tárházban elvégzett munkafolyamatainak integrálását.

A GitHub egy webalapú üzemeltetési szolgáltatás a Git-adattárakhoz, például a Microsoft Learn-tartalmak tárolásához. Minden projekt fő tárházát a GitHub üzemelteti, a közreműködők pedig másolatokat készíthetnek erről a saját munkájukhoz.

Ez a cikk a Microsoft Learn-munkafolyamat részét képező kulcskifejezéseket határozza meg. Emellett áttekintést nyújt a Git- és a GitHub-adattárakról, valamint ismerteti a Microsoft műszaki dokumentációjának tartalmainak rendszerezését.

Ág

Az ágak a munkafolyamatok (általános elnevezéssel verziók) elkülönítésére szolgálnak. A közreműködők hatásköre pedig mindig egy adott ágra terjed ki.

Az adott ághoz kapcsolódó módosítások elkülönítése lehetővé teszi, hogy egymástól függetlenül vezérelje és vezesse be ezeket a módosításokat. A valóságban a végzett munka típusától függően könnyen megtörténhet, hogy több munkaág is lesz a tárházában. Nem ritka, hogy egyszerre több munkaágon folyik munkavégzés úgy, hogy mindegyik más projekthez tartozik.

Minden adattár tartalmaz egy alapértelmezett ágat (általában "main" néven) és egy vagy több folyamatban lévő ágat (amelyeket munkaágaknak hívunk), amelyek még nem integrálva lettek az alapértelmezett ágba. Az alapértelmezett ág a projekt aktuális verziójaként és "egyetlen igazságforrásként" szolgál. Ez a tárházban létrehozott összes további ág szülője.

Minden alkalommal, amikor új, logikailag kapcsolódó módosításokat vezet be, ajánlott munkaágat létrehozni a módosítások kezeléséhez. Nem javasoljuk, hogy közvetlenül módosítsa az alapértelmezett ágat.

Elágazás

Ezt a kifejezést általában főnévként használják, amikor egy fő GitHub-adattár másolatára hivatkozik. Egy elágazás a gyakorlatban nem más, mint egy újabb tárház. Mégis különleges abban az értelemben, hogy a GitHub fenntartja annak kapcsolatát a fő/szülőtárházzal. Ezt a kifejezést néha igeként is használják, ahogy a "Először el kell forditania az adattárat".

Git

Ha ismeri a központi verziókövetési rendszereket (például a Team Foundation Servert, a SharePointot vagy a Visual Source Széf), láthatja, hogy a Git egyedi közreműködői munkafolyamattal és terminológiával rendelkezik az elosztott modell támogatásához. Például nincs olyan fájlzárolás, amely általában a kivételi/bejelentkezési műveletekhez van társítva. Ehelyett a Git még finomabb szinten aggódik a változások miatt, összehasonlítva a fájlok bájt bájtjait.

A Git többszintű struktúrában tárolja és kezeli az adott projekthez tartozó tartalmat:

  • Tárház – ez a legnagyobb tárolási egység, rövid angol neve repo. Egy tárház egy vagy több ágat tartalmaz.
  • Ág – a projekt tartalomkészletét alkotó fájlokat és mappákat tartalmazó tárolási egység. Az ágakról a cikk Ág szakaszában olvashat bővebben.

A közreműködők helyi szinten és a GitHub szintjén egyaránt a Git használatával frissítik és kezelik a tárházakat:

  • Helyben olyan eszközökkel, mint például a helyi tárházakat kezelő és GitHub-tárházakkal kommunikáló Git-parancsokat támogató Git Bash konzol.
  • A www.github.com webhelyen keresztül, amely a Gitet integrálva kezeli a fő tárházba visszaérkező közreműködések egyeztetését.

GitHub

Feljegyzés

Bár a dokumentációs útmutató a GitHubon alapul, egyes csapatok a Visual Studio Team Services használatával üzemeltetik a Git-adattárakat. A Visual Studio Team Explorer ügyfél grafikus felhasználói felület kínál a Team Services-tárházakkal végzett munkához a Git-parancsok parancssori használatának kiváltására.
Emellett az alábbi irányelvek közül sok az Azure-szolgáltatástartalom GitHubon való üzemeltetésében szerzett több éves tapasztalatból származó ajánlott eljárásként lett kifejlesztve. Előfordulhat, hogy néhány Microsoft Learn-adattárban szükség van rájuk.

Minden munkafolyamat a GitHub szintjén kezdődik és fejeződik be, ahol minden dokumentációs projekt fő adattára tárolódik. A közreműködők által saját használatra készített másolatok több számítógépen lesznek elosztva. Ezek a másolatok végül ismét össze lesznek hangolva a projekt fő GitHub-tárházával.

Könyvtárszerkezet

A projekt alapértelmezett ága a projekt tartalmának aktuális verziója. Az alapértelmezett ág és az abból létrehozott ágak tartalma lazán igazodik a megfelelő Microsoft Learn-oldalakon található cikkek szervezetéhez. Az alkönyvtárak a cikkek (például szolgáltatások), a médiatartalmak (például képfájlok) és a "belefoglalás" fájlok elkülönítésére szolgálnak (amelyek lehetővé teszik a tartalom újrafelhasználását).

Cikkek alkönyvtára

A tárház gyökérkönyvtárában általában megtalálható egy fő articles könyvtár. A articles könyvtár alkönyvtárakat tartalmaz, az alkönyvtárakban lévő cikkek Markdown-fájlokként vannak formázva, amelyek .md kiterjesztést használnak. Egyes, több szolgáltatást támogató tárházak egy általános /articles alkönyvtárat használnak. Ilyen például a Azure-Docs tárház. Mások a szolgáltatásra utaló nevet használnak, mint például az IntuneDocs tárház, amely az /IntuneDocs nevet használja.

Ennek a könyvtárnak a gyökerében találhatók a szolgáltatás vagy termék egészére vonatkozó, általános tartalmú cikkek. Ezt többnyire más, a funkciókhoz, szolgáltatásokhoz vagy gyakori forgatókönyvekhez tartozó alkönyvtárak egészítik ki. Az Azure „Virtual Machine” (virtuális gép) témájú cikkei például a /virtual-machines alkönyvtárban, az Intune „Understand & Explore” (Az Intune bemutatása) témájú cikkei pedig az /understand-explore alkönyvtárban helyezkednek el, stb.

Médiafájlok alkönyvtára

Minden cikk-könyvtár tartalmaz egy /media alkönyvtárat a kapcsolódó médiafájlok számára. A médiafájlok a képhivatkozásokkal rendelkező cikkekben használt képeket tartalmazzák.

Beágyazott fájlok alkönyvtára

Ha újrafelhasználható tartalmat használ két vagy több cikkben, akkor azt a fő articles könyvtár /includes alkönyvtára tartalmazza. Egy Markdown-fájlban, amely felhasználja a beágyazott fájlt, a beágyazott fájlra való hivatkozás helyén egy megfelelő "include" Markdown-bővítményt kell elhelyezni.

Lásd: Markdown-referencia: További útmutatást ad .

Markdown-fájlsablon

Segítségképpen általában minden tárház gyökérkönyvtárában található egy template.md nevű Markdown-fájlsablon. Ez kiindulásként használható, ha új cikket szeretne létrehozni és feltölteni a tárházba. A fájl tartalma:

  • Egy metaadat-fejléc a fájl elején – ez egy kétsoros, három kötőjellel megjelölt rész. Ez a cikkel kapcsolatos nyomkövetési információkhoz tartalmaz különféle címkéket. A cikkek metaadatai bizonyos funkciókat tesznek elérhetővé; ilyenek például a szerzők és a közreműködők megnevezése, az útkövetés, és a cikkleírások. Ide tartozik még a keresőmotor-optimalizálás és olyan jelentési folyamatok, amelyeket a Microsoft használ a tartalom teljesítményének értékeléséhez. A metaadatok tehát fontos szerepet játszanak.
  • Egy metaadatok szakasz, amely ismerteti a különféle metaadat-címkéket és azok értékeit. Ha nem tudja biztosan, milyen értékeket kell használnia az egyes metaadatoknál, üresen is hagyhatja őket, vagy egy sor eleji hashtaggel (#) megjegyzéssé alakíthatja, majd a tárház pull-kérelmének felülvizsgálója ellenőrzi vagy kiegészíti azokat.
  • Markdown-használati példák, amelyek a cikk különféle részeinek formázását mutatják be.
  • Markdown-bővítményekre vonatkozó általános használati útmutatók, amelyek különféle típusú riasztásokhoz használhatók.
  • Példák videó beágyazására Iframe használatával.
  • A Microsoft műszaki dokumentációs bővítményeinek használatára vonatkozó általános utasítások, amelyeket speciális vezérlőkhöz, például gombokhoz és választókhoz használhat.

Eredet

Ez a kifejezés a helyi adattár és a klónozott adattár közötti kapcsolathoz rendelt név. A Microsoft Learn munkafolyamatban a forrás jelöli az elágazáshoz való kapcsolatot. Ezt a kifejezést néha maga a forrástárház monikerjeként használják, ahogyan a "Ne felejtse el leküldni a módosításokat a forrásba".

Lekéréses kérelmek

A lekéréses kérelem (PR) egy tartalomtulajdonos kérése, amely lekéri a módosításokat a hivatalos forrásba. A lekéréses kérelem lehetővé teszi a GitHub együttműködési modelljét úgy, hogy a munkaág módosításait (más néven véglegesítéseket) kéri le és egyesíti egy másik ágba. A legtöbb esetben ez a másik ág az alapértelmezett ág a fő adattárban.

A lekéréses kérelem is mechanizmusként szolgál, amely a Microsoft Learn érvényesítési folyamataiból és a lekéréses kérelem felülvizsgálójától kapott visszajelzéseket nyújtja a problémák vagy kérdések megoldásához, mielőtt a módosításokat az alapértelmezett ágba egyesítené.

Távoli

A távoli egy távoli adattár nevesített kapcsolata, például a "forrás" vagy a "felsőbb réteg" távoli. A Git azért hivatkozik erre távoliként, mert egy másik számítógépen üzemeltetett adattárra hivatkozik. A Microsoft Learn munkafolyamatban a távoli mindig Egy GitHub-adattár.

Upstream

A távoli forráshoz hasonlóan a felsőbb réteg is egy elnevezett kapcsolat egy másik adattárhoz. A Microsoft Learn munkafolyamatban a felső réteg a helyi adattár és a fő adattár közötti kapcsolatot jelöli, amelyből az elágazás létre lett hozva. Ezt a kifejezést gyakran használják a felsőbb rétegbeli adattár bevételezőjeként, ahogyan a "Ne felejtse el lekérni a legújabb módosításokat a felsőbb rétegből".

További információ

Ha nem ismeri a Gitet vagy a GitHubot, ezek az erőforrások segíthetnek a tanulásban, a hatékony munkában vagy a kérdések megválaszolásában.

Git-forrásvezérlési erőforrások

GitHub-források

GYIK

Mi az a Git?

A Git segít nyomon követni a változásokat, ha sokan együtt dolgoznak a számítógépes kódon. Ez olyan, mint egy időgép a kódhoz, így láthatja, mi változott, és szükség esetén visszatérhet.

Miért érdemes a Gitet használni?

Nagyszerű csapatmunkához. A Git megkönnyíti, hogy sok ember dolgozik ugyanazon a projekten anélkül, hogy elrontja egymás munkáját. Segít a hibák egyszerű kijavításában is.

Hogyan működik a Git?

A Git egy projekt kódjának összes verzióját tárolja. Ha módosításokat hajt végre, a Git képet készít (például pillanatképet) a különbözőségről. Egyszerre több verziót is készíthet probléma nélkül.

Mik azok az ágak a Gitben?

Az ágak olyanok, mint a projekt különböző elérési útjai. Lehetővé teszik, hogy az emberek a fő projekt módosítása nélkül dolgozzanak az új dolgokon. Később visszahozhatják ezeket a módosításokat a fő projektbe.

Mi a véglegesítés a Gitben?

A véglegesítés olyan, mint egy mentési pont. Így rögzítheti a végrehajtott módosításokat. Minden véglegesítés egyedi azonosítóval és megjegyzéssel rendelkezik arról, hogy mi változott.

Mi az a GitHub?

A GitHub egy webhely, ahol a Git-projekteket tárolhatja. Ez olyan, mint egy nagy központ a kód megosztásához és másokkal való közös munkához. Emellett segít nyomon követni, hogy ki mit változtatott meg.

Miben különbözik a GitHub a Gittől?

A Git a változások nyomon követésének eszköze, míg a GitHub a projektek tárolásának és együttműködésének a helye. A GitHub a Git segítségével hajtja végre a varázslatát.

Ingyenes a GitHub?

Igen, a projektek esetében mindenki láthatja. Magánprojektek esetén (csak Ön és a csapata) lehet, hogy fizetnie kell. Különböző csomagokat kínálnak extra funkciókkal.

Mik azok a lekéréses kérelmek a GitHubon?

A lekéréses kérelmek olyanok, mintha a módosításokat a fő projektbe helyeznék. Kapcsolatok még a hozzáadásuk előtt áttekintheti és megvitathatja a módosításokat.

Mennyire biztonságos a GitHub?

A GitHub gondoskodik a biztonságról. Speciális kódokat és szabályokat használnak annak biztosításához, hogy csak a megfelelő személyek férhessenek hozzá a kódhoz, és módosíthassanak. További biztonsági rétegeket is hozzáadhat, például kéttényezős hitelesítést a nagyobb biztonság érdekében.