You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged.
9
-
This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit.
12
-
Staging the files checksums each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
$ git commit -m 'The initial commit of my project'
18
18
----
19
19
20
-
When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository.
21
-
Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.(((git commands, commit)))
Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.
This moves `HEAD` to point to the `testing` branch.
102
+
這會移動 `HEAD` 並指向 `testing` 分支。
103
103
104
-
.HEAD points to the current branch
105
-
image::images/head-to-testing.png[HEAD points to the current branch.]
104
+
.被 HEAD 指向的分支是目前分支
105
+
image::images/head-to-testing.png[被 HEAD 指向的分支是目前分支。]
106
106
107
-
What is the significance of that?
108
-
Well, let's do another commit:
107
+
這樣做有什麼意義呢？
108
+
好吧！讓我們再提交一次：
109
109
110
110
[source,console]
111
111
----
112
112
$ vim test.rb
113
113
$ git commit -a -m 'made a change'
114
114
----
115
115
116
-
.The HEAD branch moves forward when a commit is made
117
-
image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.]
116
+
.當再次提交時，被 HEAD 指向的分支會往前走
117
+
image::images/advance-testing.png[當再次提交時，被 HEAD 指向的分支會往前走。]
118
118
119
-
This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches.
It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to.
132
-
This also means the changes you make from this point forward will diverge from an older version of the project.
133
-
It essentially rewinds the work you've done in your `testing` branch so you can go in a different direction.
130
+
這條命令做了兩件事，
131
+
它把 HEAD 指標移回去並指向 `master` 分支，然後把工作目錄中的檔案換成 `master` 分支所指向的快照內容；
132
+
也就是說，現在開始所做的改動，將基於專案中較舊的版本，然後與其它提交歷史分離開來；
133
+
它實際上是取消你在 `testing` 分支裡所做的修改，這樣你就可以往不同方向前進。
134
134
135
135
[NOTE]
136
-
.Switching branches changes files in your working directory
136
+
.切換分支會修改工作目錄裡的檔案
137
137
====
138
-
It's important to note that when you switch branches in Git, files in your working directory will change.
139
-
If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch.
140
-
If Git cannot do it cleanly, it will not let you switch at all.
138
+
重要的是要注意：當你在 Git 中切換分支時，工作目錄內的檔案將會被修改；
139
+
如果切換到舊分支，你的工作目錄會回復到看起來就像當初你最後一次在這個分支提交時的樣子。
140
+
如果 Git 無法很乾淨地切換過去，它就不會讓你切換過去。
141
141
====
142
142
143
-
Let's make a few changes and commit again:
143
+
讓我們做一些修改並再次提交：
144
144
145
145
[source,console]
146
146
----
147
147
$ vim test.rb
148
148
$ git commit -a -m 'made other changes'
149
149
----
150
150
151
-
Now your project history has diverged (see <<divergent_history>>).
152
-
You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work.
153
-
Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you're ready.
154
-
And you did all that with simple `branch`, `checkout`, and `commit` commands.
You can also see this easily with the `git log` command.
161
-
If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.
Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy.
175
-
Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project's files into a second directory.
178
-
This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous.
179
-
Also, because we're recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do.
180
-
These features help encourage developers to create and use branches often.
0 commit comments