Workshop // November 12th, 2018 // Faktor E Multimedia GmbH

Timetable

Timetable

• What the GIT? advantages of distributed version control
• More than versioning control how GIT can help you with your daily work
• Far far away all about GitHub and other remotes
• Features and environments let's learn more about GIT branching
• Back to the roots merge your changes back to master or should you rebase?
• From development to production how to use GIT as a deployment tool
• Continuous integration GIT as part of automated quality assurance
• Continuous delivery GIT as part of automated deployment processes
• Sneak preview about GIT flow and other branching concepts

What the

“In software development, distributed version control [...] is a form of version control where the complete codebase - including its full history - is mirrored on every developer's computer.” Wikipedia: Distributed Version Control

GIT is the most common DVCS

but this does not only let you take care of code changes

GIT
is more than
version control

how GIT can help you with your daily work

Home is where the Dom is

let's just forget about remotes for now

Let GIT be your friend

GIT helps you to...

• ...temporary cleanup your working tree from stuff you've worked on.
• ...compare several development states fast and easy.
• ...prepare your versioning structure before you make it available to others.
• ...develop multiple features simultaneously without getting confused.
• ...keep track of deployed changes on several environments at a glance.

$git stash

put all the changes aside for now

$git stash

• $git stash -m "My notice to remember what I've stashed"
• $git stash list
• $git stash show [<stash>]
• $git stash apply
• $git stash drop
• or simpler:
• $git stash pop (git stash apply && git stash drop)

$git status

know what's going on

$git status

• – list changed files
• – check if they're staged to commit or not
• – list untracked files
• – list unresolved conflicts
• – check if the local repository is up to date with the remote(s)
• – I foolish forgot there are no remotes yet. ;-)

$git diff

know whats going on, but in detail

$git diff

• $git diff (get all unstaged changes on your working tree)
• $git diff --cached (get all changes that are staged to be committed)
• $git diff -w (ignore all space - but be patient, the changes will be committed even if not shown in the diff output)
• – For sure there's more. Have a look at the documentation. Or use a GUI for this. We'll have a look at several GUIs later.

$git branch

create a new spin-off from the current status

When to use branches?

• – use branches to start working on a new feature
• – use branches to separate development stages of different environments
• – use branches to prepare changes you need in different branches afterwards

  •     – think about hot fixes for example
• – use branches to test things and keep the changes without messing up your history

When NOT to use branches?

• – don't use branches to track changes of totally different things

What to do instead:

• – put them in one repository when it makes sense
• – use a separate repository when necessary
• – let them interact which each other by using a sub module

Rule of thumb:

• – you should not be afraid to regularly switch branches as this would rewrite almost your whole working tree

$git branch

• $git branch temp/my-temporary-branch
• $git checkout temp/my-temporary-branch
• or simpler:
• $git checkout -b temp/my-temporary-branch
• $git branch -D temp/my-temporary-branch
• Hint:
• $git branch -d my-branch-name
  works only if the branch was successfully merged
• $git branch -D my-branch-name
  means force deleting the branch regardless if merged or not

GIT branching

basics and best practices

We're still @home

Don't even try to think about GitHub.

But first: how to commit

The ultimate guide for the perfect commit ;-)

• – Different changes should be in separate commits
• – Separate subject from body with a blank line
• – Limit the subject line to 50 characters
• – Wrap the message body at 72 characters
• – Use a proper prefix for every commit
      – [TASK], [FEATURE], [BUGFIX], [CLEANUP], [DOCS]
      – [WIP][FEATURE], [!!!][TASK]
  
• – Explain what and shy instead of how
• – Describe the new behavior instead of what changed

Good example:

[BUGFIX] Fixes displayed fields for teaser element

Ensures that only the required fields for this element
are shown in the backend.

A simple but effective branching concept:

• – Create a branch for every environment
• – Use branches to separate unfinished features
• – Regularly pull changes from the main branch into you feature branch
• – Use hot fix branches when needed
• – Merge feature branches back into the main branch when finished
• – Merge the environment branches in the order in which they'll get deployed

The main branch may NOT be master

The master branch should always represent the current state on production

A common list of branches for a project:

• – Environment branches
      – development, staging, master
• – Feature branches
      – feature/refs47-card-teaser, feature/refs11-require-js-loader
• – Feature branches
      – hotfix/xss-vulnerability-in-ext-fe_contact

Put the changes back into master

what you want to know about merging and rebasing

Yep, still the Kölner Dom.

Don't worry, we'll leave Cologne soon.

Let's have a look:

Merge vs. Rebase vs. Fast Forward vs. No Fast Forward

Rule of thumb:

• –Merge and No Fast Forward will create a merge commit which contains all changes since the last merge
• –Rebase and Fast Forward will copy all commits to the other branch

Let's have a look in a live demo!

Rebase hint:

• – Rewriting and reorganising the local history is no problem as long as it is not pushed to ANY remote
• – Do NOT rewrite remote histories if you're not sure what you're doing
• – A separate commit to revert some accidentally committed changes is totally fine

$ git push --force

Always avoid using git push --force

Use git push --force-with-lease if it's totally necessary to force push

Let's leave Cologne

Far far away

all about remotes

Gerrit Code Review

Hint: https://review.typo3.org

GitLab (SaaS)

GitLab (self-hosted)

But:
remotes can be anywere

GIT remotes can be...

• ...a SaaS like GitHub or Bitbucket
• ...a self-hosted solution like Gerrit or GitLab
• ...a bare-repository somewhere...
  • e.g. on your local filesystem
  • or on a server accessible over SSH

What the
heck is a
bare-repository?

bare vs. non-bare repositories

• – the .git directory contains all versioning information
• – and additionally some configuration and maybe hooks
• – everything beside this folder would be called working tree
• – well not exactly as the ignored files do not belong to the working tree
• – so anyway, what is a bare-repository?
• – it's the .git directory even if this might have a different name
• – bare-repositories do not have a working tree
• – they just contain the versioning information, some configuration and maybe hooks

$git push

Finally bring your work to a place where everyone can see it

okay or just the project team can see it ;-)

$git push

And here's the point:

• – you can not push to a non-bare repository
• – okay, you might be able to do that under certain circumstances when using GIT version > 2.3
• – but you should not push to a non-bare-repository ;-)
• – why? well, what's if the working tree is not clean?
• – it's just not the way how you should work with GIT

From development
to production

how to use GIT as a deployment tool

Why no git pull?

• – the destination environment (mostly owned by customer) needs access to our GitHub account
• –
• – more possibilities and flexibility using hooks (we'll have a closer look in a minute)
• – overall overview of development and deployment states in your GIT GUI or on CLI

Deployment using GIT hooks

Live Demo! ;-)

GIT tags

Unfortunately I have not prepared any slides for it :-(

TYPO3 Surf

As well no slides for this one :-(

Continuous integration

what Mr. Jenkins has to say about this

Mr. Jenkins, at your service.

Have a look at: https://jenkins.io/artwork/ ;-)

CI of TYPO3 core was based on Jenkins is now running on Bamboo

So should we prefer Bamboo over Jenkins

Well...

• ... Bamboo is an Atlassian SaaS
• ... Bamboo is based on a paid license model
• ... Jenkins is a open source software forked from Hudson (Sun/Oracle)
• ... for TYPO3 as an OpenSource project Bamboo is free of charge
• ... So, from TYPO3 perspective they lower the maintenance costs by using Bamboo
• ... anyway, there're more tools beside Bamboo and Jenkins

Travis CI

GitLab (again)

Why to use Continuous Integration in the first place

• – build an running application using a predefined build chain
• – automated tests which means party automated quality assurance
• – measuring of code quality
• – and many more

Continuous delivery

deployments as an automated process
of your daily work

Continuous delivery

Let's combine continuous integration and deployments

Sneak preview

A first look on GIT flow, alternative branching concepts and other best practises

Some tips

links and stuff

learn
GIT
branching

also have a look at the remote tutorials in the 2nd tab

Visualizing GIT

just a playground to try out some things you're not sure about

graphical user interfaces

available for Windows and MacOS

tortoise git - avilable for Windows

handle GIT using the context menu

For sure there are more.

Show us your favorite

GUI hint:

• – some tools may not respect your global GIT configuration
• – especially on Windows
• – this may concern the user name and mail address
• – but also default behaviors like auto-rebase on pull

Credits

Links

GIT SCM // GitHub // Bitbucket // Gerrit Code Review // Gitlab // Jekins // Bamboo // Travis CI // LearnGitBranching // Visualizing GIT // Tower GIT // Sourcetree // TortoiseGit // TortoiseGit //

Credits

Used images

Slide 2 (philipterrygraham) Slide 3 (Nicola) Slide 4 (stevensnodgrass) Slide more than vcs (Bergadder) Slide wikipedia quote (aitoff) Slide dom (377053) Slide airport (Didgeman) Slide fra far away (Larisa-K) Slide clouds (dimitrisvetsikas1969) Slide branches (geraldfriedrich2) Slide schokoladenmuseum (taxicologne) Slide background dark (dannysantos) Slide merge (ulleo) Slide dom2 (MaxWaidhas) Slide dev to prod (cocoparisienne) Slide CI (ralf-steinberger) Slide CD (lukasbieri) Slide Sneak Preview (mermyhh) Slide Lightbulb (jplenio) Slide magic mouse (Huber_Alexander) Slide thanks (lzeebythesea)