2009-08-01 31 views
30

Vì vậy, tôi đang sử dụng GUI Git để tạo một kho lưu trữ. Nhưng tôi không thể tìm thấy bất kỳ dấu vết nào trên Google, Tài liệu hoặc bất kỳ nơi nào khác mà 'Biểu thức sửa đổi' là gì và cần phải tạo Chi nhánh mới.Biểu thức sửa đổi Git là gì?

Ngoài ra, có vẻ như điều này được sử dụng nhiều nơi khác trong chương trình, vì vậy tôi tin rằng điều quan trọng là phải biết.

Tôi đã tìm thấy câu hỏi về điều này trên StackOverflow, nhưng anh ấy không bao giờ có câu trả lời.

Tôi chỉ cần biết: Biểu thức sửa đổi là gì?

+0

nếu bạn muốn kết hợp các thay đổi từ xa sang địa phương của bạn (master for me), bạn có thể nhập từ xa/master – cgao

Trả lời

32

git cần để có thể xác định một cam kết trong một số hoạt động phổ biến

Có một số cách để xác định một cam kết. Bạn có thể sử dụng một chi nhánh, thẻ, cam kết sha1, hoặc biểu thức. Ví dụ:

git log HEAD 

HEAD cuối cùng sẽ giải quyết một cam kết cụ thể và bạn sẽ được cung cấp nhật ký cho điều đó. YOu cũng có thể nói:

git log master 

master là chi nhánh và cũng sẽ giải quyết một cam kết cụ thể.

git log fd72e9c99312 

Bây giờ IS là cam kết thực tế.


Tài liệu dưới đây là những gì bạn đang tìm kiếm. Lấy từ tài liệu hướng dẫn git-rev-parse tại http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.

sửa đổi quy định cụ thể

Một số phiên bản thông thường, nhưng không nhất thiết, tên một đối tượng cam kết. Chúng sử dụng cú pháp SHA1 mở rộng. Dưới đây là các cách khác nhau để đánh vần tên đối tượng. Những cái được liệt kê ở gần cuối danh sách này là đặt tên cho cây và các đốm màu trong một commit.

Tên đối tượng SHA1 đầy đủ (chuỗi thập lục phân 40 byte) hoặc chuỗi con như vậy là duy nhất trong kho lưu trữ. Ví dụ. dae86e1950b1277e545cee180551750029cfe735 và dae86e cả hai tên cùng một đối tượng cam kết nếu không có đối tượng khác trong kho lưu trữ của bạn có tên đối tượng bắt đầu bằng dae86e.

Đầu ra từ mô tả git; tức là một thẻ gần nhất, được theo sau bởi dấu gạch ngang và một số lần commit, theo sau là dấu gạch ngang, g và tên đối tượng viết tắt.

Tên ref biểu tượng. Ví dụ. master thường có nghĩa là đối tượng commit được tham chiếu bởi $ GIT_DIR/refs/heads/master. Nếu bạn có cả hai đầu/master và thẻ/master, bạn có thể nói rõ ràng thủ trưởng để nói với git mà bạn muốn nói.Khi mơ hồ, một cách rõ ràng bằng cách tham gia trận đấu đầu tiên trong các quy tắc sau:

nếu $ GIT_DIR/tồn tại, đó là ý bạn (thường chỉ hữu ích cho HEAD, FETCH_HEAD, ORIG_HEAD và MERGE_HEAD);

nếu không, $ GIT_DIR/refs/if exists;

nếu không, $ GIT_DIR/refs/tags/if exists;

nếu không, $ GIT_DIR/refs/heads/if exists;

nếu không, $ GIT_DIR/refs/remotes/if exists;

nếu không, $ GIT_DIR/refs/remotes // HEAD nếu tồn tại.

Tên gốc cam kết thay đổi của bạn trong cây đang hoạt động dựa trên. FETCH_HEAD ghi lại nhánh bạn đã tìm nạp từ một kho lưu trữ từ xa với lời gọi git-fetch cuối cùng của bạn. ORIG_HEAD được tạo ra bởi các lệnh di chuyển HEAD của bạn một cách quyết liệt, để ghi lại vị trí của HEAD trước khi hoạt động của chúng, để bạn có thể thay đổi đầu của nhánh trở lại trạng thái trước khi bạn chạy chúng một cách dễ dàng. MERGE_HEAD ghi lại (các) commit bạn đang hợp nhất vào chi nhánh của bạn khi bạn chạy git-merge.

Một lần tiếp theo là hậu tố @ với thông số ngày được đính kèm trong cặp đôi (ví dụ: {yesterday}, {1 tháng 2 tuần 3 ngày 1 giờ 1 giây trước} hoặc {1979-02-26 18:30: 00}) để xác định giá trị của ref tại một điểm trước đó trong thời gian. Hậu tố này chỉ có thể được sử dụng ngay sau tên ref và ref phải có một log hiện có ($ GIT_DIR/logs /). Lưu ý rằng điều này tra cứu trạng thái của ref nội bộ của bạn tại một thời điểm nhất định; ví dụ: trong tổng chi nhánh địa phương của bạn tuần trước. Nếu bạn muốn xem xét các cam kết được thực hiện trong một số thời điểm nhất định, hãy xem --since và --until.

Giá trị tiếp theo là hậu tố @ với thông số thứ tự được đính kèm trong cặp ngoặc đôi (ví dụ: {1}, {15}) để chỉ định giá trị trước đó của giá trị n. Ví dụ: master @ {1} là giá trị trước đó ngay lập tức của master trong khi master @ {5} là giá trị thứ 5 trước của master. Hậu tố này chỉ có thể được sử dụng ngay sau tên ref và ref phải có một log hiện có ($ GIT_DIR/logs /).

Bạn có thể sử dụng cấu trúc @ với phần ref trống để có thể khôi phục nhánh hiện tại. Ví dụ: nếu bạn ở trên nhánh blabla, thì @ {1} có nghĩa là blabla @ {1}.

Cấu trúc đặc biệt @ {-} có nghĩa là nhánh thứ được kiểm tra trước nhánh hiện tại.

Hậu tố^đối với thông số sửa đổi có nghĩa là phụ huynh đầu tiên của đối tượng cam kết đó.^nghĩa là phụ huynh thứ hai (tức là rev^tương đương với rev^1). Như một quy tắc đặc biệt, rev^0 có nghĩa là cam kết và được sử dụng khi rev là tên đối tượng của một đối tượng thẻ đề cập đến một đối tượng cam kết.

Hậu tố ~ đối với thông số sửa đổi có nghĩa là đối tượng cam kết là thế hệ thứ ba của đối tượng cam kết được đặt tên, chỉ theo sau cha mẹ đầu tiên. I E. rev ~ 3 tương đương với rev ^^^ tương đương với rev^1^1^1. Xem dưới đây để minh họa cách sử dụng biểu mẫu này.

Hậu tố^theo sau là tên đối tượng được đính kèm trong cặp ngoặc (v0.99.8^{commit}) có nghĩa là đối tượng có thể là thẻ và bỏ qua thẻ đệ quy cho đến khi tìm thấy đối tượng thuộc loại đó hoặc đối tượng không thể được dereferenced nữa (trong trường hợp đó, barf). rev^0 được giới thiệu trước đó là viết tắt của rev^{commit}.

Hậu tố^tiếp theo là cặp dấu ngoặc rỗng (ví dụ: v0.99.8^{}) có nghĩa là đối tượng có thể là thẻ và bỏ qua thẻ đệ quy cho đến khi tìm thấy đối tượng không phải thẻ.

Dấu hai chấm, sau dấu gạch chéo, theo sau là văn bản: tên này là cam kết có thư cam kết bắt đầu bằng văn bản được chỉ định. Tên này trả về commit tương ứng nhỏ nhất có thể truy cập từ bất kỳ ref nào. Nếu thông báo cam kết bắt đầu bằng a !, bạn phải lặp lại điều đó; trình tự đặc biệt:/!, theo sau là cái gì đó khác! được dành riêng cho bây giờ.

Hậu tố: sau đó là đường dẫn; tên này là blob hoặc cây tại đường dẫn đã cho trong đối tượng tree-ish được đặt tên bởi phần trước dấu hai chấm.

Dấu hai chấm, tùy ý theo sau là một số giai đoạn (0 đến 3) và dấu hai chấm, sau đó là đường dẫn; tên này là một đối tượng blob trong chỉ mục tại đường dẫn đã cho. Thiếu số giai đoạn (và dấu hai chấm sau nó) đặt tên cho mục nhập giai đoạn 0. Trong quá trình hợp nhất, giai đoạn 1 là tổ tiên chung, giai đoạn 2 là phiên bản của nhánh đích (thường là nhánh hiện tại) và giai đoạn 3 là phiên bản từ nhánh được hợp nhất.

Đây là hình minh họa, của Jon Loeliger. Cả hai nút cam kết B và C là cha mẹ của nút cam kết A. Các cam kết của phụ huynh được sắp xếp từ trái sang phải.

G H I J 
\/ \/
    D E F 
    \ |/\ 
    \ |/ | 
    \|/ | 
     B  C 
     \ /
     \/
     A 
A =  = A^0 
B = A^ = A^1  = A~1 
C = A^2 = A^2 
D = A^^ = A^1^1 = A~2 
E = B^2 = A^^2 
F = B^3 = A^^3 
G = A^^^ = A^1^1^1 = A~3 
H = D^2 = B^^2 = A^^^2 = A~2^2 
I = F^ = B^3^ = A^^3^ 
J = F^2 = B^3^2 = A^^3^2 
+1

Lưu ý rằng bạn cũng có thể truy cập tài liệu SPECIFYING REVISIONS trực tiếp thông qua 'man gitrevisions' (https: // www.kernel.org/pub/software/scm/git/docs/gitrevisions.html). –

9

gahooa cung cấp câu trả lời toàn diện. Các trường hợp phổ biến:

  • Tên của một chi nhánh hiện có (ví dụ, master)
  • vài chữ số đầu tiên của một tổng kiểm tra SHA1, chụp tốt nhất từ ​​gitk hoặc git log

Chào mừng đến với thế giới tuyệt vời của git . TMI là mệnh cho khóa học ...

+3

TMI = mệnh giá. Câu trả lời thường gặp = Birdie. – dreftymac

0

Trường hợp khác, khi sử dụng Emacs: Chỉ cần gõ Ctrl-x v l để liệt kê tất cả các sửa đổi. Đối với một newbie để git (nhưng không phải để Emacs/CVS) Tôi rất ngạc nhiên khi thấy rằng các phiên bản được liệt kê như:

commit 8d5ab12cd76d5e6098e5894c8713ec605fd9f153 

Đó chắc chắn là một sự thay đổi mới mẻ từ Major.minor.bugfix.build ký hiệu.

Điều đáng ngạc nhiên hơn là Emacs xử lý git tự động mà không cần tôi nói (thông qua .emacs) mà nó cần tham khảo git thay vì CVS. Khá tuyệt vời.

Vì vậy, để tóm tắt, khi Emacs nhắc sửa đổi, chỉ cần nhập 40 chữ số hex đó.

Các vấn đề liên quan