- 浏览: 796879 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (651)
- Java (39)
- Java 初学者小问题 (66)
- 设计模式 (7)
- 项目管理 (3)
- 数据库 (1)
- 算法 (2)
- Java practices (6)
- Effective Java2读书笔记 (78)
- Linux (2)
- programming ruby 读书笔记 (5)
- Core Java Ninth Edition Volume I 读书笔记 (15)
- Pro Git 读书笔记 (12)
- Git (3)
- Maven in Action 读书笔记 (20)
- Web (12)
- 非技术类书籍 (11)
- 电影 (40)
- Web Cache (1)
- jquery (0)
- 历史 (4)
- Dive Into HTML5 读书笔记 (13)
- 三国演义小学毕业考 (79)
- 高效能人士的7个习惯 读书笔记 (12)
- Java Performance 读书笔记 (3)
- Protocol Buffer 学习笔记 (6)
- Mongo DB 学习笔记 (7)
- Morphia 学习笔记 (7)
- Algorithms -- Princeton 学习笔记 (13)
- String研究 (10)
- Hadoop: The Definitive Guide 读书笔记 (3)
- Java与模式读书笔记 (5)
- Date研究 (3)
- The Roman Empire 听课笔记 (4)
- Algorithms -- Standford 学习笔记 (16)
- Core Java Ninth Edition Volume II 读书笔记 (9)
- Thinking in Java 4th Edition 读书笔记 (21)
- Node : Up and Running 学习笔记 (5)
- Eloquent Javascript (8)
- Smashing Node.js 读书笔记 (1)
- Algorithms II -- Standford 学习笔记 (19)
- Algorithm II -- Princeton 学习笔记 (14)
- 网络安全 (2)
- Javascript (4)
- 正则表达式 (1)
- JAVA 7/8 (15)
- JVM (10)
- NodeJS (1)
- 鸟哥的linux私房菜读书笔记 (14)
- Web Service (1)
- The art of programming (9)
- Introduction to Algorithm 读书笔记 (4)
- Java 源码阅读 (0)
- Spring in Action 读书笔记 (2)
- Java Network Programming 读书笔记 (2)
最新评论
-
心存高远:
谢谢作者分享,刚好看到这里不太明白,现在茅塞顿开。不过runt ...
关于 Maven的传递依赖的理解 -
sxlkk:
851228082 写道甚至在某次技术会议现场遇到《Maven ...
关于 Maven的传递依赖的理解 -
851228082:
851228082 写道a----compile----b-- ...
第五章 坐标和依赖 -
851228082:
a----compile----b-----provided- ...
第五章 坐标和依赖 -
851228082:
甚至在某次技术会议现场遇到《Maven in action》的 ...
关于 Maven的传递依赖的理解
1. You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.
2. If you're starting to track an existing project in Git, you need to go to the project's directory and type:
$ git init
This command creates a new subdirectory named .git that contains all of your necessary repository files—a Git repository skeleton. At this point, nothing in your project is tracked yet.
3. If you want to start version-controlling existing files, you should probably begin tracking those files and do an initial commit:
$ git add *.c
$ git add README
$ git commit -m 'initial project version'
4. If you want to get a copy of an existing Git repository, You clone a repository with git clone [url] :
$ git clone git://github.com/schacon/grit.git
That creates a directory named grit , initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you want to clone the repository into a directory named something other than grit , you can specify that as the command-line option.
5. Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run git clone .
6. Git has a number of different transfer protocols you can use. You can use git:// protocol and http(s):// or user@server:/path.git , which uses the SSH transfer protocol.
7. Each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot(or newly added to the staging area); they can be unmodified, modified, or staged. Untracked files are everything else—any files in your working directory that weren't in your last snapshot and aren't in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything. As you edit files, Git sees them as modified, because you've changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats.
8. The main tool you use to determine which files are in which state is the git status command.
9. In order to begin tracking a new file, you use the command git add :
$ git add README
If you run the git status command again, you can see that your README file is now tracked and staged. You can tell that it's staged because it's under the "Changes to be committed " heading. If you add a directory, the command adds all the files in that directory recursively.
10. If you change a previously tracked file called benchmarks.rb and then run the git status command again, The benchmarks.rb file appears under a section named "Changed but not updated "—which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the git add command.
11. It turns out that Git stages a file exactly as it is when you run the git add command. If you modify a file after you run git add , you have to run git add again to stage the latest version of the file, otherwise when you run git commit , the version of the file as it was when you last ran the git add command is how it will go into the commit.
12. You'll have a class of files that you don't want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file named .gitignore listing patterns to match them:
$ cat .gitignore
*.[oa]
*˜
The first line tells Git to ignore any files ending in .o or .a—object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (˜).
13. The rules for the patterns you can put in the .gitignore file are as follows:
1) Blank lines or lines starting with # are ignored.
2) Standard glob patterns work.
3) You can end patterns with a forward slash (/ ) to specify a directory.
4) You can negate a pattern by starting it with an exclamation point (!).
Glob patterns are like simplified regular expressions that shells use.
# a comment - this is ignored
*.a # no .a files
!lib.a # but do track lib.a, even though you're ignoring .a files above
/TODO # only ignore the root TODO file, not subdir/TODO
build/ # ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt
14. To see what you've changed but not yet staged, type git diff with no other arguments. That command compares what is in your working directory with what is in your staging area.
15. If you want to see what you've staged that will go into your next commit, you can use git diff --cached . (In Git versions 1.6.1 and later, you can also use git diff --staged , which may be easier to remember.) This command compares your staged changes to your last commit.
16. Anything that is still unstaged—any files you have created or modified that you haven't run git add on since you edited them—won't go into this commit. They will stay as modified files on your disk.
17. The simplest way to commit is to type git commit . Doing so launches your editor of choice to edit your commit message. (This is set by your shell's $EDITOR environment variable, although you can configure it with git config ) The default commit message contains the latest output of the git status command commented out and one empty line on top. You can pass the -v option to git commit . Doing so also puts the diff of your change in the editor so you can see exactly what you did. Alternatively, you can type your commit message inline with the commit command by specifying it after a -m flag.
18. Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later.
19. Providing the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add part.
20. The git rm command removes a file from your staging area and also removes it from your working directory so you don't see it as an untracked file next time around. If you simply remove the file from your working directory, it shows up under the "Changed but not updated" (that is, unstaged) area of your git status output.
21. If you modified the file and added it to the index (staged area) already, you must force the removal with the -f option. This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git.
22. To keep the file on your hard drive but not have Git track it anymore:
$ git rm --cached readme.txt
23. You can pass files, directories, and file-glob patterns to the git rm command:
$ git rm log/\*.log (removes all files that have the .log extension in the log/ directory.)
$ git rm \*˜ (removes all files that end with ˜ )
24. Git has a mv command. If you want to rename a file in Git, you can run something like:
$ git mv README.txt README
this is equivalent to running something like:
$ mv README.txt README
$ git rm README.txt
$ git add README
Git figures out that it's a rename implicitly. If you run something like this and look at the status, you'll see that Git considers it a renamed file.
25. git log can help you to view the existing commit history. By default, with no arguments, git log lists the commits made in that repository in reverse chronological order.
26. A huge number and variety of options to the git log command are available:
1) options -p shows the diff introduced in each commit. You can also use −2 , which limits the output to only the last two entries.
2) --stat option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
3) --pretty option changes the log output to formats other than the default. –pretty= oneline option prints each commit on a single line. –pretty=short , full , and fuller options show the output in roughly the same format but with less or more information, respectively. --pretty format allows you to specify your own log output format:
$ git log --pretty=format:"%h - %an, %ar : %s"
Formatting Options for the git log pretty Output
|
|
Option |
Description of Output |
%H |
Commit hash |
%h |
Abbreviated commit hash |
%T |
Tree hash |
%t |
Abbreviated tree hash |
%P |
Parent hashes |
%p |
Abbreviated parent hashes |
%an |
Author name |
%ae |
Author e-mail |
%ad |
Author date (format respects the -date = option) |
%ar |
Author date, relative |
%cn |
Committer name |
%ce |
Committer e-mail |
%cd |
Committer date |
%cr |
Committer date, relative |
%s |
Subject |
The oneline and format options are particularly useful with another log option called --graph . This option adds a nice little ASCII graph showing your branch and merge history, in which you can see your copy of the Grit project repository.
27. Common git log Output Formatting Options:
28. The time-limiting options such as --since and --until are very useful:
$ git log --since=2.weeks
This command works with lots of formats—you can specify a specific date ("2008-01-15") or a relative date such as "2 years 1 day 3 minutes ago".
The --author option allows you to filter on a specific author, and the --grep option lets you search for keywords in the commit messages. Use --all-match to match all filter otherwise the command will match commits with any. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (-- ) to separate the paths from the options.
Common git log Filtering Options
|
|
Option |
Description |
-(n) |
Show only the last n commits. |
--since, --after |
Limit the commits to those made after the specified date. |
--until, --before |
Limit the commits to those made before the specified date. |
--author |
Only show commits in which the author entry matches the specified string. |
--committer |
Only show commits in which the committer entry matches the specified string. |
29. If you commit too early and possibly forget to add some files, or you mess up your commit message, you can run commit with the --amend option:
$ git commit --amend
This command takes your staging area and uses it for the commit. The same commit-message editor fires up, but it already contains the message of your previous commit. You can edit the message the same as always, but it overwrites your previous commit. This commit will replace the previous one.
30. You can use "git reset HEAD <file> " to unstage a file.
31. You can use "git checkout -- <file> " to discard changes in working directory.
32. To see which remote servers you have configured, you can run the git remote command. It lists the short-names of each remote handle you've specified. If you've cloned your repository, you should at least see origin —that is the default name Git gives to the server you cloned from. You can also specify -v , which shows you the URL that Git has stored for the short-name to be expanded to.
33. To add a new remote Git repository as a short-name you can reference easily, run git remote add [shortname] [url] .
34. To get data from your remote projects, you can run:
$ git fetch [remote-name]
The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. The fetch command pulls the data to your local repository—it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready.
35. If you have a branch set up to track a remote branch, you can use the git pull [remote-repo] command to automatically fetch and then merge a remote branch into your current branch. By default, the git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from. Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.
36. When you have your project at a point that you want to share, you have to push it upstream:
$git push [remote-name] [branch-name]
If someone else pushed upstream and then you push upstream, your push will rightly be rejected. You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push.
37. If you want to see more information about a particular remote, you can use the git remote show [remote-name] command.
38. If you want to rename a reference, in newer versions of Git you can run git remote rename [original-name] [new-name] to change a remote's short-name. If you want to remove a reference for some reason you can use
git remote rm [short-name] .
39. Listing the available tags in Git is straightforward, just type git tag . You can also search for tags with a particular pattern:
$ git tag − l v1.4.2.*
40. Git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn't change—it's just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They're check-summed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG).
41. The easiest way to create an annotated tag is to specify -a when you run the tag command:
$ git tag -a v1.4 -m 'my version 1.4'
42. You can see the tag data along with the commit that was tagged by using the git show command:
$ git show v1.4
43. You can also sign your tags with GPG:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
44. A lightweight tag is basically the commit checksum stored in a file—no other information is kept. To create a lightweight tag, don't supply the -a , -s , or -m option. If you run git show on the tag, you don't see the extra tag information. The command just shows the commit.
45. To verify a signed tag, you use git tag -v [ tag-name] . This command uses GPG to verify the signature. You need the signer's public key for this to work properly.
46. To tag a past commit, you specify the commit checksum (or part of it) at the end of the command:
$ git tag -a v1.2 9fceb02
47. The git push command doesn't transfer tags to remote servers. You have to explicitly push tags to a shared server after you create them. This process is just like sharing remote branches—you can run git push origin [tagname] .
48. You can also use the --tags option to the git push command. This transfers to the remote server all of your tags that aren't already there.
49. Download the Git source code, and look in the contrib/completion directory; there should be a file called git-completion.bash . Copy this file to your home directory, and add this to your .bashrc file:
source ˜/.git-completion.bash
If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the /opt/local/etc/bash_completion.d directory on Mac systems or to the /etc/bash_completion.d/ directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions.
50. You can use git config to create alias for git command or external command:
$ git config --global alias.ci commit
git ci <----> git commit
$ git config –global alias.unstage 'reset HEAD --'
git unstage fileA <----> git reset HEAD fileA
$ git config --global alias.visual "!gitk"
git visual <----> gitk
发表评论
-
授权申明
2012-04-13 18:40 853近日我将我在iteye上发布的《Pro Git读书笔记》做成电 ... -
《Pro Git》读后感
2012-03-18 18:26 2339开始接触Git是在去年年初,公司开始从Clearcase 过度 ... -
Chapter 9. Git Internals
2012-03-18 17:27 24681. Git is fundamentally ... -
Chapter 8. Git and Other Systems
2012-03-17 21:44 13141. git svn allows y ... -
Chapter 7. Customizing Git
2012-03-17 16:10 18461. Git uses a series of ... -
Chapter 6. Git Tools
2012-03-13 19:52 13651. Git is smart ... -
Chapter 5. Distributed Git
2012-03-05 23:10 16701. You can easil ... -
Chapter 4. Git on the Server
2012-03-03 16:23 19591. The preferred method ... -
Chapter 3. Git Branching
2012-02-29 15:22 22441. Branching means you ... -
Chapter 1. Getting Started
2012-02-26 15:31 32691. Version control is a system ... -
《Pro Git》
2011-11-27 21:43 932A very good git tutorial: ...
相关推荐
Chapter 2. Package Structure Part II. Package Components Chapter 3. R Code Chapter 4. Package Metadata Chapter 5. Object Documentation Chapter 6. Vignettes: Long-Form Documentation Chapter 7. Testing...
Chapter 2. Using the Wiki and Managing Code Versioning Chapter 3. Managing Organizations and Teams Chapter 4. Collaboration Using the GitHub Workflow Chapter 5. GitHub Pages and Web Analytics Chapter ...
Chapter 14: Git Basics Chapter 15: Setting up Github Chapter 16: Local vs. Remote Repositories SECTION 2 - Beginning iOS Chapter 17: Your First iOS App Chapter 18: UIStackView Chapter 19: Tipsy Tip ...
Chapter 2: Site Building: Building Drupal Sites Without Programming Chapter 3: Getting Started with HTML Chapter 4: Creating a Basic Drupal Module with HTML Output Chapter 5: A CSS Primer for Drupal ...
Git is the most popular tool for that purpose and GitHub was built around it leveraging its powers by bringing it to the web., Starting with the basics of creating a repository you will then learn ...
Each chapter provides exercises to help you learn various techniques and short quizzes to make sure you understand key concepts. This thoroughly revised edition is ideal for students and professionals...
在实际的学习笔记中,我们可能会看到如 "Chapter01-Basics.md"、"Chapter02-VariablesAndOperators.md" 这样的文件,分别对应不同的章节,涵盖 Java 基础语法、变量和运算符等内容。 在这个项目中,学习者将能够: ...
**1.2 获取帮助 (Chapter 2: Getting Help)** - **命令行帮助**: 如`man`, `info`等命令。 - **在线资源**: 指导用户如何查找在线文档和社区支持。 - **书籍推荐**: 推荐进一步学习Unix的书籍资源。 #### 二、定制...
【压缩包子文件的文件名称列表】:虽然没有提供具体的子文件名称,但通常这样的文件结构可能会包括多个章节或主题,例如 "Chapter01_Basics", "Chapter02_Programming", "Chapter03_Databases", "Chapter04_...
在这个目录下,可能会有按照章节或主题划分的子文件夹,每个子文件夹内包含了对应的笔记内容,如"Chapter01-Basics"、"Chapter02-OOP"等,便于读者按需查阅。 综合以上信息,我们可以期待"myJavaNotes:王松年的Java...