Update data

[gitmagic.git] / vi / branch.txt

== Thủ Thuật Tạo Nhánh ==

Tạo nhánh và trộn là các đặc tính sát thủ của Git.

*Vấn đề*: Những nhân tố bên ngoài chắc hẳn có đòi hỏi việc hoán chuyển nội dung. Một lỗi severe
bug manifests trong phiên bản đã được phát hành mà không được cảnh báo gì. The deadline for a
certain feature is moved closer. Một nhà phát triển phần mềm whose help you need for a key section of the project is about to leave. trong tất cả các trường hợp, bạn phải abruptly xóa bỏ cái mà bạn đang làm và nhắm vào on a completely different task.

Việc gán đoạn suy nghĩ có thể làm giảm hiệu suất làm việc của bạn, and the more cumbersome it is to switch contexts, càng lớn càng tổn thất. Đối với các hệ thống quản lý mã nguồn tập trung chúng ta phải tải về một bản sao công việc mới từ máy chủ trung tâm. Các hệ thống phân tán fare better, as we can clone the desired version locally.

Nhưng việc nhân bản bắt buộc phải sao chép toàn bộ thư mục làm việc cũng như là toàn bộ các mục trong lịch sử cho đến thời điểm đã được chỉ ra. Dù là Git giảm bớt sự lãng phí cho việc này bằng cách chia sẻ và tạo ra các liên kết tệp tin cứng, chính bản thân các tệp tin dự án cũng phải được tạo ra trong các đề mục của chúng trong thư mục làm việc.

*Giải pháp*: Git có một công cụ tốt hơn để sử lý tình huống này, nó nhanh và tiết kiệm không gian lưu trữ hơn lệnh nhân bản: *git branch*.

Với những khả năng tuyệt diệu của mình With this magic word, các tệp tin trong thư mục của bạn suddenly shape shift từ phiên bản này sang phiên bản khác. Sự chuyển đổi này có thể  làm nhiều hơn việc quay lại hay chuyển tiếp trong lịch sử một các đơn thuần. Các tệp tin của bạn có thể chuyển hình thái từ bản phát hành cuối thành phiên bản thử nghiệm, thành phiên bản phát triển hiện hành, thành phiên bản của người bạn của bạn, và cứ như thế.

=== The Boss Key ===

Ever played one of those games where at the push of a button (``the boss key''), màn hình có lẽ hiển thị ngay một cái bảng hay một thứ gì đó? Thế thì nhỡ ông chủ của bạn đang đi lại trong văn phòng nơi bạn đang chơi trò chơi thì làm cách nào để nhanh chóng giấu chúng đi?

Ở 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  # dường như chẳng có gì thay đổi sau lệnh này
 $ echo "My boss is smarter than me" > myfile.txt
 $ git commit -a -m "Lần commit khác"

Điều này cũng giống như việc chúng ta ghi đè lên tệp tin của mình sau đó commit nó. Nhưng không, đó chỉ là ảo tưởng. Gõ:

 $ git checkout master  # quay trở lại phiên bản nguyên gốc của tệp tin

Ối trời ơi! Tệp tin văn bản lại trở về như cũ mất rồi. Và nếu ông chủ có ý định ngó qua thư mục của bạn thì hãy gõ:

 $ git checkout boss  # chuyển trở lại phiên bạn vừa mắt ông chủ

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 từng cái trong số chúng một cách độc lập.

=== Dirty Work ===

[[branch]]
Bạn nói mình đang làm việc với một số đặc tính kỹ thuật, 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 ra màn hình để có thể thấy được một số hàm 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ời ở đâu mình muốn. Bạn còn có thể commit những thay đổi đó. Khi bạn đã làm xong,

 $ git checkout master

để quay lại công việc chính. Chú ý là bất kỳ các thay đổi không được commit sẽ đổ xuống sông xuống biển.

Nhưng bạn lại muốn ghi lại các thay đổi tạm thời đó sau khi làm xong? Rất dễ:

 $ git checkout -b dirty

và commit trước khi quay trở lại nhánh master. Khi nào đó bạn muốn quay trở lại các thay đổi ở trên, đơn giản, chỉ cần gõ:

 $ git checkout dirty

Chúng ta đã đụng chạm đến lệnh như trên ở những chương trước rồi, khi thảo luận về việc tải về một trạng thái cũ. Cuối cùng chúng ta có thể thuật lại toàn bộ câu chuyện: các tệp tin đã thay đổi theo trạng thái đã được yêu cầu, nhưng chúng ta phải rời bỏ nhánh master. Tất cả những lần commit được tạo ra từ đây sẽ dẫn bạn đi trên một nhánh khác, nhánh này có thể được đặt tên sau.

Mặt khác, sau khi 'check out' một trạng thái cũ, Git tự động đặt bạn vào một trạng thái mới, một nhánh chưa có tên, và nhánh này có thể đặt tên và ghi lại với lệnh *git checkout -b*.

=== Quick Fixes ===

Bạn đang phân vân giữa ngã ba đường khi bạn phải xác định là xóa tất cả mọi thứ hoặc là are told to drop everything and fix a newly discovered lỗi trong lần commit `1b6d...`:

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

Một khi bạn đã sửa lỗi:

 $ git commit -a -m "Sửa lỗi"
 $ git checkout master

và phục hồi lại công việc theo phận sự của mình. Bạn thậm chí có thể 'merge' in the freshly
baked bugfix:

 $ git merge fixes

=== Trộn ===

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 và bạn có thể
không hay biết nó hoạt động như thế nào.

Chúng ta đã sử dụng việc trộn từ lâu rồi. Lệnh *pull* trên thực tế đã 'fetch'
các lần commit và sau đó trộn chúng vào trong nhánh hiện hành của bạn. Nếu trên máy của mình bạn không có
thay đổi gì cả, thế thì việc trộn sẽ là một 'fast forward', a degenerate case akin to fetching
phiên bản cuối cùng trong hệ thống quản lý mã nguồn tập trung. Nhưng nếu bạn đã có thay đổi
trên máy của mình, Git sẽ tự động trộn, và báo cáo cho bạn nếu có xung đột xảy ra.

Thông thường, một lần commit có một 'commit cha', tạm gọi thế, the previous
commit. Merging branches together produces a commit with at least two parents.
Điều này đặt ra câu hỏi: lần commit mà `HEAD~10` thực sự ám chỉ đến là lần nào? Một lần commit
có thể có nhiều cha, thế thì chúng ta phải theo cái nào?

It turns out this notation chooses the first parent every time. Đây là
desirable bởi vì nhánh hiện hành trở thành cha đầu tiên trong suốt quá trình trộn;
một cách thường xuyên, bạn chỉ liên quan đến những thay đổi mình tạo ra trong nhánh
hiện hành , as opposed to changes merged in từ các nhánh khác.

Bạn có thể quy một cha nào đó với một dấu mũ. Ví dụ, để hiển thị
logs từ cha thứ hai:

 $ git log HEAD^2

Bạn có thể bỏ qua số dành cho cha đầu tiên. Ví dụ, để hiển thị
sự khác nhau với cha đầu tiên:

 $ git diff HEAD^

Bạn có thể tổ hợp các dấu mũ này với các kiểu khác nhau. Ví dụ:

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

bắt đầu một nhánh mới ``ancient'' tương ứng với trạng thái (state) lần commit thứ 10 trở về trước từ
cha thứ hai của cha thứ nhất của lần commit bắt đầu với 1b6d.

=== Làm Việc Liên Tục ===

Thường trong các dự án phần cứng, bước thứ hai của kế hoạch phải chờ bước thứ nhất hoàn thành. Một chiếc xe hơi cần sửa chữa có thể phải nằm chờ trong xưởng sửa chữa cho đến khi các chi tiết phụ tùng đặc biệt được chuyển đến từ nhà máy. Một mẫu có thể phải chờ một con chip được làm ra trước khi quá trình chế tác có thể tiếp tục.

Dự án phần mềm cũng có thể tương tự như thế. Bộ phận thứ hai có một số tính năng có thể phải
chờ cho đến khi phần thứ nhất đã được phát hành và kiểm tra. Một số dự án yêu cầu
mã nguồn của bạn phải được xem xét lại trước khi chấp nhận nó, vì vậy bạn có thể phải chờ cho đến khi bộ phận
thứ nhất đã được chấp thuận trước khi bắt đầu phần thứ hai.

Nhờ có việc tạo nhánh và trộn dễ dàng và cũng chẳng mất mát gì, chúng ta có thể phá vỡ quy tắc và làm việc trên
Part II trước khi Part I chính thức sẵn sàng. Gải sử bạn đã commit Part I
và gửi nó đi để xem xét. Giả sử bạn đang ở nhánh `master`. Thế thì hãy phân nhánh
ra:

 $ git checkout -b part2

Tiếp đến, làm việc trên Part II, commit những thay đổi của bạn  your changes along the way. To err is human,
and often you'll want to go back và sửa lỗi nào đó trong Part I.
Nếu may mắn, or very good, bạn có thể bỏ qua những dòng này.

 $ 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 được chấp thuận:

 $ git checkout master  # Quay trở lại Part I.
 $ submit files         # Xuất bản ra!
 $ git merge part2      # Trộn vào Part II.
 $ git branch -d part2  # Xóa nhánh "part2".

Bây giờ chúng ta lại ở trong nhánh `master`, với Part II trong thư mục làm việc.

Thủ thuật này rất dễ dàng để mở rộng ra dành cho nhiều phần hơn. Nó cũng đễ dàng để
phân nhánh ra từ quá khứ: giả sử muộn bạn mới nhận ra là mình phải tạo
một nhánh từ trước đây 7 lần commit. Thế thì gõ:

 $ git branch -m master part2  # Đổi tên nhánh "master" thành "part2".
 $ git checkout HEAD~7 -b master # Tạo nhánh "master" mới 7 lần commit ngược từ trước.

Nhánh `master` bây giờ chỉ chứa Part I, và nhánh `part2` trở thành contains phần ngừng lại.

=== Cải Tổ Lại Sự Pha Trộn ===

Có lẽ bạn thích làm việc trên mọi khía cạnh của một dự án trên cùng một nhánh. You want to keep works-in-progress to yourself and và muốn những người khác chỉ thấy được các lần commit của bạn không họ have been neatly organized. Hãy chuẩn bị một cặp nhánh:

  $ git branch -b sanitized # Tạo một nhánh dùng cho việc dọn.
  $ git checkout -b medley # Tạo và chuyển nhánh thành nơi làm việc.

Tiếp theo, làm việc gì đó: 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, commit thường xuyên. Sau đó:

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

áp dụng applies the grandparent of the head commit of the nhánh ``medley'' to nhánh ``sanitized''. Với lệnh thích hợp là cherry-picks bạn có thể cấu trúc một nhánh mà nó chỉ chứa mã nguồn không thay đổi, và những lần commit có liên quan sẽ được nhóm lại với nhau.

=== Quản Lý Các Nhánh ===

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''. Một số người chủ trương rời bỏ
nhánh ``master'' mà không động chạm gì đến nó và tạo các nhánh mới dành 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ển (đổi tên) các nhánh.
Xem thêm *git help branch*.

Nhánh ``master'' thông thường rất hữu dụng. Những người khác có thể cho rằng
kho chứa của bạn có nhánh với tên này, và nhánh đó chứa phiên bản chính thức
của dự án của bạn. Mặc dù bạn có thể đổi tên hay xóa bỏ nhánh ``master'',
nhưng bạn nên tôn trọng thỏa thuận ngầm này.

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

Một lát sau bạn có lẽ nhận thức được rằng you are creating short-lived branches
frequently vì các lý do như: mọi nhánh khác đơn thuần phục vụ cho
việc ghi lại trạng thái hiện tại so you can briefly hop back to an older state to
fix a high-priority bug hay thứ gì đó.

Đ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 cái gì.
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

Lệnh này ghi lại trạng thái hiện hành vào một vị trí tạm thời (một 'stash') và
phục hồi lại trạng thái trước đó. Thư mục bạn đang làm việc xuất hiện chính xác
như trước khi bạn chỉnh sửa, và bạn có thể sửa lỗi, pull in upstream changes, và
cứ như thế. Khi bạn muốn qua trở lại trạng thái đã được tạm giấu đi đó, hãy gõ:

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

Bạn có thể có nhiều trạng thái được tạm giấu đi, và vận dụng chúng theo nhiều cách khác nhau. Xem
*git help stash*. As you may have guessed, Git duy trì các nhánh ở 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. Cuối cùng, clones are almost
as fast, và bạn có thể hoán chuyển giữa chúng với lệnh *cd* thay vì sử dụng
lệnh riêng của Git.

Ta thử xét đến các trình duyệt web. Tại sao việc 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.