5分钟学会git (svn基础)[zt]

kidys

5分钟学会git (svn基础)　　http://www.linuxfans.org/bbs/thread-171291-1-8.html
　　git是核心，cogito是它的一个包装，可以使得git更容易使用。
　　和SVN的常用命令对照
　　The Cogito commands are in the form cg command, the Git commands take t
　　he form of git command. In both cases, you can interchangeably use the c
　　g-command and git-command form as well.
　　Cogito can produce colourful output with some commands; since some peop
　　le hate colors way more than the rest likes them, by default the colors
　　are turned off. If you would like to have colors in your output, create
　　~/.cgrc and put this inside:
　　cg-diff -c
　　cg-help -c
　　cg-log -c
　　The format and purpose is the same as of the ~/.svnrc file; you can add
　　other commands and switches there later if you wish (my tip is -f for c
　　g-log).
　　Also, you may find it convenient to watch your repository using the git
　　k repository as you go.
　　Your Very Own
　　For the first introduction, let's make your project tracked by Git and
　　see how we get around to do daily development in it. Let's cd to the dir
　　ectory with your project and initialize a brand new Git repository with
　　it:
　　cg init       svnadmin create repo
　　svn import file://repo
　　cg init will both initialize the repository and create the initial impo
　　rt, given that repositories are coupled with working copies.
　　Now your tree is officially tracked by Git. You can explore the .git su
　　bdirectory a bit if you want, or don't if you don't care. Do some random
　　changes to your tree now - poke into few files or such. Let's check wha
　　t we've done:
　　cg diff svn diff | less
　　That's it. This is one of the more powerful commands; just like with SV
　　N, you can pass -rs, limit the diff to specific directories or files and
　　so on. Git embeds special information in the diffs about adds, removals
　　and mode changes:
　　cg patch    patch -p0
　　That will apply the patch while telling Git about and performing those
　　"meta-changes".
　　There is a more conscise changes representation available:
　　cg status   svn status
　　This will show the conscise changes summary as well as list any files t
　　hat you haven't either ignored or told Git about. In addition, it will a
　　lso show some cryptic line at the top (with "master" inside) - ignore it
　　for now, we'll learn more about it later.
　　While we are at the status command, over time plenty of the "? lines" w
　　ill get in there, denoting files not tracked by Git. Wait a moment if yo
　　u want to add them, run cg clean if you want to get rid all of them, or
　　add them to the .gitignore file if you want to keep them around untracke
　　d (works the same as .svnignore).
　　Somewhat out of order, one thing svn update would do is restoring files
　　you've accidentally removed. The command for that in Cogito is cg resto
　　re; you can restore everything, just specified files, force it to overwr
　　ite missing files.
　　So, just like in SVN, you need to tell Git when you add, move or remove
　　any files:
　　cg add file
　　cg rm -f file
　　cg mv file    svn add file
　　svn rm file
　　svn mv file
　　Cogito is more promising than SVN here; especially, you can keep files
　　that are yet present in the working directory (cg rm can remove them for
　　you if you pass it the -f switch) - saves a lot of annoyance when remov
　　ing files matching to a wildcard. You can also recursively add/remove wh
　　ole directories and so on; Cogito's cool!
　　So, it's about time we committed our changes. Big surprise about the co
　　mmand:
　　cg commit   svn commit
　　As with Subversion, you can limit the commit only to specified files an
　　d so on. Few words on the commit message: it is customary to have a shor
　　t commit summary as the first line of the message, because various tools
　　listing commits frequently show only the first line of the message You
　　can specify the commit message using the -m parameter as you are used, b
　　ut there're two differences - the text gets autoformatted to paragraphs
　　and you can pass several -m arguments and they will create separate para
　　graphs in the commit message:
　　cg commit -m"Short one-line description" -m"And here can come \
　　your longer description of the commit, and it gets split out \
　　and reflown to wrapped paragraphs just right."
　　If you don't pass any -m parameter or pass the -e parameter, your favor
　　ite $EDITOR will get run and you can compose your commit message there,
　　just as with Subversion. In addition, the list of files to be committed
　　is shown and you can actually delete lines with the files you don't want
　　to commit and they won't be. You can also adjust the authorship informa
　　tion in the editor.
　　And as a bonus, if you pass it the -p parameter it will show the whole
　　patch being committed in the editor so that you can do a quick last-time
　　review. And you can manually modify the patch and your changes will get
　　propagated to the commit (and your working tree).
　　By the way, if you screwed up committing, there's not much you can do w
　　ith Subversion, except using some enigmatic svnadmin subcommands. Git do
　　es better - you can amend your latest commit (re-edit the metadata as we
　　ll as update the tree) using cg commit --amend, or toss your latest comm
　　it away completely using cg admin-uncommit.
　　Now that we have committed some stuff, you might want to review your hi
　　story:
　　cg log
　　cg seek rev
　　git blame file    svn log | less
　　svn checkout -r tag
　　svn blame file
　　The log command works quite similar in SVN and Git; again, cg log is qu
　　ite powerful, please look through its options to see some of the stuff i
　　t can do.
　　To move your tree to some older revision, use the seek command (and pas
　　s it no arguments to go back to your latest revision_. Note that this is
　　only for "temporary excursions" - if you want to just reset your histor
　　y and make a given commit your new head, think again and if you are sure
　　, cg switch -f -r newrev master (this will be perhaps made simpler in th
　　e future, we will review the switch command in more detail in the future
　　).
　　Git now has an annotation command akin to Subversion's, but there are b
　　ig chances that you probably want to do something different! Usually, wh
　　en using annotate you are looking for the origin of some piece of code,
　　and the so-called pickaxe of Git is much more comfortable tool for that
　　job (detailed discussion; you may want to use cg log -S string instead o
　　f git log -Sstring, tho').
　　Tagging and branching
　　Subversion marks certain checkpoints in history through copies, the cop
　　y is usually placed in a directory named tags. Git tags are quite more p
　　owerful. The Git tag can have an arbitrary description attached (the fir
　　st line is special as in the commit case), some people actually store th

　　e whole>
　　he person who tagged is stored (again following the same rules as>　　ty of the committer). You usually tag commits but if you want, you can t
　　ag files (or trees, but that's a bit lowlevel) as well. And the tag can

　　be cryptographically PGP signed to verify the>　　of working, that signature also confirms the validity of the associated
　　revision, its history and tree). So, let's do it:
　　cg tag name svn copy http://example.com/svn/trunk http://example.com/sv
　　n/tags/name
　　To list tags in Subversion, you could run svn list http://example.com/s
　　vn/tags. In Git, you can find out using cg tag-ls and show details (auth
　　or, description, PGP signature verification, ...) using cg tag-show.
　　Like Subversion, Git can do branches (surprise surprise!). In Subversio
　　n, you basically copy your project to a subdirectory. In Git, you tell i
　　t, well, to create a branch.
　　cg switch -c branch
　　cg switch branch    svn copy http://example.com/svn/trunk http://example.c
　　om/svn/branches/branch
　　svn switch http://example.com/svn/branches/branch
　　The first command creates a branch, the second command switches your tr
　　ee to a certain branch. You can pass an -r argument to switch to base yo
　　ur new branch on a different revision than the latest one.
　　You can list your branches conveniently using the aforementioned cg-sta
　　tus command - the cryptic listing at the top is just the listing of bran
　　ches. The current one is denoted by an "arrow".
　　Git supports merging between branches much better than Subversion - his
　　tory of both branches is preserved over the merges and repeated merges o
　　f the same branches are supported out-of-the-box. Make sure you are on o
　　ne of the to-be-merged branches and merge the other one now:
　　cg merge branch (assuming the branch was created in revision 20 and you
　　are inside a working copy of trunk)
　　svn merge -r 20:HEAD http://example.com/svn/branches/branch
　　If changes were made on only one of the branches since the last merge,
　　they are simply replayed on your other branch (so-called fast-forward me
　　rge). If changes were made on both branches, they are merged intelligent
　　ly (so-called three-way merge): if any changes conflicted, cg merge will
　　report them and let you resolve them, updating the rest of the tree alr
　　eady to the result state; you can cg commit when you resolve the conflic
　　ts. If no changes conflicted, cg commit is invoked automatically, lettin
　　g you edit the commit message (or you can do cg merge -n branch to revie
　　w the merge result and then do the commit yourself).
　　Sometimes, you do want to throw away the history of one of the branches
　　, e.g. when you did a fine-tracked development of a topic and now want t
　　o squash it to a single conceptual change commit - just pass merge the -
　　-squash switch. Also, sometimes you may want to join together two unrela
　　ted branches (coming from different projects; hold on, we'll get to that
　　in a minute): -j will take care of that.
　　Aside of merging, sometimes you want to just pick one commit from a dif
　　ferent branch. We have already mentioned the command cg patch. It can ap
　　ply patches, but also autocommit them and extract them from given commit
　　s. cg patch -C rev combines both functionality and will cherry pick a gi
　　ven commit to your branch.
　　Going Remote
　　So far, we have neglected that Git is a distributed version control sys
　　tem. It is time for us to set the record straight - let's grab some stuf
　　f from remote sites.
　　If you are working on someone else's project, you usually want to clone
　　its repository instead of starting your own. We've already mentioned th
　　at at the top of this document:
　　cg clone url    svn checkout url
　　Now you have got your master branch as when initializing a new reposito
　　ry, but in addition you got an origin remote branch. Remote branch, you
　　ask? Well, so far we have worked only with local branches. Remote branch
　　es are a mirror image of branches in remote repositories and you don't e
　　ver switch to them directly or write to them. Let me repeat - you never
　　mess with remote branches. If you want to switch to a remote branch, you
　　need to create a corresponding local branch which will "track" the remo
　　te branch. In clone's default setup, the master local branch tracks the
　　origin remote branch, which represents the remote repository.
　　You can add more remote branches, to a cloned repository as well as jus
　　t an initialized one, using cg branch-add branch url. cg branch-ls lists
　　all the branches.
　　Now, how to get any new changes from a remote repository to your local
　　branch? You fetch them: cg fetch branch. At this point they are in your
　　local branch and you can examine them using cg log -r branch (cg log -r
　　HEAD..branch to see just the changes you don't have in your branch), dif
　　f them, and obviously, merge them - just do cg merge branch. Note that i
　　f you don't specify a branch for fetch or merge, it will conveniently de
　　fault to origin.
　　Since you frequently just fetch + merge, there is a command to automate
　　that:
　　cg update branch    svn update
　　Again, it will default to origin if no branch was specified. It is reco
　　mmended to use update instead of fetch + merge since it does the first t

　　hing even if the remote branch' history got>
　　son why>　　So we can get updates from the remote side (pull changes). Can we do th
　　e opposite as well? Push our changes? Yes! We do cg push branch which wi
　　ll push our current branch to the given remote branch - note that this w
　　orks generally only over SSH (or HTTP but with special webserver setup).
　　It is highly recommended to setup a SSH key and an SSH agent mechanism
　　so that you don't have to type in a password all the time.
　　One important thing is that you should push only to remote branches tha
　　t are not currently checked out on the other side (for the same reasons
　　you never switch to a remote branch locally)! Otherwise the working copy
　　at the remote branch will get out of date and confusion will ensue. The
　　best way to avoid that is to push only to remote repositories with no w
　　orking copy at all - so called bare repositories which are commonly used
　　for public access or developers' meeting point - just for exchange of h
　　istory where a checked out copy would be a waste of space anyway. You ca
　　n create such a repository using cg admin-setuprepo path - you can add a
　　dditional options to make it shared for a UNIX group of users.
　　Git can work with the same workflow as Subversion, with a group of deve
　　lopers using a single repository for exchange of their work - the only c
　　hange is that their changes aren't submitted automatically but they have
　　to push (however, you can setup a post-commit hook that will push for y
　　ou every time you commit; that loses the flexibility to fix up a screwed
　　commit, though). The developers have to have either an entry in htacces
　　s (for HTTP DAV) or a UNIX account (for SSH) - you can restrict their sh
　　ell account only to Git pushing/fetching by using the git-shell login sh
　　ell.
　　You can also exchange patches by mail. Git has very good support for pa
　　tches incoming by mail. You can apply them by feeding mailboxes with pat
　　ch mails to cg patch -m. If you want to send patches (or a third-party c
　　hanges to an upstream repository with no commit access in general), it i
　　s best to use the StGIT tool - see the StGIT Crash Course).
　　If you have any question or problem which is not obvious from the docum
　　entation, please contact us at the Git mailing list at git@vger.kernel.o
　　rg. We hope you enjoy using Git and Cogito!
　　--
　　I come from the past to save the future~~~
　　[m [1;31m※ 来源:·浙江大学海纳百川站 bbs.zju.edu.cn·[FROM: 10.214.18.21] [m