Csapatmunka Github segítségével

Ez a cikk eredetileg +Sayanee Basu (Twitter: @sayanee_) munkája, amit a @nettuts oldalon publikált “Team Collaboration With Github” címen. Mivel úgy gondolom, hogy ez egy nagyon jól összeszedett cikk gyorsan engedélyt is kértem a fordításra Twitteren, melyre gyors válasz érkezett. Így aztán nekiláttam a fordításnak. Mivel a cikk sok olyan szót tartalmaz, amit nem lehet vagy legalábbis nincs értelme lefordítani, így ha valahol olyan hibát találsz, ami ebből fakad, akkor kérlek írd meg, hogy mi az, hol van és hogyan lenne jobb. (természetesen minden más hibára is örülök, ha írsz)

És itt kezdődik a cikk…

A Github lett manapság az Open Source közösségek, alkalmazások központja. A fejlesztők szeretik, itt dolgoznak együtt projektjeiken és jobbnál-jobb dolgokat készítenek közösen. Azon kívül, hogy a kódbázis tárolására ad lehetőséget, a Github az együttműködés terén kimagaslik bármilyen más hasonló szolgáltatás mellett. Ebben a leírásban felfedezzük, hogy miként is lehet csapatban dolgozni a Github-on, hogyan lehet hatékonyan és mindemellett fájdalommentesen használni és javunkra fordítani.

Szoftverfejlesztés közösen a Github-on

Ez a leírás azt veszi alapul, hogy a Git használatának már a tudatában vagy. A Git egy teljesen nyílt forráskódú verziókövető rendszer, amit Linus Torvalds csinált 2005-ben. Ha úgy érzed, hogy utána kellene nézned, hogy mi is ez és hogyan működik, akkor nézd meg ezt a videóanyagot vagy nézz szét a nettuts oldalon további cikkekért. Ezen kívül azt is feltételezi a cikk, hogy már van Github felhasználód és ismered az alapokat, mint például a repo készítés és a változások követését is ismered a Github-on. Ha mégsem, akkor ajánlott szétnézni további hasznos cikkekért az intereten.

Ha fejlesztőként dolgozol, akkor elkerülhetetlen, hogy találkozz olyan esettel, amikor csapatban kell dolgoznod. Ebben a leírásban az kerül előtérbe, hogy miként lehet megoldani a Github segítségével ezt, milyen eszközöket lehet hozzá használni, hogy még könnyebb és hatékonyabb tudjon lenni a csapatban való fejlesztés. Amik érintve lesznek:

  1. Csapattag hozzáadása – Szervezet és Együttműködők
  2. Pull Requests – Beküldés és Beolvasztás
  3. Bug Tracking – Github Issues (Github hibakövető)
  4. Analitika – Grafikonok és Hálózatok
  5. Project ManagementTrello és Pivotal Tracker
  6. Continuous IntegrationTravis CI
  7. Code Review – Megjegyzések adott sorokhoz és URL képzés
  8. Dokumentáció – Wiki és Hubot

Jobban szereted Screencast-okat?

Ha jobban szereted videó formájában nézni a dolgokat és úgy látni működés közben, akkor nézd meg nézd meg ezt: (angol nyelvű)

Csapattag hozzáadása

Alapértelmezetten két lehetőség van csapatban dolgozni Github-on:

  1. Szervezet – Egy Szervezet tulajdonosa létrehozhat csapatokat különböző jogokkal és repókkal.
  2. Együttműködés – A repó tulajdonosa hozzáadhat bárkit írási és olvasási joggal a saját repójához

Szervezet

Ha több csapatod van, és szeretnél minden csapatnak illetve a csapat tagjainak is külön állítani hozzáférési szinteket, akkor a legjobb választás, ha csinálsz egy Szervezetet (Organization). Minden Github felhasználó ingyenesen létrehozhat szervezetet Open Source projekteknek. Ha létre szeretnél hozni egyet, akkor csak menj a saját szervezetek beállításaihoz.

Github szervezet

A csapatok oldalát egyszerűen el lehet érni a http://github.com/organizations/[organization-name]/teams címen, ha pedig újat szeretnél létrehozni, akkor azt megteheted a https://github.com/organizations/[organization-name]/teams/new oldalon. Minden tagnak három lehetséges jogot lehet beállítani:

  1. Pull Only: Leszedheti a forrást és beolvaszthatja egy másik repóba vagy készíthet belőle lokális másolatot. Ez tulajdonképpen a Csak olvasható mód.
  2. Push and Pull: (1) + Frissítheti a szerveren lévő repót. Írási/Olvasási jog.
  3. Push, Pull & Administrative: (1) és (2) + hozzáfér a számlázási adatokhoz, létrehozhat új csapatokat, de akár törölheti is a szervezetet. Olvasás + Írás + Adminisztrációs jogok.

Három jogosultsági szint

Együttműködő (partner)

Ha van egy személyes repód, akkor bárkinek adhatsz írási és olvasási jogokat a te saját felhasználóddal. Ha szeretnél hozzáadni valakit egy projektedhez, akkor látogass el a https://github.com/[username]/[repo-name]/settings/collaboration oldalra:

Csapattársak

Ha hozzáadtunk valakit, akkor láthatja az írható hozzáférési címet is a repóhoz. Ha valakinek van írási joga, akkor tud git clone parancs kiadása után dolgozni a projekten és a módosításait egyszerűen git push-al felküldeni a Github-ra.

Github jogosultságok

Pull Requests

A Pull Request egy nagyon jó lehetőség arra, hogy saját ágat létrehozva (fork) függetlenül módosíts a kódon. A nap végén, ha akarod, akkor fel tudod küldeni a módosításokat a saját repódba és küldhetsz egy Pull Request-et a projekt eredeti tulajdonosának a módosításaidról. A módosítási listáról ezután elindulhat egy beszélgetés, hogy kell-e, milyen a minősége és bekerülhet-e az eredeti kódbázisba.

Nézzük hogyan is működik a Pull Request.

Pull Request kezdeményezése

Két típusa van a Pull Requesteknek
Github-on:

  1. Fork & Pull Model – Publikus repóknál használatos, ahol nincs írási jogod.
  2. Share Repository Model – Privát repóknál használatod, ahol van írási jogod. Ilyen esetben nem szükséges Fork-olni.

Most nézzük a folyamatot két résztvevő esetén (repo-owner and forked-repo-owner), hogy lássuk a Fork & Pull Model működését:

  • Keressük meg a Github repót, amin szeretnénk dolgozni. Kattintsunk a “Fork” gombra:

Fork

  • Ez létrehoz egy teljes másolatot a saját felhasználónk alá:

Forkolt

  • Válasszuk ki az SSH URL-t, így az SSH kulcshoz tartozó jelszót fogja kérni (és nem a Github felhasználónevet és
    jelszót)
    minden alkalommal, amikor a git push vagy git pull parancsot adjunk ki. Most leszedhetjük a saját gépünkre a kódot:

    $ git clone [ssh-url] [folder-name]
    $ cd [folder-name]
  • Általánosságban egy új funkció fejlesztéséhez csinálni szoktunk egy új ágat (branch). Ez egy jó gyakorlat, mert megmarad a master águnk és így könnyen tudjuk frissíteni az alapján a fejlesztésünket. Így a pull request-ünket a rendszer automatikusan tudja majd frissíteni. Tehát most csináljunk egy új ágat és módosítsuk a readme.md fájlt:

    $ git checkout -b [new-feature]

  • Miután sikeresen befejeztük a módosításokat simán hozzáadjuk a repóhoz a módosításainkat. Majd visszaállunk a master ágra:

    $ git add .
    $ git commit -m "information added in readme"
    $ git checkout master
  • Ezen a ponton fel tudjuk küldeni a Github-ra a readme águnkat, ami ugyebár most csak lokálisan van meg. Ez a git push [git-remote-alias] [branch-name] parancssal tehetjük meg:
    $ git branch
    • master
      readme
      $ git remote -v
      origin  git@github.com:[forked-repo-owner-username]/[repo-name].git (fetch)
      origin  git@github.com:[forked-repo-owner-username]/[repo-name].git (push)
      $ git push origin readme
  • A saját forkolt repónknál kiválasztjuk a frissen felküldött ágat és megnyomjuk a “Pull Request”
    gombot.

Github Pull Request

  • Miután beküldtük a kérelmünket, megjelenünk az eredeti repó “pull requests” oldalán. Megjelenik mint “pull request” és mint “issue”.

Github Pull Request: 1 commit

  • A változásokkal kapcsolatban történő beszélgetés végén kiderült, hogy bekerül az eredeti repóba mint újdonság vagy nem.

Github Pull Request: 2 commit

Pull Request beolvasztása

Mi van akkor, ha te vagy a repó tulajdonosa?
Két lehetőség van beolvasztani
a beérkező módosításokat:

  • Beolvasztás Github-on: Ha Github-on szeretnénk beolvasztani, akkor előtte meg kell bizonyosodni róla, hogy nincs semmilyen akadály. Tehát nincs conflict és készen áll az egybeolvasztásra. Csak egyszerűen rá kell kattintani a “Merge Pull Request” gombra:

Github Merge

  • Beolvasztás lokális gépen: Amennyiben vannak problémák a beolvasztással, ay “info” gomb megnyomására kiírja a Github, hogy pontosan hogyan lehet megoldani a beolvasztást lokális gépen.

Github Merge Conflict

Különböző modellek vannak az elágazások kezelésére (branching). Két legelterjedtebb a (1) Github folyamat, ami egyszerűen új ágak létrehozásával és Pull kérelmekkel dolgozik és a (2) Gitflow ami sokkal kiterjedtebb metódust használ. Az, hogy melyiket használja egy csapat az elsősorban rajtuk múlik illetve az adott projekten.

Hibakövetés

Github-on a hibakezelés központja az “Issues” fül alatt található. Annak ellenére, hogy a problémák nevet viseli, három különböző típus van:

  • Hibák: Hibák, amiket javítani kell
  • Újdonság: Új ötletek, amiket implementálni kell
  • Feladatlista: Lista azokról, amiket meg kell csinálni

Nézzük meg, hogy mit lehet csinálni velük:

  • Címkézni: Minden bejegyzéshez hozzá lehet társítani egy kategóriát/címkét.
    Mindegyiknek van saját színe. Velük egyszerűen lehet szűrni a listában.
  • Mérföldköveket beütemezni: Ezek olyan kategóriák, amiknek van egy dátuma. Azok a jegyek tartoznak
    egy mérföldkő alá, amik jó lenne, ha készen lenne a következő verzióban (releaseben).
    Mivel a mérföldkövek össze vannak kötve a jegyekkel, automatikusan frissül az állapotjelző,
    ahogyan lezárunk egy jegyet.
  • Keresni: A kereső automatikus kiegészítéssel segít megtalálni a nekünk az éppen keresett
    mérföldkövet vagy jegyet.

Github Issue

  • Hozzá lehet rendelni valakihez: Minden jegy hozzárendelhető egy emberhez, így lehet látni, hogy kinek mit kellene csinálnia, ki foglalkozik az üggyel és kit kell keresni, ha kérdés van vele kapcsolatban.

Uj hiba felvitele

  • Automatikusan lezárhatóak: Ha egy commit tartalmazza a Fixes/Fixed vagy Close/Closes/Closed #[issue-number] formát, akkor az issue-number azonosítójú jegy automatikusan lezárt állapotba kerül.

    $ git add .
    $ git commit -m “corrected url. fixes #2”
    $ git push origin master

Hiba automatikus lezárása

  • Lehet említeni: Bárhol létrehozható olyan megjegyzés, ami az adott jegyre mutat, ha használjuk a #[issue-number] formulát. Az ilyen karakterláncokból linket készít a rendszer, így gyorsan oda lehet jutni hozzájuk.

Hiba megjelölése commit-ban

Analitika

Két eszköz van, amit a rendszer nyújt – Graphs és Network. A Github Graphs egy áttekintést ad az együttműködők munkájáról és a commit-okról. A Github Network pedig vizuálisan jeleníti meg az adott projekt forkjait és a hozzájuk tartozó commit-okat. Ezek nagyon hasznosak, ha át szeretnénk látni, hogy mi hogy áll.

Graphs

A Graphs ezeket mutatja be:

  • Contributors: Kik voltak akik dolgoztak rajta? Mennyi sort adtak hozzá vagy épp töröltek.
  • Commit Activity: Melyik héten voltak commit-ok az elmúlt egy évben?
  • Code Frequency: Hány sor lett commit-olva a projekt élete során?
  • Punchcard: Mely napokon és milyen időszakban milyen aktivitás van?

Github grafikonok

Network

A Github Network is egy nagyon hasznos segítség, mert lehet rajta látni, hogy hol milyen ágak vannak. Ki hol tart, hol lettek összeolvasztva az ágak és ki honnan dolgozik, melyik ágból csinált magnának másolatot és hol szállt be. Minden ág, minden commit-ja látható rajta.

Branch és Fork hálózat

Project Management

Bár a Github Issues segítségével lehet a jegyek és mérföldkövek segítségével vezetni egy projektet, sok csapat más eszközöket használ és preferál erre a célra. Ebben a részben megnézünk két olyan népszerű projektvezetési eszközt, ami teljes mértékben együtt tud dolgozni a Github-bal. Az első a Trello, a második a Pivotal Tracker. A Github hook-oknak köszönhetően automatikusan frissülhetnek a feladatok, és a választott rendszerben látható lesz az aktivitás. Nem pusztán azért jó, mert frissíti a jegyek állapotát, hanem ténylegesen segíteni és gyorsítani tudja a csapat munkáját.

Github és Trello

A Trello egyszerűen vizualizálja a feladatokat. Az agilis szoftverfejlesztés metodikáját követi és kártyákként egy Kanban táblát varázsol elénk. Github összekötéssel például egyszerűen és automatikusan létre tudunk hozatni egy új kártyát, ha Pull Request érkezik. Nézzük hogyan!

  • Csináljunk egy Trello felhasználót, ha még nincs és hozzunk létre egy új táblát.

Github + Trello

  • Menjünk be Github-on a repónkhoz, ott Settings > Service Hooks, és válasszuk ki a Trello-t.
  • TOKEN kérhető az Install Notes alatti linken.
  • Az Install Notes második pontja alatt van egy link, amibe behelyettesítve a frissen szerzett TOKEN-t kapunk egy json formátumú tartalmat. Ez megadja a listaazonosítót minden kártyához. A BOARDID pedig beszerezhető, ha ellátogatunk az oldalra az adott táblához, fent az URL-ből, ami így néz ki: https://trello.com/board/[BOARD-NAME]/[BOARDID].

Trello list_id

  • Vissza a Github hook-okhoz, töltsük ki a list id és a token mezőket. Állítsuk be, hogy az állapota Active legyen, majd nyomjunk egy Test Hook gombot, hogy lássuk működik-e.

Github hook beállítása Trello kapcsolathoz

  • Mostantól automatikusan létrejön egy kártya, ha Pull kérelem jön.

Automatikus frissítés

Github és Pivotal Tracker

A Pivotal Tracker egy másik egyszerű agilis PM eszköz, ami story-based tervezést ad, amivel a csapat gyorsan tud reagálni a változásokra és a projekt állapotára. A csapat állapota alapján mutatja a projektet, készít grafikonokat és elemzi a csapat sebességét, iterációs burn-up, release burn-down és egyéb grafikonokkal segíti a munkát és a tervezést. Ebben a rövid példában beállítjuk, hogy automatikusan deliver státuszt kapjon egy sztori Github commit alapján.

  • Csináljunk egy új projektet a Pivotal Tracker-en egy új Sztorival, amit meg kellene csinálni.

Github + Pivotal Tracker

  • navigáljunk el a Profile > API Token (jobboldalt lent) oldalra. Másoljuk ki a kapott API tokent.

Token

  • Menjünk vissza a Github repóhoz, majd Settings > Service Hooks és keressük ki a Pivotal Tracker-t. Másoljuk be a kapott tokent, állítsuk be, hogy aktív legyen és kattintsunk az Update settings gombra. Mostantól össze van kötve a kettő.

Github hook beállítása Pivotal Tracker-hez

  • Végül csináljunk egy commit-ot úgy, hogy a tracker_id is benne legyen a git commit -m "message [delivers #tracker_id]" formában.

    $ git add .
    $ git commit -m “Github and Pivotal Tracker hooks implemented [delivers #43903595]”
    $ git push

  • Most, ha visszamegyünk a Pivotal Tracker-re, akkor láthatjuk, hogy át lett állítva a
    státusza és bekerült egy link, amit a Github commit-ra visz minket, ahol láthatjuk a
    változásokat is.

Github commit a Pivotal Tracker-ben

Ezekben a példákban a Trello és Pivotal Tracker segítségével látható, hogy nagyon jól összeköthetőek a rendszerek és nagy segítség tud lenni. Sok időt meg tud spórolni már csak ott is, hogy ad egy linket az adott feladathoz tartozó commit-okra. Jó hír az is, hogy sok más eszközhöz van már kapcsolat, mint például Asana vagy Basecamp. Ha ahhoz nincs amit ti használtok, akkor létre tudsz te is hozni egyet.

Continuous Integration

Continuous Integration (CI) egy nagyon fontos része a szoftverfejlesztésnek, de legfőképpen akkor, ha többen dolgoznak egy projekten. CI segít abban, hogy a hibák korábban kiderüljenek. Nem csak automatikusan lefordítja a projektet, de a teszteket is lefuttatja, így ha azokból bármi hibát jelez, akkor a kód hibás és nem szabad beolvasztani, de legfőképpen nem szabad kiélesíteni. Ebben a példában Travis CI-t fogunk használni, hogy látható legyen Github-on, lehet-e beolvasztani avagy sem.

Travis CI beállítása

Egy egyszerű hello-world alkalmazáson nézzük meg a működését, ami node.js-re épül és grunt.js-t használ, amit a tesztek futtatására használunk. Pár fájl tartozik csak a projektünkhoz:

A fő fájl a hello.js és ez a Node.js projektünk. Szándékosan lehagyunk egy pontosvesszőt, hogy elhasaljon:

var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World in Node!n') // without semicolon, this will not pass linting
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

package.json megadja a függőségeket (és egyéb tulajdonságokat):

{
  "name": "hello-team",
  "description": "A demo for github and travis ci for team collaboration",
  "author": "name <email@email.com>",
  "version": "0.0.1",
  "devDependencies": {
    "grunt": "~0.3.17"
  },
  "scripts": {
    "test": "grunt travis --verbose"
  }
}

A gruntjs egyetlen feladattal bír, ami jelenleg a linting (az egyszerűség kedvéért):

module.exports = function(grunt) {
    grunt.initConfig({
     lint: {
      files: ['hello.js']
    }
  });
  grunt.registerTask('default', 'lint');
  grunt.registerTask('travis', 'lint');
};

.travis.yml fájl tartalmazza a Travis CI beállításokat, hogy tudja a rendszer miként kell futtatni a tesztünket:

language: node_js
node_js:
  - 0.8

Most jelentkezzünk be a Travis-ba a Github felhasználónkkal és kapcsoljuk be a repó hook-ot a repositories fülön.

Github + Travis CI

Ha nem indul el a teszt, akkor manuálisan kell beállítani. A profil fülön másoljuk ki a token-ünket.

Travic CI token

Menjünk vissza Github-ra és aktiváljuk a Travis hook-ot bemásolva az imént megszerzett
token-t.

Github hook beállítása Travis CI kapcsolathoz

Első alkalommal egy git push kell, hogy elinduljon a folyamat. Ha minden rendben volt,
akkor látogassunk el a http://travis-ci.org/[username]/[repo-name] oldalra, hogy
lássuk a végeredményt.

Travis CI eredmények

Travis CI + Pull Requests

Korábban, amikor még nem volt a CI a Pull kérelmek elbírálásának folyamatában, akkor úgy ment az egész, hogy Pull Request, beolvasztás, aztán tesztelés, és ha nem volt jó, akkor visszaállítás. A Travis CI-nek köszönhetően a második és harmadik lépés felcserélődött, így gyorsabban kiderül, ha valami nem jó, és így könnyebb eldönteni, hogy lehet-e beolvasztani. Nézzük is meg, hogy miként megy a folyamat.

  • Küldünk egy Pull Request-et és hagyjuk, hogy a Travis megmondja, működik-e vagy sem.

Github Pull Request-ben látszódó Travis CI eredmények

  • Ha a módosításokkal hibásak a tesztek, akkor a Travis szól nekünk erről.

Ha hiba van a Pull Request-ben, akkor az látszik

  • Ha a piros figyelmeztető gombra kattintunk, akkor az elnavigál minket a Travis oldalára, hogy lássuk, mi nem jó.

A Travis CI és a Github kiemelten hasznos a csapat számára, mert automatikusan lefuttatja a teszteket és értesítést küld az eredményről. Így sokkal gyorsabban javításra kerülhetnek azok a hibák, amik lehet, csak később kerülnének napvilágra. Ha más eszközt használsz, mint mondjuk a Jenkins-t, akkor van lehetőség arra is, hogy egyszerűen együtt használd őket.

Code Review

A Github minden commit-hoz lehetőséget ad egy letisztult és egyszerű felületen, hogy megjegyzéseket fűzzünk egy adott módosítás adott sorához vagy az egész commit-hoz. Ez egy remek lehetőség, hogy sorról-sorra átnézhessük a változásokat, azokat átbeszéljük, vagy épp csak rámutassunk egy hibára, hibalehetőségre, jelezzük, hogy az adott kódolási stílus nem helyes adott projekten. A sorokhoz fűzött megjegyzéseket el lehet rejteni és meg lehet jeleníteni minden commit-nál a jobb felső sarokban lévő checkbox-al.

Github commit adott sorához is hozzá lehet fűzni megjegyzést

Nézzünk pár olyan URL mintát, ami segítheti a munkánkat. Először is, hogyan lehet lekérdezni két commit közötti különbséget?

  • Összehasonlítás ágak, címkék és SHA1-ek között : Az URL így néz ki egy összehasonlításra: https://github.com/[username]/[repo-name]/compare/[starting-SHA1]...[ending-SHA1]. Hasonlóan működik ágakra (branches) és címkékre (tags) is.

Commit-ok összehasonlítása

  • Összehasonlítás felesleges szóközök nélkül : Add hozzá az URL-hez a ?w=1 paramétert

Felesleges space-ek nélkül is megtekinthetőek a változások

  1. Diff : add hozzá a .diff kiterjesztést, hogy megkapd azt a formát, amit egy git diff is eredményezne. Hasznos lehet akkor, ha scriptelni szeretnéd a kimenetet.
  2. Patch : add hozzá a .patch kiterjesztést, hogy úgy lásd mintha egy git format-patch kimenete lenne (formázott patch email küldéshez).
  3. Sorra hivatkozás : Ha rákattintasz egy sor számára, a Github hozzáfűzi az adott sorszámot #line formában az URL végéhez így, ha valaki megnyitja a linket, akkor az adott sor háttere sárga lesz. Így pontosan rá lehet mutatni egy linkkel egy adott sorra. Ez a forma ugyan úgy elfogad tartományt is a #start-end formában. Itt egy példa a sorra hivatkozáshoz és egy a tartományra.

Dokumentálás

Ebben a fejezetben megnézünk két dokumentálási lehetőséget:

  1. Hivatalos dokumentáció: A forráskód dokumentálására van a Github Wiki
  2. Nem hivatalos dokumentáció: Github Hubot segítségével dokumentálható a beszélgetés a csapattagok között és automatizálható az információáramlás egy vicces boton keresztül.
  3. Megemlítés, gyorsbillentyűk és hangulatjelek

Github Wiki

A Github Wiki létrejön minden repóval és így egy helyen tud lenni a dokumentáció és a forráskód. Hogy létrehozz egy Wiki-t, szinte semmit se kell tenni, csak engedélyezni a beállításoknál. A Wiki-nek saját verziókövetése van és azt le lehet klónozni lokális gépre, akár csak magát a projekt repóját.

Github Wiki

Egy nagyon haszos dolog, ha például submodule-ként hozzáadjuk a Github Wiki-t a forráskódhoz, így nem kell két repót karbantartani és nincs elszeparálva a kettő. Ahhoz, hogy ezt megtegyük, adjuk hozzá a Wikit mint submodule. Természetesen ha használunk Travis CI-t, akkor meg kell neki mondani, hogy azt ne nézze, mert felesleges. Ezt egyszerűen megtehetjük, csak hozzá kell adni a .travis.yml fájlhoz pár sort:

git:
  submodules: false

Ezek után hozzáadhatjuk a Wiki repóját, mint submodule:

$ git submodule add git@github.com:[username]/[repo-name].wiki.git
Cloning into 'hello-team.wiki'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
$ git add .
$ git commit -m "added wiki as submodule"
$ git push origin master

Innentől kezdve a dokumentáció ott van a forrás mellett, mint submodule.

Github Wiki mint Submodule

Github Hubot

Hubot egy egyszerű csevegőbot, ami információkat fogad vagy küld szét értesítésként, ha össze van kötve a Github commit-okkal, kommentekkel, hibalistával és egyéb aktivitással. Egy csapatban, ahol szeretnénk lecsökkenteni a szükséges meetingeket (vagy akár teljesen ki is iktathatjuk), ott Hubot egy remek társ lesz. Minden egyes beszélgetést rögzít, így még inkább segíti a munkát akkor is, ha a csapattagok nem egy időben dolgoznak és írják le gondolataikat, kérdéseiket.

Vigyázat: Hubot függőséget okoz!

Kezdjük ott, hogy beállítjuk Hubot-unkat egy szerveren. Jelen esetben ez a Heroku lesz és a Campfire mint felület, ahol a kommunikáció folyni fog. Azért is ezt a kettőt választottuk, mert mindkettő ad lehetőséget ingyenes használatra.

  • Most a Hubot Github-os Campfire verzióját fogjuk használni. Ha gondolod, nézd meg milyen, más lehetőségek vannak már készen, mint Skype, IRC, Gtalk stb.
  • Csináljunk egy új Campfire fiókot, ami csak a Hubot-é, és ez a felhasználó létre fog hozni egy új csevegőszobát, ahova mindenki meg lesz hívva később.
  • Telepítsük fel Hubot-ot Heroku-ra a leírtak szerint. Ne problémázz azon, ha azt mondja az alkalmazás, hogy Cannot GET /, mert tényleg nincs ott semmi alapértelmezetten.
  • A Hubot Campfire fiókjából hívjuk meg magunkat. Most jelentkezzünk be a saját fiókunkba, és írjuk be, hogy Hubot help. Hubot szépen le fogja írni, hogy milyen parancsok vannak.

Hubot help parancs, ami segít megtudni, hogy mit tudsz még csinálni

  • Ki is próbálhatsz párat, mint például hubot ship it vagy a hubot map me CERN.

Hubot parancsok

  • Következőnek, hozzá kell adnunk egy Hubot script-et. Bőven van miből válogatni ha szeretnénk látni, mi mit csinál, akkor még illusztrációkat is találunk.
  • Mi most csak a github-commits script-et pakoljuk be, így minden egyes commit-nál értesíteni fog minket róla a csevegőszobában. Egyszerűen helyezzük a github-commits.coffee fájlt a scripts könyvtárba.
  • Frissítsük a package.json fájlt a szükséges függőségekkel, ahogyan le van írva minden script első soraiban, a kommentek alatt.
  • Élesítsük ki a változásokat egy git add package.json scripts/github-commits.coffee és egy git push heroku master paranccsal.
  • Navigáljunk el a repónkhoz, ahonnan szeretnénk, hogy értesítés érkezzen a commit-okról. Adjunk hozzá egy új web hook-ot és állítsuk be a [HUBOT_URL]:[PORT]/hubot/gh-commits?room=[ROOM_ID] címre, ahogyan a script is elmondja nekünk a fájl elején.

Github hook beállítása Hubot kapcsolathoz

  • Mostantól minden egyes commitról Hubot szólni fog a csevegőszobában.

Github Commit megjelenik Hubot-nak köszönhetően

Nézz szét további Github specifikus Hubot scriptek után vagy ha gondolod, írj sajátot, amihez találhatsz nagyon jó leírásokat. Hubot iszonyatosan fel tudja dobni a szürkének ható beszélgetéseket, commit-értesítéseket és úgy az egész dokumentálási folyamatot. Adj neki egy esélyt!

Végezetül pedig itt van pár olyan lehetőség, ami még segíthet:

  1. Említések – Bármilyen felületen, ahol szövegdoboz van, említhetünk másokat a kukac karakterrel, @user formában és erről a felhasználó kap értesítést.
  2. Gyorsbillentyűk – A [shift] + ? megnyomásával bármelyik Github oldalon megnézhetjük, hogy milyen gyorsbillentyűk vannak.
  3. Hangulatjelek – Az Emoji cheat sheet-et használva, a Github szövegdobozoknál támogatott a hangulatjelek beszúrása. Ezzel lehet egy kis színt
    vinni a csapatmunkába.

Nem szoftveres együttműködés Github-on

A legtöbben a Github-ra, mint szoftverfejlesztő eszközre gondolnak. Természetesen a Github erre is lett kitalálva. Közösségi kódolásra. De van jópár olyan repó, ami nem programozói, viszont ugyanúgy a csapatmunka miatt választották a Github-ot. Ezek a projektek ugyanúgy nyílt forrásúak és bárki dolgozhat rajtuk, így könnyű javítani a hibákat benne, illetve jelenteni, ha talál valaki egyet. Itt van pár érdekes repó, amikre ránézhetsz:

További olvasmányok

Legyen szórakozás a csapatmunka!

Ez csak egy kis ízelítő volt abból, hogy milyen jól lehet használni csapatban a Github-ot. Rengeteg eszköz áll rendelkezésre, amik segítenek analizálni, automatizálni vagy átláthatóbbá tenni egyes folyamatokat. Van egyéb dolog, ami szerinted hasznos lehet? Negatív vagy pozitív tapasztalatok? Oszd meg velünk lentebb.

Kapcsolódó cikkek:

Balazs Nadasdi

Developer, Project Manager, Blogger, Dad... or sometihng like these

  • Csima Gabriella

    Kedves Yitsushi!

    Kaptam egy 18 hónapos határozott idejű kutató-fejlesztői állást Exeterben, a Met. Office-ban. Megkérdeztem a leendő főnökömet, hogy mi lesz a munkám, hogy egy kicsit átnézzem azt a témát. A konkrét szakmai részen kívül a következőt írta:
    “Having only 18 months means a steep learning curve! So, I believe there is external access to FCM and Rose via github. It would be good if you had some understanding of those”

    Ebből a szövegből én csak az FCM-ről, a Rose-ról és a github-ról nem hallottam soha életemben….

    Kiprinteltem párszor 10 oldalt, olvasgattam is, de nem érettem szinte semmit, és igazán az lenne a jó, ha a gyakorlatban látnám ezeket. Mindennek a letöltése azonban nem megy, ráadásul feladatokat sem tudok szimulálni.

    Mit javasol, hogyan tudnék 3 héten belül értékelhetően felkészülni ezekből a témákból?? (A fenti írását olvastam, de egy idő után – a tiszta elmélet miatt – teljesen elvesztettem a fonalat, s kellően el is keseredtem…..és akkor még hol van az FCMés a Rose megértése és az esetleges elsajátítása…)

    Elnézést, hogy a problémám kicsit off-osra sikeredett!

    Köszönettel:
    Csima Gabriella

    • Ahogy ebből kiveszem a Github-hoz nem sok minden kell neked, elég csak a clone-ozás.

      Az FCM az ez az FCM?
      FCM: a modern Fortran build system, and wrappers to Subversion for scientific software development

      A Rose az ez a Rose:
      Rose: a framework for managing and running meteorological suites

      Ha privátban rámírsz, akkor lehet többet tudok segíteni, mert így publikusan nem igazán lenne illendő 😀