Web-basierte Anwendungen 1

Git-Basics

08. Oktober 2015

Studiengang Medieninformatik an der Fachhochschule Köln
Campus Gummersbach

M.Sc. Jan Kus

Ziele dieses Abschnitts

  • Einführung in Git
  • Zu wissen was ein Versionierungssystem ist
  • Den Unterschied zwischen Git und Github verstehen
  • Zu verstehen wie ein Git Workflow funktioniert
  • Was Commit Messages sind und wie man welche schreibt

Aufbau dieser Session

  • Was ist ein Versionierungssystem
  • Geschichte - Historie von Versionierungssystemen
  • Entstehung von Git
  • Unterschied zwischen Git & Github
  • Worschatz beim Umgang mit Versionierungssystemen
  • Git Grundlagen & Basisbefehle
  • Der einfachste Git Workflow

Frage an das Publikum

Wer weiss was ein Versionierungssystem ist?

Git Command

Frage an das Publikum

Wer kennt Git?

Git Command

Frage an das Publikum

Wer kennt github?

Github Artefact

Frage an das Publikum

Wer kennt andere Versionierungssysteme?

Github Artefact

Was ist Versionierung und ein Versionierungssystem?

Versionierung

[...] is the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the "revision number," "revision level," or simply "revision."

Ein Beispiel für Versionierung ist z.B.: Time Machine auf dem Mac oder z.B. Reinigungsprotokolle auf Toiletten die im nachhinein archiviert werden

Quelle: https://en.wikipedia.org/wiki/Version_control, Stand: 04.10.2015

Versionierungssystem (VCS)

A version control system is a piece of software that helps the developers on a software team work together and also archives a complete history of their work.
  1. We want people to be able to work simultaneously, not serially
  2. When people are working at the same time, we want their changes to not conflict with each other
  3. We want to archive every version of everything that has ever existed — ever. And who did it. And when. And why.

Quelle: Version Control by Example, Eric Sink, Stand: 04.10.2015

Evolution von Versionierungssystemen

Evolution von Versionierungssystemen

Wie sich Versionierungssysteme mit der Zeit verändert haben
  • Local VCS: In first generation tools, concurrent development was handled solely with locks. Only one person could be working on a file at a time. E.g.: RCS
  • Centrelized VCS: The second generation tools are a fair bit more permissive about simultaneous modifications, with one notable restriction. Users must merge the current revisions into their work before they are allowed to commit. E.g.: Subversion
  • Distributed VCS: The third generation tools allow merge and commit to be separated. E.g.: git

Quelle: Version Control by Example, Eric Sink, Stand: 04.10.2015

Entstehung von git

  • Git wurde 2005 von Linus Torvalds initieert nachdem Bitkeeper (bis dahin das genutzte SCM von der Linux Community) kommerzialisiert wurde und keine kostenlosen Zugang mehr angeboten hat
  • Linus Torvalds wollte ein dezentrales und performantes Versionierungs Software - seiner Ansicht nach gab es zu dem Zeitpunkt keine die seine Wünsche erfüllte
    • Dezentralität: Jeder Entwickler besitzt die Historie des ganzen Source Codes bei sich und verteilt nur seine Änderungen an andere Entwickler. Es gibt kein zentralen Server mehr der für den Ableich der einzelnen Entwicklungstände sorgt
    • Performance: 2005 brauchten Versionierungssysteme ca. 30 Sekunden um einen Patch zu versionieren und damit alle Metadaten zu aktualisieren. Bei dem Linux Core Team hätte es 250 solcher Aktionen zum gleichen Zeitpunkt gegeben - somit skalierten die ehmals auf dem Markt verfügbaren Versionierungssysteme nicht

Git

Git ist ein verteiltes Versions-Kontrollsystem mit dem Hauptaugenmerkmal auf Geschwindigkeit, Daten Integrität und der Unterstützung von verteilten und nicht-linearen Versionierungsvorgängen.

Git

Charakteristiken von Git:
  • Speed
  • Strong support for non-linear development (thousands of parallel branches)
  • Fully distributed development
  • Able to handle large projects like the Linux kernel efficiently (speed and data size)
  • Compatibility with existing systems/protocols

Quelle: Pro Git, Scott Chacon & Ben Straub, Second Edition, 2015

Git Server

Eine weitere wichtige Eigenschaft ist, dass Git, als ein dezentrales Versionierungssystem direkt sowohl einen Client als auch einen Server bereitstellt. Somit kann der Code zwischen den einzelnen Team-Mitgliedern weitergegeben werden ohne ihn auf eine zentrale Instanz zu besitzen. Jedoch können Git-Server Implementierungen nützlich sein um z.B.: erweiterte Zugriffskontrollen, Anzeige von Inhalt und das Verwalten von mehreren Repositories anzubieten.
  • Remote file store and shell access
  • Git daemon, instaweb
  • GitLab
  • Bitbucket
  • GitHub
  • Weitere komerzielle Anbieter

Was ist Github?

Github - erweiterter, externer Git-Server as a service

GitHub is a website where you can upload a copy of your Git repository. It is a Git repository hosting web service, which offers all of the distributed revision control functionality of Git as well as adding its own features. Unlike Git, which is strictly a command-line tool, GitHub provides a web-based graphical interface and desktop as well as mobile integration. It also provides access control and several collaboration features such as wikis, task management, and bug tracking and feature that can be helpful for projects.

Unterschied zwischen Git und GitHub

GitHub ist NICHT Git - GitHub benutzt Git
  • Git: Git is ein dezentrales System zur Versionskontrolle
  • Github: Github ist eine Webseite die Gitfunktionalitäten zugänglich macht und erweitert

Bitte merken!

Wortschatz beim Umgang mit Versionierungssystemen (1/2)

  • Command Line: The computer program we use to input Git commands. On a Mac, it’s called Terminal. In both cases, you type text-based commands, known as prompts, into the screen, instead of using a mouse.
  • Repository: A directory or storage space where your projects can live. It can be local to a folder on your computer, or it can be a storage space on GitHub or another online host. You can keep code files, text files, image files, you name it, inside a repository.
  • Version Control: Basically, the purpose Git was designed to serve. When you have a Microsoft Word file, you either overwrite every saved file with a new save, or you save multiple versions. With Git, you don’t have to. It keeps “snapshots” of every point in time in the project’s history, so you can never lose or overwrite it.

Quelle: GitHub For Beginners: Don't Get Scared, Get Started, 07.10.2015

Wortschatz beim Umgang mit Versionierungssystemen (2/2)

  • Commit: This is the command that gives Git its power. When you commit, you are taking a “snapshot” of your repository at that point in time, giving you a checkpoint to which you can reevaluate or restore your project to any previous state.
  • Branch: How do multiple people work on a project at the same time without Git getting them confused? Usually, they “branch off” of the main project with their own versions full of changes they themselves have made. After they’re done, it’s time to “merge” that branch back with the “master,” the main directory of the project.

Quelle: GitHub For Beginners: Don't Get Scared, Get Started, 07.10.2015

Git Basisbefehle (1/4)

  • git config: Short for “configure,” this is most useful when you’re setting up Git for the first time.
  • git help: Forgot a command? Type this into the command line to bring up the 21 most common git commands. You can also be more specific and type “git help init” or another term to figure out how to use and configure a specific git command.
  • git status: Check the status of your repository. See which files are inside it, which changes still need to be committed, and which branch of the repository you’re currently working on.

Git Basisbefehle (2/4)

  • git init: Initializes a new Git repository. Until you run this command inside a repository or directory, it’s just a regular folder. Only after you input this does it accept further Git commands.
  • git clone: Importing a Git repository using the command line

Git Basisbefehle (3/4)

  • git add: This does not add new files to your repository. Instead, it brings new files to Git’s attention. After you add files, they’re included in Git’s “snapshots” of the repository.
  • git commit: Git’s most important command. After you make any sort of change, you input this in order to take a “snapshot” of the repository. Usually it goes git commit -m "Message here."" The -m indicates that the following section of the command should be read as a message.
  • git push: If you’re working on your local computer, and want your commits to be visible online on GitHub as well, you “push” the changes up to GitHub with this command.
  • git pull: If you’re working on your local computer and want the most up-to-date version of your repository to work with, you “pull” the changes down from GitHub with this command.

Git Basisbefehle (3/4)

  • git branch: Working with multiple collaborators and want to make changes on your own? This command will let you build a new branch, or timeline of commits, of changes and file additions that are completely your own. Your title goes after the command. If you wanted a new branch called "cats" you’d type git branch cats
  • git merge: When you’re done working on a branch, you can merge your changes back to the master branch, which is visible to all collaborators. git merge cats would take all the changes you made to the "cats" branch and add them to the master.
  • git checkout: Literally allows you to "check out" a repository that you are not currently inside. This is a navigational command that lets you move to the repository you want to check. You can use this command as git checkout master to look at the master branch, or git checkout cats to look at another branch.

Der einfachste git Workflow

  • git init oder git clone: Initieeren eines lokalen git-Repository oder das kopieren eines Remote-Repository in ein lokales Verzeichnis (z.B.: ein Github Repository)

[Änderungen am Code vornehmen]

  • git add: das Bekanntmachen der Veränderungen oder neuen Dateien an git. Ein so genanntes Snapshot. Es ist noch nicht fester Bestandteil der Repository.
  • git commit: Hinzufügen der Snapshots in die Repository.
  • git push : Eine kopie der Repository an das Remote-Repository laden. Nur im Falle das ein existiert (wie z.B.: Github)

One More Thing: Git Commit Messages

Git Commit und Messages

Wenn man im verteilten Team arbeitet, dann ist es sehr wichtig mit aussagekräftigen Commit Messages zu arbeiten. Ein unlesbares Beispiel:

$ git log --oneline -5 --author cbeams"
e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils

Git Commit und Messages

Wenn man im verteilten Team arbeitet, dann ist es sehr wichtig mit aussagekräftigen Commit Messages zu arbeiten. Ein lesbares Beispiel:

$ git log --oneline -5 --author pwebb
5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage

Git Commit und Messages

The contributors to these repositories know that a well-crafted git commit message is the best way to communicate context about a change to fellow developers (and indeed to their future selves). A diff will tell you what changed, but only the commit message can properly tell you why.
  • Markup syntax, wrap margins, grammar, capitalization, punctuation: Spell these things out, remove the guesswork, and make it all as simple as possible. The end result will be a remarkably consistent log that's not only a pleasure to read but that actually does get read on a regular basis.
  • Content: What kind of information should the body of the commit message (if any) contain? What should it not contain?
  • Metadata: How should issue tracking IDs, pull request numbers, etc. be referenced?

Quelle: http://chris.beams.io/posts/git-commit/, 07.10.2015

Git Commit und Messages

The seven rules of a great git commit message
  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

Literatur