From e689e8146b9ff1b06aa95787168516f66443af28 Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Sat, 1 Sep 2007 12:19:16 -0700 Subject: [PATCH] Moved some secions from basic.txt to clone.txt New tricks in basic.txt --- basic.txt | 74 +++++++++++++++++++++++++++++++++++++++++++++++--------------- branch.txt | 2 +- clone.txt | 33 ++++++++++++++++++++++++++-- intro.txt | 4 ++-- 4 files changed, 90 insertions(+), 23 deletions(-) diff --git a/basic.txt b/basic.txt index 1968e6c..84fb9b6 100644 --- a/basic.txt +++ b/basic.txt @@ -2,15 +2,18 @@ Rather than diving into a sea of Git commands, use these elementary examples to get your feet wet. Despite their simplicity, each of them are useful in real life. -== Instant Backup == +== Saving State == When I'm about to attempt something drastic I like to save the current state, so I can go back and try again should things go awry. - $ git-init + $ git-init-db # for git-1.5 and up you can type "git-init" instead $ git-add . $ git-commit -m "my first backup" to take a snapshot of all files in the current directory. + +The above sequence of commands should be memorized, or placed in a script, as they will be reused frequently. + Then if something goes wrong type $ git-checkout HEAD . @@ -19,7 +22,7 @@ to go back to where you were. To save the state again, you can type $ git-commit -a -m "another backup" -=== Adding, Deleting, Renaming Files === +=== Add, Delete, Rename === The above will only keep track of the files that were present when you first ran git-add. If you add new files to the directory, you'll have to tell Git: @@ -35,12 +38,16 @@ Renaming a file is the same as removing the old name and adding the new name. Th == Advanced Undo/Redo == -Typing git-log shows you a list of recent commits, and their SHA1 hashes. Then typing: +Running: + + $ git-log + +shows you a list of recent commits, and their SHA1 hashes. Then: $ git-checkout SHA1_HASH . will load the previous state with the given hash. -Don't like working with hashes? Then use: +Don't like cutting and pasting hashes? Then use: $ git-checkout "@{10 minutes ago}" . @@ -61,27 +68,58 @@ Lastly, other times you might want: which restores the state to a given commit but also erases all newer commits from the record permanently. -To take the computer game analogy again, git-checkout is like loading a game, git-revert is like loading a game and recording this fact as another saved game, and git-reset --hard is like loading an old save and deleting all saved games newer than the one just loaded. +To take the computer game analogy again, git-checkout is like loading a game, git-revert is like loading a game and recording this fact as a new saved game, and git-reset --hard is like loading an old save and deleting all saved games newer than the one just loaded. -== Sync Computers == +== Dowloading Files == -This is the reason I first used Git. I can tolerate making tarballs or using rsync for backups. The problem was sometimes I'd edit on my laptop, other times on my desktop, and they may not have talked to each other in between. +If a project uses Git to manage its files, you can get a copy with: -Initialize a Git repository and commit your files as above on one machine. Then on the other: + $ git-clone server:/path/to/files - $ git-clone git+ssh://other.computer/directory +We'll have a lot more to say about the clone command later. -to get a second copy. From now on, +== Keeping Up-to-date == - $ git-commit -a - $ git-pull git+ssh://other.computer/directory +If a project uses Git to manage its files, and you've already downloaded a copy using git-clone, you can upgrade to the latest released version with: + + $ git-pull + +== Instant Publishing == + +Let's say you've written a script you'd like to share with others. You could just tell them to download from your computer, but if they do so while you're improving the script or making experimental changes, they'll get a bad version. + +Of course, this is why release cycles exist. Code is written, and at certain points in time, when it's suitable for others, it gets released. + +To do this with Git, in the directory where your script resides: + + $ git-init-db # in git-1.5 just type git-init + $ git-add . + $ git-commit -m "first release" + +Then tell your users to type + + $ git-clone your.computer:/path/to/script + +to download your script. From now on, every time your script is ready for release, type: + + $ git-commit -a -m "next release" + +and your users can upgrade their version by changing to the directory containing your script and typing. + + $ git-pull + +Your users will never wind up with a version of your script you don't want them to see. Obviously this trick works for anything, not just scripts. + +== What Have I Done? == + +Find out what changes you've made since the last commit with: -will pull in the state of the files on the other computer into the one you're working on. If you've recently made conflicting edits in the same file, Git will let you know and you should resolve them with another edit and commit. + $ git-diff -If you have not committed any changes on the other computer, you may type +Or since yesterday: - $ git-push git+ssh://other.computer/directory + $ git-diff "@{yesterday}" -to push the current state to the other computer. Next time you're there, run git-reset --hard or git-checkout HEAD . to update the files. +Or between a particular version and 2 versions ago: -That Git does not do the last step automatically is good in case you were in the middle of some uncommitted changes. + $ git-diff SHA1_HASH "@{2}" diff --git a/branch.txt b/branch.txt index a4508fc..46c5afb 100644 --- a/branch.txt +++ b/branch.txt @@ -35,7 +35,7 @@ Some projects require your code to be reviewed before you can submit it. To make What if the second part cannot be written until the first part is approved and checked in? In many version control systems, you'd have to send the first part to the reviewers, and then wait until it has been approved before starting on the second part. -Actually that's not quite true, but in many systems editing part 2 before part 1 had been submitted involves a lot of suffering and hardship. In Git, branching and merging are painless. So after you've committed the first part and sent it for review: +Actually that's not quite true, but in many systems editing part 2 before part 1 has been submitted involves a lot of suffering and hardship. In Git, branching and merging are painless. So after you've committed the first part and sent it for review: $ git checkout -b part2 diff --git a/clone.txt b/clone.txt index 3e43a22..356bca4 100644 --- a/clone.txt +++ b/clone.txt @@ -1,5 +1,34 @@ = Cloning Around = +In older version control systems, checkout was the standard way to get a saved state. On checkout, you'd get a bunch of files in the requested saved state. + +In Git, the standard way to get files is to create a clone of the entire repository. In other words, you practically create a mirror of the central repository, so you can do anything the central repostiory can do. + +== Sync Computers == + +This is the reason I first used Git. I can tolerate making tarballs or using rsync for backups. The problem was sometimes I'd edit on my laptop, other times on my desktop, and they may not have talked to each other in between. + +Initialize a Git repository and commit your files as above on one machine. Then on the other: + + $ git-clone other.computer:/path/to/files + +to create a second copy of the files and Git respository. From now on, + + $ git-commit -a + $ git-pull other.computer:/path/to/files + +will pull in the state of the files on the other computer into the one you're working on. If you've recently made conflicting edits in the same file, Git will let you know and you should commit again after resolving them. + +If you have not committed any changes on the other computer, you may type + + $ git-push other.computer:/path/to/files + +to push the current state to the other computer. Next time you're logged in to the other computer, run + + $ git-checkout HEAD . + +to update the files before working on them. Be aware that you'll lose any uncommitted changes after. + == Classic Source Control == Copy your project to a directory in your main server. Initialize a Git @@ -7,7 +36,7 @@ repository: git init ; git add . ; git commit -m "Initial commit". To check out source, a developer types - $ git clone git+ssh://main.server/directory + $ git clone main.server:/path/to/files After making changes, the code is checked in to the main server by: @@ -25,7 +54,7 @@ Sick of the way a project is being run? Think you could do a better job? First, on your server: - $ git clone git+ssh://main.server/directory + $ git clone main.server:/path/to/files Then tell everyone to check out your fork of the project at your server. diff --git a/intro.txt b/intro.txt index 692e196..30e9e38 100644 --- a/intro.txt +++ b/intro.txt @@ -21,7 +21,7 @@ In some computer games, saving the game actually writes a directory full of file This turns out to be a basic capability of all version control systems. They all have nice interfaces to manage a directory of stuff. You can save its state every so often, and be able to load any one of the saved states later on. They're also smart about using space, by exploiting the fact that only a few of the files usually change between version to version. -== Centralized Versus Distributed == +== Distributed Control == Now imagine a very difficult computer game. So difficult to finish that many experienced gamers all over the world decide to team up and share their saved games to try to beat it. Real-life examples of this include doing speedruns of certain games. Players specializing in different levels of the same game collaborate to produce amazing results. @@ -35,7 +35,7 @@ There could be many reasons to want to see an older revision, but the outcome is The new generation of version control systems, of which Git is a member, are known as distributed systems, and can be thought of as a generalization of centralized systems. When players download from the main server they get every saved game, not just the latest one. It's as if they're mirroring the central server. -Thus the initial cloning can be expensive, especially if there's a long history, but it pays off in the long run. One immediately obvious benefit is that when an old save is desired for any reason, communication with the central server is unnecessary. +This initial cloning operation can be expensive, especially if there's a long history, but it pays off in the long run. One immediate benefit is that when an old save is desired for any reason, communication with the central server is unnecessary. == Merge Conflicts == -- 2.11.4.GIT