Git in the European Parliament

DG ITEC
Innovation and Technological Support
Git
Pierre-Antoine Grégoire - Jean-Pol Landrain
Solutions ALSA

DG ITEC
Git
Solutions ALSA
https://www.youtube.com/watch?v=4XpnKHJAok8
Pronounced [ɡít] by Linus Torvalds
“I see SVN as the most pointless project ever started”

DG ITEC
Git
Solutions ALSA
A brief history
➢ BitKeeper
○ commercial distributed Source Code Management (SCM)
○ free for open-source projects
○ used for source code of Linux kernel
➢ Linux kernel in 2005
○ 7 millions LOC
○ 400 developers
➢ 3rd April 2005, conflict about free usage of BitKeeper for OSS projects
○ Linus Torvalds searches alternative. Can’t find one matching requirements
○ Linus freezes Linux kernel. Starts developing Git, based on BitKeeper

DG ITEC
Git
Solutions ALSA
A brief history
➢ 16th June 2005, Git released, kernel developers start using it
➢ Feb 2008, GitHub launched
➢ 2009, 46.000 public repositories, 100.000 users on GitHub
➢ 2016, 31 millions public repositories, 12 millions users on GitHub
➢ 2018: 25 millions LOC, 62296 files, 1316 developers, >600000 pushes (total) on
the Linux kernel

DG ITEC
Git
Solutions ALSA
Why Git ?
❏ “If you’re not distributed, you’re not worth using” ⇒ Distributed
❏ “If your perform badly, you’re not worth using” ⇒ Performant
❏ “If you cannot guarantee that the stuff I put into an SCM comes out exactly the
same, you’re not worth using” ⇒ Reliable
“I can write something better than anything out there in two weeks”
According to Linus:

DG ITEC
Git
Solutions ALSA
Centralized vs Distributed SCM
● Explanation
● Centralized SCMs
○ CVS
○ SVN
○ Perforce
○ M$ Team Foundation Server (TFS)
○ M$ Azure Devops: currently based on a cloud version of TFS (however M$ recently bought GitHub)
○ IBM Rational Clearcase (aka Clearcase)
● Distributed SCMs
○ BitKeeper
○ Git
○ Mercurial
○ Bazaar (used by Canonical for Ubuntu)
○ Fossil
○ Gnu Arch (deprecated, being replaced by Gnu Bazaar)

DG ITEC
Git
Solutions ALSA
Advantages of a distributed SCM
● Able to work when the central SCM server or the network are not available
○ Maintenance, upgrades, unplanned downtimes
● Able to take the code everywhere, and to transfer it between multiple sources
○ Plane, train, hotel
○ No real central source
● Able to modify the code everywhere and at any time without connection
○ Includes commits, view logs, browse modifications, create branches, tags, etc.
● Many replications of the entire history of the code
○ Less easily prone to file or database corruptions
● Everyone has his own private branches of the code
○ Branches extremely “cheap” to create/delete
○ Easy to switch between them ⇒ 1 branch per specific task or JIRA ticket (potentially shared)
○ Relatively easy to merge/reconciliate/replay changes (vs centralized SCM)
○ Can be built and tested in isolation of other developments (even from a central build server)

DG ITEC
Git
Solutions ALSA
Create a local git repository
● repository:
○ working directory: checked out files, current branch
○ git tree, located under “.git” subdirectory
● Starting fresh
○ “git init”
● From existing remote location
○ “git clone”
(not “git checkout” !)
● git clone ssh://[user@]host.xz[:port]/path/to/repo.git
● git clone git://host.xz[:port]/path/to/repo.git
● git clone http[s]://host.xz[:port]/path/to/repo.git/
● git clone ftp[s]://host.xz[:port]/path/to/repo.git/
● git clone file:///path/to/repo.git/
Repository
working
directory
git tree
(.git)

DG ITEC
Git
Solutions ALSA
Content of git tree (.git)
settings of repository and definition of remote locations
description of repo (obsolete file, legacy of “gitweb”)
Client-side scripts automatically executed before or
during certain commands (like svn hooks but on client)
patterns of files to exclude from git processing (like .gitignore but local, not shared)
all the commits in the repository (some compressed under “pack” subdir)
Files that contain hashes of certain commits (heads, branches, tags) and remote refs locations
Name of the reference that designates the current HEAD

DG ITEC
Git
Solutions ALSA
First step with Git
● git config --global user.name "GREGOIRE Pierre-Antoine"
git config --global user.email pierre-antoine.gregoire@ext.europarl.europa.eu
● System settings: --system
○ Linux: /etc/gitconfig (root privilege required)
○ Windows: C:UsersAll UsersGitconfig
● User settings: --global
○ Linux: $HOME/.gitconfig
○ Windows: %HOMEDRIVE%%HOMEPATH%.gitconfig
⇒ C:Usersusername.gitconfig
● Repository settings: --local
○ Inside repository “.git/config” file

DG ITEC
Git
Solutions ALSA
First step with Git
● git config --list --show-origin
file:/home/EP/jplandrain/.gitconfig user.email=jean-pol.landrain@ext.europarl.europa.eu
file:/home/EP/jplandrain/.gitconfig user.name=LANDRAIN Jean-Pol
file:/home/EP/jplandrain/.gitconfig gui.recentrepo=/home/EP/jplandrain/git/ep-foundry-examples-spring-boot-spring-security
file:/home/EP/jplandrain/.gitconfig gui.recentrepo=/home/EP/jplandrain/git/ep-foundry-common-parent
file:.git/config core.repositoryformatversion=0
file:.git/config core.filemode=true
file:.git/config core.logallrefupdates=true
file:.git/config remote.origin.url=http://jplandrain@scm.ep-foundry.ep.parl.union.eu/git/scm/alsaex/ep-foundry-examples-spring-boot.git
file:.git/config remote.origin.fetch=refs/heads/*:refs/remotes/origin/*
file:.git/config remote.origin.tagopt=--tags
file:.git/config branch.master.remote=origin
file:.git/config branch.master.merge=refs/heads/master
file:.git/config branch.abandoned-feature-kept-for-reference-dont-merge/remove-security-constraint-web-xml.remote=origin
file:.git/config branch.abandoned-feature-kept-for-reference-dont-merge/remove-security-constraint-web-xml.rebase=true

DG ITEC
Git
Solutions ALSA
First step with Git
● In Eclipse

DG ITEC
Git
Solutions ALSA
Staging area (aka “index”)
● Logical space that holds a snapshot of the working directory
and where modifications are transferred until they are committed
● Once a file in index, modifications are tracked (but not saved yet)
⇒ use “git status” to view the state
● If file modified after being transferred to index
⇒ must re-add to transfer the new changes to staging area
● Can transfer select modifications to index, instead of whole content of a file (also from Eclipse)
working
directory
index
add
git tree
(.git)
commit

DG ITEC
Git
Solutions ALSA
➢ Two files: a.txt and b.txt
➢ a.txt already in index
➢ a.txt modified after being transferred to index
➢ b.txt not yet in index
> git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: a.txt
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: a.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
b.txt

DG ITEC
Git
Solutions ALSA
● Transfer file to index:
○ git add “filename”
○ git add “directory” (recursive)
○ git add -A ⇒ add all the changes recursively from the root of the working directory
○ git add . ⇒ add all the changes recursively from the current folder
● Remove file from index:
○ git rm --cached “filename”
⇒ removes the file from the index but leaves it in the workspace
● file becomes “untracked”
○ git revert “filename”
⇒ replace the changes in the file with the version in HEAD
● file in HEAD, changes are lost but file still tracked
● file not in HEAD, deleted and removed from index
● Transfer partial modifications to a file to index (also possible from Eclipse):
○ git add -p “filename”
⇒ git asks confirmation for every chunk of modification to add in index

DG ITEC
Git
Solutions ALSA
From staging area (“index”) to git tree
● git commit -m “commit message”
○ git tree is local (.git subdirectory) ⇒ commits not shared !
● View the references logs: git reflog
○ Only local, shows when the HEAD reference (by default) has been updated
○ Similar to a local “undo” history

DG ITEC
Git
Solutions ALSA
● View the references logs: git reflog
○ Can be used on a branch pointer too: git reflog branchName

DG ITEC
Git
Solutions ALSA
● View the commit logs: git log
○ Show the operations log for the current branch, including remote changes
○ Local operation, must locally “fetch” the latest changes in order to see the remote operations
commit 9e32d0345e771382d4c08a887203f32f1295bdea (HEAD -> master, tag: spring-boot-1.5.16, origin/master, origin/HEAD)
Author: LANDRAIN Jean-Pol <jean-pol.landrain@ext.europarl.europa.eu>
Date: Wed Sep 19 15:52:29 2018 +0200
Upgrade to latest Spring Boot version 1.5.x (1.5.16)
commit b77b75d01678d4c552edc28d4053ddc0f2e2f990 (tag: spring-boot-1.3.6)
Author: LANDRAIN Jean-Pol <jean-pol.landrain@ext.europarl.europa.eu>
Date: Thu Jul 13 16:42:45 2017 +0200
Updated for Tomcat 8.0.x
● View the changes: git show <ref>
⇒ show a textual diff of the changes

DG ITEC
Git
Solutions ALSA
● In Eclipse
○ git commit

DG ITEC
Git
Solutions ALSA
● In Eclipse
○ “Git Reflog” and “History” views

DG ITEC
Git
Solutions ALSA
What is a commit hash ?
● SHA-1 hashes: input data ⇒ 40 characters string; same input ⇒ same result
> echo "foobar" | openssl sha1
988881adc9fc3655077dc2d4d757d480b5ea0e11
> echo "foobaz" | openssl sha1
3bd2e705823a1e333c44dbf314477d903fd20498
● Commit hash
○ similar role to SVN revision number
sha1(
- meta data:
-- commit message
-- committer
-- commit date
-- author
-- authoring date
- sha1(entire workspace)
- sha1(parent commit(s)) [ usually one parent, two in case of simple merge, and more if multiple merges in one commit ]
)
○ Integrity check: use the hash to check the integrity of every commit and its relation to other commits

DG ITEC
Git
Solutions ALSA
What is a reference ?
● A reference (ref) is a named marker
● Four types of references
○ HEAD:
■ points to the branch reference that is currently checked out
● git checkout master → HEAD = refs/heads/master
● git checkout test → HEAD = refs/heads/test
■ or to a specific commit: detached HEAD
● git checkout e21c → HEAD = e21c5175dfde56ecba3f6cd692752250ee7dddd7
○ Branch reference:
■ named marker that points to a specific commit
■ moves when commits added to a branch in order to point to the last commit
■ located under /refs/heads/<branch_name>
/refs/heads/test = bf249e9b2d13a42461c6b8649b6c3d1131736fbc
git checkout test
add a file
commit →2d173fa3b4fcf9cd99459a66b1568420d5c51e42
/refs/heads/test = 2d173fa3b4fcf9cd99459a66b1568420d5c51e42

DG ITEC
Git
Solutions ALSA
What is a reference ?
○ Tag reference:
■ fixed marker that points to a specific commit
■ located under /refs/tags/<tag_name>
○ Remote reference
■ reference to a branch in another repository
■ defined in .git/config file and pointers located under /refs/tags/remotes/<remote_name>
■ contains:
● source direction: push or fetch
● remote URL
● remote branch_name
● commit hash of last fetch or last push

DG ITEC
Git
Solutions ALSA
Synchronize with remote repository
Remote
repository
Local repository
working
directory
git tree
(.git)
git push
git fetch
git merge
git pull = git fetch + git merge
Must pull before push (to resolve eventual conflicts)

DG ITEC
Git
Solutions ALSA
Example of work with multiple remote repositories
Central
remote repository
Local repository
working
directory
git tree
(.git)
origin/master
forked remote
repository
private/master
● origin and private are aliases for remote locations (URLs)
● origin is the default alias name when cloning URL
● master is the default branch name (similar to trunk in SVN)

DG ITEC
Git
Solutions ALSA
Merge vs Rebase
● Merge feature branch into the master branch
git checkout master
git merge feature
(= git merge master feature)
Non-destructive operation: a new commit for merge operation (with 2 parents)
But history harder to follow with frequent merges
● Rebase feature branch on top of the master branch
git checkout feature
git rebase master
History of feature branch rewritten: commits from feature branch repeated into master branch (new commits)
Clean history: single path

DG ITEC
Git
Solutions ALSA
Merge vs Rebase
● Rebase = history of branch rewritten
⇒ What if the branch is shared ?
We have a branch that is now completely different of the shared branch other users are using !
⇒ The other users can’t push their changes after you:
conflicts arise when they try to push after you have pushed !
⇒ They will be tempted to force push their changes
thus overwriting your changes !!!
⇒ Complete mess !!!!!!
DON’T USE REBASE ON PUBLIC SHARED BRANCHES
safe on local branches, private branches and on non-shared public branches
DON’T FORCE PUSH
unless in specific cases, and when you exactly know what you are doing

DG ITEC
Git
Solutions ALSA
Merge vs Rebase
● git pull = git fetch + git merge
⇒ merge commit
● git pull --rebase = git fetch + git rebase
⇒ rebase

DG ITEC
Git
Solutions ALSA
Stashes
● Save uncommited changes temporarily
git stash save
git stash pop

DG ITEC
Git
Solutions ALSA
EP SCM Standard for Git
● http://ep-foundry.ep.parl.union.eu/standards/
● No large binary files
● Default branching model:
○ development branch → master (merged into production when preparing a release)
○ production branch → production (branch from master and merged into release branches)
○ feature branches → feature/ prefix (branch from and to master)
○ hotfix branches → hotfix/ prefix (branch from production and merges into production and into master)
○ release branches → release/ prefix (long term maintenance, branch from production)
○ bugfix branches → bugfix/ prefix (branch from and to release branches)
● Do not force push a public branch (public branch = a shared remote branch)
● Do not rebase a public branch
● Format your commit messages: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Git in the European Parliament

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Git in the European Parliament

Ähnlich wie Git in the European Parliament (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Git in the European Parliament

Hinweis der Redaktion