Skip to content

Instantly share code, notes, and snippets.

@vstrimaitis
Created September 22, 2017 18:32
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vstrimaitis/75d7660ff44baa72b75d4528a0324f1f to your computer and use it in GitHub Desktop.
Save vstrimaitis/75d7660ff44baa72b75d4528a0324f1f to your computer and use it in GitHub Desktop.
vu_hci git+latex workflow proposal

Git + LaTeX workflow

  • Rašyti kiekvieną (+-) sakinį iš naujos eilutės (eilutės ilgis būtų gerai, jei neviršyt kokių 80 simboli teksto). Gerai todėl, kad git'as skaido tekstinį failą eilutėmis, tai pakeitimai diff'e geriau matytųsi, jei tekstas irgi būtų paskaidytas eilutėm.
  • Paskaidom visą dokumentą į atskirus failus (tarkim po atskirą failą kiekvienam skyriui) ir tada tuos failus pagrindiniam faile įsimetam su \include{file}. Potencialiai sumažintų konflikt riziką ir šiaip skaidymas yra gerai, kaip ir visur.
  • Išnaudokim git'o branch galimybę. Vietoj to, kad visi dirbtų vienu metu ant master branch'o, kiekvienam issue (tarkim) pasikuriam po atskirą branch'a. Kai manom, kad padarėm viską, ko tas issue prašo, galim merge'int į master. Šitas irgi padėtų struktūrizuot darbą ir galbūt padėtų išvengti random merge konfliktų.
  • Dokumento versiją atnaujinam su kiekvienu push'u į master branch'ą. Čia tik šiaip pasiūlymas, bet master'y teoriškai turėtų būt kažkokia daugiau mažiau baigta dokumento versija, todėl būtų logiška būtent ją ir versijuoti.
@MantasPtr
Copy link

MantasPtr commented Sep 22, 2017

  1. Rašymą iš naujos eilutės mes kažkur naudojom ir gan neblogai atrodė, bet susidaro problemos dėl jei ilgų sakinių. Tai galima ilgus sakinius arba išreikšinai skaidyti (galima perkeltos eilutės pradžioje dėti tarpo simbolius) arba palikti skaidyti text editoriams.
  2. Skaidymas į failus gal ir nice, nesugalvoju stiprių atgumentų prieš. (naudojam \include ar \input ?)
  3. Branchinimas gali turėt tik vieną problemą - gali būt sunkiau "daryt taip kaip pas jį/ją padarytą" nes iš kito brancho copy + paste sunkiau nei iš vieno failo. Bet galima prieš darant susitart dėl bendros struktūros, pasidaryt vieną pavyzdį kartu ir tada dirbti branchuose.
  4. Su versijom galima ir pasižaisti, svarbu tik neužsižaisti :D. Ir klausimas kada 0.XX turėtų virsti 1.00?
  • Galim kurti git issues planuojamiems darbams, pastebėjimams ir pakeitimams

@vstrimaitis
Copy link
Author

  • Dėl ilgų sakinių manau nebus labai problemos, tiesiog jei matos kad jau labai užsitęsia, tai vidury kur nors vietoj tarpo įdėt newline ir viskas turbūt good.
  • Dėl bendros struktūros sutinku, galvoju prieš pasiskirstant darbus padaryt tokį "karkasą", kur matytųs, kur kokie skyriai/poskyriai ir kaip viskas struktūrizuota, tai turėtų bent kažkoks guide gautis. Jei neužteks, tai visada galima kitų žmonių paklaust, kaip darom X ar Y.
  • Manau 0.XX keičiam į 1.00 prieš atsiskaitymą. Po to jei reiks pakeitimų tiesiog bus 1.XX, gal čia nėra labai svarbu. Nebent dar kokių pasiūlymų būtų.
  • Dėl issues sutinku. Pradžiai manau reik susikurt po issue kiekvienam skyriui, kurio reiks visam projekte. Po to projekto eigoj galbūt dar atsiras ko

@vstrimaitis
Copy link
Author

Pastaba dėl \include ir \input gera, kiek dabar skaitau, tai \include daro tą patį, kaip ir \input, tiesiog dar išvalo puslapį. Tai čia jau eigoj turbūt priklausys, ar mum to reiks ar ne.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment