H9: Werken op GitHub

• ICT
• MBO
• Studiejaar 4

Hub, GitHub, Hub!

https://myoctocat.com/build-your-octocat/

It's a-me!

Als je maar lang genoeg xkcd strips toe blijft voegen aan je slides vindt vanzelf iemand het grappig, toch? Toch?

Leerdoelen

• Leren over verschillende "workflows"
  
• Branching toepassen op GitHub
• Pull requests om te mergen
  
• Werken met issues door commits te doen

Benadruk dat wat we gaan leren in principe van toepassing is op GitHub, maar dat het net zo goed kan op GitLab, gitea, [jouw git server hier]

Commandline

Vorige keer werkten we met de commandline, maar nu mag je git doen op de manier die het comfortabelst voor je is.

Hackermannnn

Als iemand weet waar dit plaatje van is mag je ze een aai over hun bol geven.

"Workflows"

De workflow is de manier waarop je op een git-server samenwerkt aan een project met meerdere mensen. De manier waarop je samen hebt afgesproken om issues op te lossen.

Centralized

Iedereen werkt in dezelfde branch.

Je commit lokaal, en als er changes zijn remote moet je eerst "rebasen"

https://www.atlassian.com/git/tutorials/comparing-workflows

Centralized

Merge conflicts every day all day.

Iedereen zit elkaar constant in de weg.

Alleen werkbaar als je alleen of in een heel klein team werkt.

Of als je in ieder geval niet op dezelfde tijden werkt.

Even benadrukken dat deze oplossing kwalitatief uitermate teleurstellend is.

Forking

Iedereen die iets wilt toevoegen maakt een "fork" van de volledige repository.

Changes terug naar de originele repository moeten dan met een pull request.

Leuk grapje maken over een FORKING STRATEGIE, klinkt vulgair als je het in een brits accent doet.

https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

• Handig om samen te werken met mensen die je niet kent
• Wel wat extra werk
  

Even checken of iedereen het verschil weet tussen een fork en een clone.

Forking

Vooral handig voor grote changes aan open source projecten.

Minder handig voor kleine changes aan projecten in eigen beheer.

Feature branching

Iedere nieuwe feature of issue wordt gemaakt in zijn eigen branch.

Iedere branch wordt dan weer teruggevoegd naar de main/master.

Dit is een vrij gebruikelijke in bedrijven.

Deze gaan we vandaag mee oefenen!

https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Voordelen:

• Je commit graph komt er mooi uit te zien
• Kan goed samenwerken met veel mensen in één team
• Geen gedoe met extra repositories
• Weinig rebases nodig
  

Nadelen:

• Elk issue wordt een branch!
• Veel merges, dus mogelijk ook veel merge conflicts.
• Je commit graph komt er ingewikkeld uit te zien
  

Issue closing

https://github.blog/news-insights/product-news/closing-issues-via-commit-messages/

"Closes #42"

"Fixes #510"

"Resolves #12"

Git feature branching

We gaan wat oefenen met feature branching, en eventueel de merge conflicts daaruit volgen.

Stappenplan:

1. Maak een issue
2. Maak een nieuwe feature branch voor die issue
3. Fix de issue in je code in die branch
   
4. Commit en push naar branch met message "Fixes #nr"
5. Maak een pull request voor die feature branch.
6. ???
7. Profijt
   

OF!

Pull request

Niet forken!!!!

Opdracht!

Werkblad op itsl

Repo template copy

4x Issues aanmaken

4x Feature branches maken

4x Pull requests aanmaken

4x Pull requests mergen

IN DIE VOLGORDE. Eerst vier issues, dan vier branches, etc.