Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in the manual
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Git Power Workshop for HiQ
Carl-Johan Sveningssonon 17 November 2014
Transcript of Git Power Workshop for HiQ
It's not the only one
( http://en.wikipedia.org/wiki/Comparison_of_revision_control_software )
Why a DVCS?
Revision control, also known as version control, source control or software configuration management (SCM) )
( http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work-the-final-question )
The git/kernel/gitworkflows(7) way
The nvie "A successful Git branching model" way
Do not mix merge and
The challenge is to define simple rules which developers can agree on / understand
( http://firstname.lastname@example.org/msg39091.html )
My question to the world:
"let people finish before you use their code"
So many branches (discouraged in hg)!
Supports code review
Pick and choose features for release
Requires a lot of discipline
Keep each branch linear
( make it default: http://d.strelau.net/post/47338904/git-pull-rebase-by-default )
$hg pull --rebase
$git pull --rebase
Enable extension in ~/.hgrc:
( from http://mercurial.selenic.com/wiki/RebaseProject )
Just two guys being busy in the same branch (from 24hbc):
It looks like a relay race... spaghetti!
Merge commits within the same branch
Unmanageable (for diff, log, rebase)
Just make it sequential instead, commit history is anyway topological more than chronological
The behavior when you fetch other's parallell commits
They hate each other, merge calculates required changesets, rebase or cherrypick duplicates them and /will/ create conflicts.
Use with caution, what you have rebased/cherry-picked in can never be merged in it's old shape again
Pick a standard and stick to it
Distributed includes centralized
Merge is not commutative
Though you can set up some fancy scheme yourself!
Mine (local only)
Mine (copied, rewritten)
( http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities )
Public / free hosting
(for git, but hg can convert transparently)
Is revolutionizing the open source ecosystem!
SSH / Network share
Patches / bundles
How to collaborate
(powered by CVS/subversion)
... we're not gonna get there today, sorry
With code review support, topic branch management etc.
"Subversion has been the most pointless project ever started"
Although not everyone agrees:
"CVS done right"
Centralized vs Distributed revision control
(or Distributed Version Control (Systems) (DVCS),
or Decentralized Version Control (Systems) )
Git can be anything!
Samba / NFS
Microsoft Word Track Changes
Wiki change histories
Wave protocol applications
( commutative is for example a+b = b+a , but a/b ≠ b/a )
Version Control commit quality may vary
Don't keep cruft/experiments in production
perpetual beta problem
stuff doesn't get maintained
The default deteriorates to flat chaos
My cry for help
The kernel way
The nvie way
Build quality in
Changing line endings
log - is something done right?
diff/patch - what's been changed?
blame - who did it?
... which is contrary to Contiuous Integration
Monolithic weekly commits...
... with stressed fixes, is trouble
Meaningful commits promote quality
What (version) is used?
Always functional - always testing
Enable code review
Playing around with directories/files
subversion bases revisions on directories
git/hg cannot work with directories
abstractions are different - integration in tools become different
(cannot choose branch?)
Give us VC in Google Docs / Wiki!?
Editors proposed changes as patches,
based on my document, not each other,
makes a lot more sense!
This is the topic of application-aware
diff/patch, this could be pluggable but not simple
Because diff is line-based, it completely breaks the log
DVCS in combination with TDD:
... you might as well go crazy
Git Power Workshop
Why... what... git?
Everything is a branch!
[shoot yourself in foot]
You need rules
My favorite recipes
Download and install windows msysgit
Disable CR/LF conversion
Choose to use OpenSSH (at home I prefer Putty)
Why... what... git?
Why: Distributed Version Control System
What: DVCS by Linus Torvalds
To build quality in
For release management
Keeping track of what happens
Distributed for flexibility
Distributed for flexibility
Git is a DVCS by Linus Torvalds
What is Git?
Distributed Version Control System
Object-based, not diffs
Repositories, not directories
Everything is a branch (in a graph)
It's all graph manipulation
All your branch are belong to Git
Rules / Workflows / WoW to make it work
Shooting your foot with git
Deploy website changes using git (using hook scripts)
Subversion with Git frontend without asking anyone for permission: