Slide 1

Git why using Git instead SVN1The answer is ... the way Git thinkVersion control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. The way Git think about source control as its data, states (repository (local and remotes), staging area, working), trees, branches, distributed model and implementing .2ContentThe snapshots Git The distributed Git Branches and mergeThe implementationThe repositoryThe staging area or the indexSupport to using parallel git and svn

3The snapshots GitThe major difference between Git and any other VCS (SVN, etc) is the way Git thinks about its data. - Scott Chacon.

Git is snapshot based, not patches or changes based.The snapshot Git (cont)There systems (CVS, SVN and so on) think of the information they keep as set of files and the change made to each file over time.

The snapshots Git

Unlike it, Git thinks of its data more like a set of snapshots of a mini file system.Takes a picture of what all your files look like, and stores a reference to that snapshot. Git doesnt store the file againjust a link to the previous identical file it has already stored.

The snapshots Git (cont)This is an important distinction and advance feature between Git and SVN.Git is very efficient in storing text files, and only storing these files that were changed.It makes Git more like a mini file system.It makes Git reconsider almost every aspect of version control.It makes Git branching to become magic feature of Git

7How Git store contentIt stores the repository in such a logical way, using far fewer files and much less disk space than SubversionEach file, no matter its location in the tree or history is only stored once. The repository is stored in a single .git folder at the top level of your working directory. Subversion needs a .svn folder inside each folder of the working directory.In SVN, the working directory holds two extra files for each file, plus some more file and folders for each directory. Git needs none of these.Its more efficient, dont need to make sure all your tools have special handling for the invisible .svn folders. 8The distributed GitSVN is a Centralized CVS. There is only a single repository to check out and check in source code. So, what happed is it if server is crashed or corrupted?It must work online or requires that you maintain a network connection to the central repository in order to track the changes that you make. What happed is it if it can't connect to internet ?Branching and merging is difficult. But you want work in new branch for test or try experiencing More management: all setting dependent on manager such as add new users, change pass, create project and so on.

It seems be disadvantage to you in some way.

With a server, the latest version is stored directly and can be retrieved quickly, where older versions must be recomputed by the server. Each changed, committed file is tracked separately with an independent revision identifier. This can make it difficult to discover which files have been changed by the commit when multiple changed files are committed. To counter this, users need to tag the repository state whenever a need exists to refer back and view the changes. - If several file were committed at once and the network dropped out, the commit would fall. And CVS administrator must resolve.- 9The distributed Git (cont)

Git is a Distributed CVS. It can resolve problems that meeting with SVN. Multiple BackupsYou do a clone of the entire repository, as copy of the repository. So, it will a backup for the main server when it need. And it only using command: git clone bare [add server/project]Local repository Each developer has their own copy of the repository. So, you can work offline:Can commit, merge, resolve conflict offlineMaking a change to your copy affects just your repository by commit your code.

Branching and merging is easy. Because every developer has their own branch, every shared change is like reverse integration. But the guilds make it easy to automatically combine changes and avoid duplicates.The distributed Git (cont)

Decentralized but centralized Centralized: all developers push to the same remote server. It is default called origin.Decentralized multi remote server : each developer may also pull changes from other peers to form sub teams. ( it neednt publish to main server) Any workflow: A centralized workflow; Integration Manager Workflow; Dictator and Lieutenants Workflow.

The distributed Git (cont)This advantage Gits featureMultiple shared repositoriesMultiple remote server.Gives the team leads an extra opportunity to review the code that was created by their team before sharing it with everyone else.Suitable for everyone: people coming to Git from a traditional centralized repository or who have never used version control or who are wanting to change completely.

Branching and mergingGit supports branching and merging far better than Subversion did:In Subversion, branches all are copies. Sometimes, it is easy to check out the whole repository by mistakeBranches are so core in Git because every developers working directory is itself a branch. They used every day by every user.Branch master consider trunk in SVN

Branching and merging in SVNCreate a branch:be placed under the /branches/ folder in the repository Generally, projects that take more than a day or two to complete should be considered for branching$ svn copy http://.../trunk http://.../branches/Mybranch -m comment hereSwitch a blanch$ mkdir /your/local/copy //if dont have a local copy$ cd /your/local/copy$ svn checkout http://.../branches/MyBranch . 15Merge branches with the trunk:Updating Your Branch The First TimeBring your local copy up to date: $ svn updateMerge from trunk to your branch: $ svn merge r[] url .Commit the merged changes back to your branch $ svn ci -m . Updating Your Branch More Than OnceUpdate your working copy of the branch : $ svn updateMerge trunk starting where the last merge left off: $ svn merge r [revision] url .Commit the merged changes back to your branch$ svn ci -m "" .Handling Branch Conflicts

Back to the trunk $ cd /your/local/copy$ svn updateAt revision 3400.$ svn switch http://.../branches/MyBranch $ svn merge -r3328:3400 http://.../branches/MyBranch .(MyBranch was created at revision number 3328)$ svn ci -m "branch back MyBranch into trunk" .Delete a branch$ svn del http://.../branches/MyBranch do you think SVN are more cumbersome?In Git, branching and merging is easy.

Create a branch $ git branch iss53Switch a branch$ git checkout iss53Back to master$ git checkout masterMerge with master (in iss53 branch)$ git rebase masterDelete a brach: $git branch d iss53

Do you think it is simply?

More advantage: easy staging temporary work. EX:

Easy staging temporary work.You are working in a branch. You need fix a bug in another branch or get o problem and want to try a new resolve. You can do:Stashing Temporary Work ( in branch A)$ git stashSwitch to another branches B$ git checkout BSwitch to branch A to resume work$ git checkout A$ git stash applyThe key thing to note is how we switch between branches.In Git, the repository handles this. With SVN, youre literally just working on a separate set of files.If you branch a lot, this quickly becomes annoying, time consuming, and non-productive. With Git, it magically changes all of the files on your file system for you. Git will float uncommitted changes. Did a git checkout B, bring all of the uncommitted work in A.But you dont need commit A. Instead, you stash your work.Using it will tuck away your WIP changes without a formal commit.The Subversion method is simpler, but you could potentially end up with several half-baked branches and no record of when you abandoned them. Stash is like a work in process commit. Using it will tuck away your WIP changes without a formal commit, which allows you to change to C without floating any of your A changes.22Merging in SVNIt's hardly to merge in a CVCS; therefore branches tend not to happenEasily get lost particularly when refactoring start happening, unless merge to HEAD frequently. The killer is not only do there include a bunch of changes already made from trunk. Changes that occurred in the past to trunk are now showing up again in the merge and SVN get very confused.Example:SVN: why doesnt it work? The simple reason is time, more specifically, order of changes.The first time you pull, you copy a set of changes. In the second time, depending on how attendant you are to start revisions, you may copy those changes again this is slightly problematical.Easily get lost particularly , all your tree is marked as changed, or files disappear, or changes are scrambled. Conflicts are marked where none should exists, and other changes are just gone.

23

This picture show the sequence of the changes to a single file in a repo. T0,T1,T3,T4 indicate points in time at which file is edited and is also the order in which the modification took place. This is important to SVN.When get to T5 and merge your branch into trunk, the sequence looks like: T1 already was in trunk, and was reapplied to the branch; T0 from the merge at T2;T4 was already in trunk then T3. So the order the merge tries to resolve is T1, T0, T4, T3. But, T1, T4 are already committed to trunk so just T1, T3. But since changes are in terms of the previous state of the file being changed, T3s modifications knew nothing about T4s modifications, so you are applying modifications out of order.Merging in GitMerging in Git is simplyEvery commit, git take a snapshot file and stores a reference to that snapshot. It is not only do you know what changes need to be made, but also what point in history they need to be made. So, Git will be able to apply the change and then play forward the changes.

Merging workflows

Git using the two snapshots pointed to by the branch tips and the common ancestor of the two.Instead of just moving the branch pointer forward, Git creates a new snapshot and automatically creates a new commit that points to it.This is referred to as a merge commit and is special in that it has more than one parent.So, by using a command: $ git merge [branch]It is easy to merge two branch with only resolve confict if having.

git merge iss5326The implementation SVNGitCentral repositoryRemote RepositoryServer ClientWorking directoryLocal RepositoryThe indexWorking directorycommitupdatefetchpushcommitaddcheckoutreset27The implementation SVNGitCentral repositoryRemote RepositoryServer ClientWorking directoryLocal RepositoryThe indexWorking directorycommitupdatefetchpushcommitaddcheckoutresetDifferenceDifference28RepositoryIn SVN, there is only a repository that called central repository, and is located in a server. Advantage: the projects source code always sync.Disadvantage: Might commit unfinished code to server that can make a lot of conflict and break your prorect. Cannot preview how projects code effect to if you dont commit your code.Difficult to try new feature or another resolve.Your work doesn't always finish in a short time and right way, does you?RepositoryGit have two repositories (remote and local) and two types repository as bare and non-bare.A "bare" repository contains the version control information, no working files It doesn't contain the special .git sub-directory.It cannot do any change in this repository. A remote repository is a bare repository.The repository has to be "bare" in order to accept a push. only use a "bare" repo to clone, pull from, and push to. A non-bare repository has working files and .git sub-directory.It can work in non-bare repository. A local repository is a non-bare repository.

RepositoryThe remote repository Git thing it only a place to share codeCan place any where or you have multi remote server.In normal, always have a remote repository to sync code of project The local repositoryCan work offline: commit code, merge code and resolve conflict.Only need network when sync source code with remote repository.Save your time when commit code.Easy try or test new way of resolve that dont break projects source code

The staging or index a great featureIt is a file named index on lies in local .git repository.St, you have code that you re not quite sure to commit but want to store. The staging is the place to store there files or take a snapshot there files by using command: $ git addThe main advantage of index is it can define exactly which changes to commit and which to leave for a later commit.Git does not force to use the staging feature. To directly going from the working directory to the local repository, using $ git commit -a m file.Easy to know what file are saved or not by using $ git status

The indexLet see this situation to understand the useful of the index.Suppose that, you start work on some an enhancements. After screwing around, you give up, leave the half-baked changes in my working copy. Then, you working again and have a problem. Using git status to see where your working is at and having some files changed but not updated such as a, b, c, d. have two unrelated changes in my working copy: a, b file are not ready commit and push into remote server and c, d file needs a commit immediately.The big problem here is c file it's "tangled" in the sense that it includes modifications from two different logical changes and need to tease these changes apart into two separate commits.

What does SVN resolve this problem?You should have committed the experimental changes to a separate branch before working on.Using Subversion, might go at it like this:Run svn diffRemove hunks from the diff and write the diff out to comment-stuff.diff.Run patch -p0 -R < comment-stuff.diff.Commit the bookmark related fixesRun patch -p0 < comment-stuff.diffForget to create branch for comment stuff, again.Hack on comment stuff for a while. Find more unrelated brokeness and fix it. Oops! GOTO a.What does Git resolve this problem?The index is more useful and become a great feature.$ git add --patch c.rb diff --git a/c.rb b/c.rb index be4159d..3efd4ce 100644 --- a/c.rb +++ b/c.rb @@ -256,7 +256,7 @@ Stage this hunk [y/n/a/d/j/J/k/K/s]?The magic is in the --patch argument the files specified on a hunk-by-hunk basis and lets choose one of options [y/n/a/d/j/J/k/K/s]Support using parallel Git and SVN You realize that in some side, Git is better than SVNYou want to using Git. But, your company, your co-dev are used to using SVN.

It is not a problemGit support using parallel Git and SVN with command$ git svnRetain SVNs features such as : centralized repository