Edit branch.txt

[gitmagic/gitmagic.git] / vi / branch.txt

== Branch Wizardry ==

Instant branching and merging are the most lethal of Git's killer features.

*Problem*: External factors inevitably necessitate context switching. A severe
bug manifests in the released version without warning. The deadline for a
certain feature is moved closer. A developer whose help you need for a key section of the project is about to leave. In all cases, you must abruptly drop what you are doing and focus on a completely different task.

Interrupting your train of thought can be detrimental to your productivity, and the more cumbersome it is to switch contexts, the greater the loss. With centralized version control we must download a fresh working copy from the central server. Distributed systems fare better, as we can clone the desired version locally.

But cloning still entails copying the whole working directory as well as the entire history up to the given point. Dù là Git reduces the cost of this with file sharing and hard links, the project files themselves must be recreated in their entirety in the new working directory.

*Solution*: Git có một công cụ tốt hơn để sử lý tình huống này that is much faster and more space-efficient hơn là cloning: *git branch*.

With this magic word, the files in your directory suddenly shapeshift from one version to another. This transformation can do more than merely go back or forward in history. Your files can morph from the last release to the experimental version to the current development version to your friend's version and so on.

=== The Boss Key ===

Ever played one of those games where at the push of a button (``the boss key''), the screen would instantly display a spreadsheet or something? So if the boss walked in the office while you were playing the game you could quickly hide it away?

Ở thư mục nào đó:

 $ echo "I'm smarter than my boss" > myfile.txt
 $ git init
 $ git add .
 $ git commit -m "Lần commit bắt đầu"

Chúng ta đã tạo ra kho chứa Git mà nó theo dõi một tệp tin văn bản có chứa một thông điệp đã biết trước. Giờ hãy gõ:

 $ git checkout -b boss  # nothing seems to change after this
 $ echo "My boss is smarter than me" > myfile.txt
 $ git commit -a -m "Another commit"

It looks like we've just overwritten our file and committed it. Nhưng đó chỉ là ảo tưởng. Gõ:

 $ git checkout master  # switch to original version of the file

Ối trời ơi! Tệp tin văn bản lại trở về như cũ mất rồi. And if the boss decides to snoop around this directory, gõ:

 $ git checkout boss  # switch to version suitable for boss' eyes

Bạn có thể hoán chuyển giữa hai phiên bản của tệp tin tùy thích, và commit to each independently.

=== Dirty Work ===

[[branch]]
Say you're working on some feature, và vì lý do nào đó, bạn muốn quay trở lại bản cách đây ba bản và tạm thời đặt vài dòng lệnh
in print để có thể thấy được một số thứ hoạt động như thế nào. Thế thì:

 $ git commit -a
 $ git checkout HEAD~3

Giờ thì bạn có thể thêm những dòng code tạm thờiNow you can add ugly temporary code all over the place. You can even commit these changes. Khi bạn đã làm xong,

 $ git checkout master

để quay lại công việc chính. Observe that any uncommitted changes are carried over.

What if you wanted to save the temporary changes after all? Rất dễ:

 $ git checkout -b dirty

and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type:

 $ git checkout dirty

We touched upon this command in an earlier chapter, when discussing loading old states. At last we can tell the whole story: the files change to the requested state, but we must leave the master branch. Any commits made from now on take your files down a different road, which can be named later.

In other words, after checking out an old state, Git automatically puts you in a new, unnamed branch, which can be named and saved with *git checkout -b*.

=== Quick Fixes ===

You're in the middle of something when you are told to drop everything and fix a newly discovered bug in commit `1b6d...`:

 $ git commit -a
 $ git checkout -b fixes 1b6d

Then once you've fixed the bug:

 $ git commit -a -m "Bug fixed"
 $ git push  # to the central repository
 $ git checkout master

and resume work on your original task.

You can even 'merge' in the bugfix you just made, dùng một trong hai lệnh sau:

 $ git merge fixes

hay là:

 $ git pull

since you have already pushed the bugfix to the main repository.

=== Merging ===

Với một số hệ thống quản lý mã nguồn, việc tạo các nhánh rất dễ dàng nhưng trộn chúng
trở lại là một bài toán hóc búa. Với Git, việc trộn là dễ dàng that you might be
unaware of it happening.

We actually encountered merging long ago. The *pull* command in fact 'fetches'
commits and then merges them into your current branch. If you have no local
changes, then the merge is a 'fast forward', a degenerate case akin to fetching
the latest version in a centralized version control system. But if you do have
local changes, Git will automatically merge, and report any conflicts.

Ordinarily, a commit has exactly one 'parent commit', namely, the previous
commit. Merging branches together produces a commit with at least two parents.
This begs the question: what commit does `HEAD~10` really refer to? A commit
could have multiple parents, so which one do we follow?

It turns out this notation chooses the first parent every time. This is
desirable because the current branch becomes the first parent during a merge;
frequently you're only concerned with the changes you made in the current
branch, as opposed to changes merged in from other branches.

You can refer to a specific parent with a caret. Ví dụ, để hiển thị
the logs from the second parent:

 $ git log HEAD^2

You may omit the number for the first parent. Ví dụ, để hiển thị
sự khác nhau với differences with the first parent:

 $ git diff HEAD^

You can combine this notation with other types. Ví dụ:

 $ git checkout 1b6d^^2~10 -b ancient

starts a new branch ``ancient'' representing the state 10 commits back from the
second parent of the first parent of the commit starting with 1b6d.

=== Uninterrupted Workflow ===

Often in hardware projects, the second step of a plan must await the completion of the first step. A car undergoing repairs might sit idly in a garage until a particular part arrives from the factory. A prototype might wait for a chip to be fabricated before construction can continue.

Software projects can be similar. The second part of a new feature may have to
wait until the first part has been released and tested. Some projects require
your code to be reviewed before accepting it, so you might wait until the first
part is approved before starting the second part.

Thanks to painless branching and merging, we can bend the rules and work on
Part II before Part I is officially ready. Suppose you have committed Part I
and sent it for review. Let's say you're in the `master` branch. Then branch
off:

 $ git checkout -b part2

Next, work on Part II, committing your changes along the way. To err is human,
and often you'll want to go back and fix something in Part I.
Nếu may mắn,If you're lucky, or very good, you can skip these lines.

 $ git checkout master  # Go back to Part I.
 $ fix_problem
 $ git commit -a        # Commit the fixes.
 $ git checkout part2   # Go back to Part II.
 $ git merge master     # Merge in those fixes.

Cuối cùng, Part I is approved:

 $ git checkout master  # Go back to Part I.
 $ submit files         # Release to the world!
 $ git merge part2      # Merge in Part II.
 $ git branch -d part2

Now you're in the `master` branch again, with Part II in the working directory.

It's easy to extend this trick for any number of parts. It's also easy to
branch off retroactively: suppose you belatedly realize you should have created
a branch 7 commits ago. Then type:

 $ git branch -m master part2
 $  # Rename "master" branch to "part2".
 $ git checkout HEAD~7 -b master

The `master` branch now contains just Part I, and the `part2` branch contains
the rest.

=== Reorganizing a Medley ===

Perhaps you like to work on all aspects of a project in the same branch. You want to keep works-in-progress to yourself and want others to see your commits only when they have been neatly organized. Start a couple of branches:

  $ git checkout -b sanitized
  $ git checkout -b medley

Next, work on anything: sửa lỗi, thêm các đặc tính kỹ thuật, thêm mã lệnh tạm thời, vân vân, committing often along the way. Then:

  $ git checkout sanitized
  $ git cherry-pick medley^^

applies the grandparent of the head commit of the ``medley'' branch to the ``sanitized'' branch. With appropriate cherry-picks you can construct a branch that contains only permanent code, and has related commits grouped together.

=== Managing Branches ===

Liệt kê tất cả các nhánh bằng cách gõ:

 $ git branch

Theo mặc định, bạn bắt đầu tại nhánh có tên ``master''. Some advocate leaving the
``master'' branch untouched và tạo các nhánh mới cho các chỉnh sửa của riêng mình.

Các tùy chọn *-d* and *-m* cho phép bạn xóa hay di chuyểm (đổi tên) các nhánh.
Xem thêm *git help branch*.

Nhánh ``master'' branch is a useful custom. Others may assume that your
repository has a branch with this name, and that it contains the official
version of your project. Although you can rename or obliterate the ``master''
branch, you might as well respect this convention.

=== Nhánh Tạm ===

After a while you may realize you are creating short-lived branches
frequently for similar reasons: every other branch merely serves to
save the current state so you can briefly hop back to an older state to
fix a high-priority bug or something.

Điều này cũng tương tự như việc chuyển kênh trên TV một cách tạm thời để thấy chương trình khác đang chiếu.
Nhưng thay vì chỉ cần nhấn vài cái nút, bạn phải tạo, check out,
trộn và xóa nhánh tạm đó. May mắn thay, Git có cách ngắn gọn tiện lợi
chẳng thua kém gì chiếc điều khiển từ xa của một chiếc TV:

 $ git stash

This saves the current state in a temporary location (một 'stash') and
restores the previous state. Your working directory appears exactly as it was
before you started editing, and you can fix bugs, pull in upstream changes, and
so on. When you want to go back to the stashed state, type:

 $ git stash apply  # Bạn có thể phải giải quyết các xung đột.

You can have multiple stashes, and manipulate them in various ways. See
*git help stash*. As you may have guessed, Git maintains branches behind the scenes to perform this magic trick.

=== Làm Theo Cách Của Mình ===

You might wonder if branches are worth the bother. After all, clones are almost
as fast, and you can switch between them with *cd* instead of esoteric Git
commands.

Consider web browsers. Tại sao hỗ trợ mở nhiều tab thì cũng tốt như mở trên nhiều cửa sổ khác nhau?
Bởi vì cả hai điều này thể hiện tính đa dạng của quan điểm, phong cách sống. Một số người sử dụng lại thích
chỉ giữ một cửa sổ trình duyệt được mở, và sử dụng các tab để hiển thị nhiều trang web một lúc. Những người khác
có lẽ lại khăng khăng cực đoan cho rằng: mở trên nhiều cửa sổ khác nhau và chẳng cần tab nữa.
Một nhóm khác lại thích cả hai một lúc.

Việc tạo nhánh thì cũng giống như các tab cho thư mục làm việc của bạn, việc nhân bản thì giống như việc mở một cửa sổ duyệt mới. Những việc này nhanh chóng và nội bộ, thế thì sao lại không
thử nghiệm để tìm thấy cách thực hiện thích hợp nhất cho mình? Git giúp bạn làm việc chính xác
như bạn muốn.