Git vs cvs ece2011

1 Git from a different (CVS/SVN) perspective Christian Campo EclipseCon Europe 2011 Confidential | Date | Other Information, if necessaryNovember 7, 2011 © 2002 IBM Corporation Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0

Git vs CVS vs SVN Git • commits like db transactions • commits linked in a hierarchy • commits contains for a collection of files • decentral repo CVS • commits are unrelated file diffs • central repo SVN • commits are file diffs • commit file diffs can be linked with a common revision • central repoCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 3

Git Promises/Claims  you get your own local repository  you can commit even offline (in an airplane)  branching is easy and no longer an unusual task but part of your everyday workflow and its so much easier with Git  you hated merging with CVS (SVN) ? you are going to love it with Git  Git is fast and easy  you cant run an open source project without GitCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 4

Git promises from the CVS angle  you never wanted a local repository  you hate toonly checkout a wholecommit in an airplane (modules) • you can fly and therefore never repo with all projects • you Internet now officially of the last 1-5  you hate branches andhistory everywhere ? years • isnt get the whole actually never create them yourself • and even if you are offline, just write code for a change • and all branches • your release engineer does that  you have a different definition of merge, if two people modify • so now you should MERGE. unrelated files thats NOcreate branches ? NO way • branches isnt that like a fork ?  Git is fast ! but not easy  successful open source only requires Git....seriously ? • no javadoc • no unit tests • no clean code • no integration tests • JUST Git ??Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 5

Git is giving words/things a new meaning  commit does not mean everybody can see your code  merge happens even if you edit unrelated files  first commit THAN merge THAN possibly commit again ??  and then....the merge commit is empty ? (has no diff)  repository is not one central thing on the server but everyone has one  branches on client and server can have different names  its ok if two repos dont carry the same branches/tagsCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 6

CVS has a real Synchronize  Synchronize shows me the list of incoming and outgoing changes on file level  helps to not check in stuff that I dont intent to  often people check incoming changes on a detailed level  helps to understand what other people changed  refactor stuff that seems wrong  check typos :-)  improves the quality of the code  update is done step by step like kind of a to-do-list  there is Synchronize in Git, but you can not incrementally update (because of the concept of Git)Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 8

Things only CVS can do  you can tag projects independant as you go  you can tag single files later  selectivly update only some projects  NOT resolve conflicts when you update (i.e. a xx.launch file that you changed)Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 9

CVS Usage is NOT problem free  If you branch you almost never merge (because its so hard)  it was always complicated to figure out what was changed for a certain changeset ?  A "changeset" are merely commits with the same message so it is easy to amend a commit :-)  did you ever tag before and after a commit to log the difference ?  if you develop in HEAD and a version branch und later you have to copy changesets from HEAD to the version branchCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 10

More CVS crap  Refactoring (renaming a class) means loosing all your history  Renaming a package, project means loosing all history of all objects in that package/project  If you delete a project it does not get deleted at your collegues workspace committer unless you TELL him. (and he deletes it manually)  If you add a project your collegues wont find out until you TELL them.Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 11

And you come to Git...  And people tell you.... the easiest way to use Git is the command line  however the command line is way better than you expect  it was created to actually work with it on a daily baseCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 12

Pitfalls in Git  you try to pull before you committed your changes  you push .... EVERYTHING (including all local branches)  you create a new project in the root of the Git Repository directoryCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 14

Pitfalls in Git II  Merge conflicts are a little more complicated  CVS flags the conflict  Git Pull actually puts a comment in the file (so that it doesnt compile)  Rebases can be scary (rerunning commits on a different branch and hoping that the commits also work there)  Merge conflicts in the middle of a rebase even more  You always have to update everything (no way to exclude a bundle or a file)Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 15

More stuff...  CVS users moving to Git think that Git is the solution to everything they missed in CVS  yes moving content between files means that Git still can keep track of the history  try to rename a bundle (just for fun) and then look at the proposed commit (there is “git mv” though)  you hear that the Git repo of the Eclipse platform was corrupted by a single committer (Is Git the right move for me ?)Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 18

Where Git is better than CVS (the centerpiece)  commits  changes collected together in one metaobject called commit  put more effort in creating a good commit  amend a commit if wrong, dont just add a second (like in CVS)  make smaller commits  commits should be a "unit-of-work" useful by itself  a good history is the key to using Git  only Git commits truely show which modifications where committed together  there is no commit in CVS !!! Its just writing a collection of diffs..Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 20

Things only Git can do  Pick some commits from one branch into another (cherrypicking)  Revert commits  Merge branches (and that actually works :-) )  Rebase your local changes on top of the server master  Work on commits in the past  Tag them  Branch from them  Sign them  Reset your workspace to that time in history  If you manually undo the changes in a file it automagically shows the file as unmodified.Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 21

Things only Git can do  develop multiple features in parallel without checking-into-the-server- repo  stash your current work, while you do something else and then come back to your work in progress  commit only parts of the changes in a file  freeze a state of your files before they are committed (staging area)Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 22

Git is confusing at times  It uses names that CVS uses, but means something different  commit, merge, repo  local tracking branches can have a strategy  git history can be confusing and complicatedCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 23

Summary  Dont treat Git as if it were CVS.  Getting from CVS to Git  requires you to "re-wire" your brain  get used to a new way of doing things  adapt your way of doing things to retain your workflow as much as possible  Symptoms are similar to learning any kind of new technology  remember XML, Javascript, Objective-C, Modeling, XText, Tycho  Git opens the door for better collaboration and contribution from othersCopyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0 25

Git vs cvs ece2011

by da152

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Git vs cvs ece2011 Presentation Transcript