Tôi là người dùng của SVN và bây giờ tôi đang học Git.

Trong SVN tôi thường kiểm tra trên máy cục bộ của mình một repo, bao gồm tất cả các chi nhánh trong dự án của tôi và tôi thường chọn thư mục cho chi nhánh mà tôi quan tâm và làm việc ở đó.

Tôi thấy một sự khác biệt bằng cách sử dụng Git.

Hiện tại tôi đang nhân bản một repo và nhân bản một chi nhánh cụ thể bằng gitk.

Thư mục dự án chỉ chứa nội dung cho nhánh đó và tôi không thể thấy tất cả các nhánh như trong SVN, điều này hơi khó hiểu đối với tôi.

Tôi không thể tìm thấy một cách dễ dàng để xem tất cả các chi nhánh trong kho lưu trữ cục bộ của mình bằng Git.

• Tôi muốn biết nếu quy trình Git mà tôi mô tả là "tiêu chuẩn" và một số cách chính xác hoặc tôi đang thiếu một cái gì đó.

• Ngoài ra, tôi muốn biết làm thế nào để xử lý một quá trình mà tôi cần phải làm việc trên hai nhánh cùng một lúc trong trường hợp, ví dụ, tôi cần tạo một hotfix trên master nhưng cũng giữ nội dung của một nhánh khác.

• Một quy ước tên đề xuất để tạo các thư mục bao gồm nhánh được sao chép từ repo trong Git là myproject-branchnamegì?

Tôi là người dùng của SVN và hiện tôi đang học GIT.

Chào mừng đến với băng đảng!

SVN cải tạo

Ở SVN tôi thường [...]

Chờ một lát. Trong khi CVS và SVN và hệ thống kiểm soát phiên bản truyền thống (nghĩa là tập trung) khác hoàn thành (hầu hết) cùng mục đích với các hệ thống kiểm soát phiên bản hiện đại (tức là phân tán) như mercurial và Git, bạn sẽ tốt hơn khi học Git từ đầu thay vì cố gắng chuyển luồng công việc SVN của bạn sang Git.

http://hginit.com ( xem trên archive.org ) của Joel Spolsky (một trong những người sáng lập Stack Exchange) là một hướng dẫn cho đồng bóng, không phải Git, nhưng đó là chương không, "Subversion Re-giáo dục" là hữu ích cho những người chuyển từ SVN sang bất kỳ hệ thống kiểm soát phiên bản phân tán nào , vì nó cho bạn biết những khái niệm SVN nào bạn (tạm thời) không học (hoặc stashxa , như người dùng Git có thể nói) để có thể quấn đầu bạn xung quanh phân tán khái niệm hệ thống kiểm soát phiên bản và quy trình công việc thành ngữ được thiết lập để làm việc với chúng.

Vì vậy, bạn có thể đọc chương số 0 đó và chủ yếu chỉ thay thế từ "đồng bóng" bằng "Git" và từ đó chuẩn bị chính xác bản thân và tâm trí của bạn cho Git.

Bản in tốt

(Bạn có thể bỏ qua điều này cho bây giờ.) Trong khi lanh lợi và Git được nhiều hơn nữa tương tự với nhau hơn để SVN, có là một số khác biệt về khái niệm giữa chúng, vì vậy một số các báo cáo và tư vấn trong "Subversion Re-giáo dục" sẽ trở thành sai về mặt kỹ thuật khi thay thế "đồng bóng" bằng "Git":

• Trong khi nội bộ theo dõi và lưu trữ các thay đổi, Git nội bộ theo dõi và lưu trữ các bản sửa đổi (tức là trạng thái của nội dung của cây thư mục), giống như Subversion. Nhưng khác với Subversion Git thực hiện hợp nhất bằng cách xem xét sự khác biệt giữa từng nhánh liên quan và sửa đổi tổ tiên chung (hợp nhất 3 điểm thực sự), do đó, kết quả tương tự như đối với đồng bóng: Việc hợp nhất dễ dàng hơn và ít lỗi hơn -prone hơn ở SVN.
• Mặc dù bạn có thể phân nhánh trong Git bằng cách nhân bản kho lưu trữ (theo thông lệ trong đồng bóng), việc tạo một nhánh mới trong kho Git là phổ biến hơn nhiều. .

Trong SVN, mọi thứ đều là một thư mục (nhưng bạn không nhất thiết phải coi nó như vậy)

Nhưng tôi đã làm phiền bạn. Bạn đã nói?

Trong SVN tôi thường kiểm tra trên máy cục bộ của mình một repo, bao gồm tất cả các chi nhánh trong dự án của tôi và tôi thường chọn thư mục cho chi nhánh mà tôi quan tâm và làm việc ở đó.

Nếu, bằng cách đó, bạn có nghĩa là bạn đã kiểm tra thư mục gốc của kho SVN (hoặc bất kỳ thư mục nào khác tương ứng với nhiều hơn trunkhoặc cho một nhánh, ví dụ như trong bố cục repo SVN thông thường, branchesthư mục chứa tất cả các nhánh không phải là thân cây) Tôi dám nói có lẽ bạn đã sử dụng SVN sai (ish) hoặc ít nhất là lạm dụng một chút thực tế là các thân cây, nhánh và thẻ được xếp thành một không gian tên (mặc dù phân cấp) cùng với các thư mục trong phiên bản / codebase.

Mặc dù có thể thay đổi song song một số chi nhánh SVN, nhưng đó là AFAIK không phải là cách sử dụng SVN. (Mặc dù tôi không chắc về những nhược điểm cụ thể hoạt động như thế có thể có.)

Trong Git, chỉ có thư mục là thư mục

Mỗi bản sao của kho lưu trữ Git đều là kho lưu trữ Git: Theo mặc định, nó nhận được một bản sao đầy đủ về lịch sử của kho lưu trữ gốc, bao gồm tất cả các sửa đổi, các nhánh và thẻ. Nhưng nó sẽ giữ tất cả theo cách của chúng tôi: Git lưu trữ nó trong cơ sở dữ liệu sắp xếp dựa trên tệp, nằm trong thư mục .git/con ẩn của thư mục gốc của kho lưu trữ .

Nhưng các tập tin không ẩn mà bạn nhìn thấy trong thư mục kho lưu trữ là gì?

Khi bạn git clonemột kho lưu trữ, Git làm một số điều. Roughly:

1. Nó tạo thư mục đích và trong đó, .git/thư mục con với "cơ sở dữ liệu"
2. Nó chuyển các tham chiếu (thẻ, nhánh, v.v.) của cơ sở dữ liệu của kho lưu trữ gốc và tạo một bản sao của chúng trong cơ sở dữ liệu mới, đặt cho chúng một tên được sửa đổi một cách rõ ràng đánh dấu chúng là các tham chiếu "từ xa".
3. Nó chuyển tất cả các sửa đổi (tức là trạng thái cây tệp) mà các tham chiếu này trỏ đến, cũng như tất cả các sửa đổi mà các sửa đổi này trỏ trực tiếp hoặc quá cảnh (cha mẹ và tổ tiên của chúng) vào cơ sở dữ liệu mới và lưu trữ chúng, để các tham chiếu từ xa mới thực sự chỉ vào một cái gì đó có sẵn trong kho lưu trữ mới.
4. Nó tạo ra một nhánh cục bộ theo dõi sửa đổi từ xa tương ứng với nhánh mặc định của kho lưu trữ gốc (thường master).
5. Nó kiểm tra chi nhánh địa phương.

Bước cuối cùng đó có nghĩa là Git tra cứu bản sửa đổi mà nhánh này trỏ tới và giải nén cây tệp được lưu trữ ở đó (cơ sở dữ liệu sử dụng một số phương tiện nén và khử trùng lặp) vào thư mục gốc của kho lưu trữ. Thư mục gốc đó và tất cả các thư mục con của nó (không bao gồm .gitthư mục con đặc biệt ) được gọi là "bản sao làm việc" của kho lưu trữ của bạn. Đó là nơi bạn tương tác với nội dung của bản sửa đổi / chi nhánh hiện đang thanh toán. Chúng chỉ là các thư mục và tập tin bình thường. Tuy nhiên, để tương tác với kho lưu trữ ("cơ sở dữ liệu" của các sửa đổi và tham chiếu), bạn sử dụng gitcác lệnh.

Xem các nhánh Git và tương tác với các nhánh Git

Hiện tại tôi đang nhân bản một repo và nhân bản một chi nhánh cụ thể bằng gitk.

Phiên bản của gitktôi có thể không lưu trữ bản sao. Nó chỉ có thể xem lịch sử repo và tạo các chi nhánh và kiểm tra các chi nhánh. Ngoài ra, không có "nhân bản" một chi nhánh. Bạn chỉ có thể sao chép kho.

Ý bạn là bạn sao chép một repo bằng cách sử dụng git clone ...và sau đó, sử dụng gitk, kiểm tra một chi nhánh?

Thư mục dự án chỉ chứa nội dung cho nhánh đó và tôi không thể thấy tất cả các nhánh như trong SVN, điều này hơi khó hiểu đối với tôi.

[...]

• Tôi muốn biết liệu quy trình git mà tôi mô tả có "chuẩn" hay không và một số cách chính xác [...]

Vâng, đó là tiêu chuẩn khá:

• Nhân bản một kho lưu trữ bằng cách sử dụng git clone ...
• Kiểm tra chi nhánh bạn muốn làm việc với git checkout ...hoặc sử dụng một công cụ đồ họa nhưgikt

Tôi không thể tìm thấy một cách dễ dàng để xem tất cả các chi nhánh trong kho lưu trữ cục bộ của mình bằng GIT.

• [...] Hoặc tôi đang thiếu smt.

Có lẽ:

• bạn có thể liệt kê các chi nhánh địa phương với git branch
• bạn có thể liệt kê các nhánh từ xa có git branch -rhoặc tất cả các nhánh vớigit branch -a

• bạn có thể sử dụng gitkđể xem toàn bộ lịch sử (tất cả các thẻ chi nhánh, v.v. mà repo địa phương của bạn biết) bằng cách gọi nó với

  gitk --all
  

Cách làm việc với nhiều nhánh song song

• Ngoài ra, tôi muốn biết làm thế nào để xử lý một quá trình mà tôi cần phải làm việc trên hai nhánh cùng một lúc trong trường hợp, ví dụ, tôi cần tạo một hotfix trên master nhưng cũng giữ nội dung của một nhánh khác.

Có nhiều kịch bản khác nhau ở đây:

Một thay đổi mới (chưa được tạo) cần được áp dụng cho nhiều chi nhánh

Sử dụng quy trình công việc này:

1. Tạo một nhánh mới ctừ một bản sửa đổi đã có trong tổ tiên của tất cả các nhánh này (ví dụ: bản sửa đổi đã đưa ra lỗi khi thay đổi sẽ là một lỗi) hoặc từ một bản sửa đổi mà (bao gồm tất cả các tổ tiên của nó) được chấp nhận để giới thiệu Tất cả những nhánh này.
2. Thực hiện và cam kết thay đổi trên chi nhánh mới đó c.

3. Đối với mỗi chi nhánh bcần thay đổi:

   1. Kiểm tra b:

      git checkout b
      

   2. Hợp nhất cthành b:

      git merge c
      

4. Xóa chi nhánh c:

   git branch --delete c
   

Một sự thay đổi hiện tại là cần thiết trên một nhánh khác

(... nhưng không có các thay đổi khác được thực hiện tại nơi thay đổi đó nằm)

1. Kiểm tra chi nhánh nơi cần thay đổi
2. Cherry-pick (các) phiên bản thực hiện thay đổi, theo thứ tự

Trên một nhánh a, bạn muốn thay đổi một hoặc một số tệp thành trạng thái chính xác mà chúng có trên một nhánh khácb

1. Thủ tục thanh toán a

2. Lấy nội dung tập tin từ chi nhánh b:

   git checkout b -- path/to/a/file.txt path/to/another/file.cpp or/even/a/complete/directory/ ...
   

   (Khác với git checkoutkhông đường đi, điều này sẽ không chuyển sang chi nhánh b, chỉ nhận được các nội dung tập tin yêu cầu từ đó. Những tập tin này có thể hoặc có thể chưa tồn tại trên a. Nếu họ làm, họ đang ghi đè bằng nội dung của họ trên b.)

Trong khi làm việc trên một nhánh, bạn muốn xem mọi thứ ở nhánh khác như thế nào

Kiểm tra chi nhánh bạn muốn làm việc.

Sau đó, để nhìn vào chi nhánh khác,

• sử dụng các công cụ đồ họa cho phép bạn xem nội dung của các bản sửa đổi hiện chưa được kiểm tra (ví dụ: gitkcố gắng chuyển các nút radio từ "bản vá" sang "cây")
• hoặc sao chép kho lưu trữ vào một thư mục tạm thời và kiểm tra các nhánh khác ở đó
• hoặc sử dụng git worktreeđể tạo một thư mục làm việc riêng của cùng một kho lưu trữ (tức là cũng sử dụng cơ sở dữ liệu trong .git/thư mục của kho lưu trữ cục bộ hiện tại của bạn) nơi bạn có thể kiểm tra chi nhánh khác

Trong SVN tôi thường kiểm tra trên máy cục bộ của mình một repo, bao gồm tất cả các chi nhánh trong dự án của tôi và tôi thường chọn thư mục cho chi nhánh mà tôi quan tâm và làm việc ở đó.

Trừ khi bạn kiểm tra thư mục trên thân cây, trong Subversion, bạn thường không có tất cả các chi nhánh có sẵn tại địa phương. Trong Git, tất cả nội dung (cam kết, tin nhắn, chi nhánh, v.v.) luôn được sao chép vào mọi bản sao.

Hiện tại tôi đang nhân bản một repo và nhân bản một chi nhánh cụ thể bằng gitk.

Không thể, xem ở trên. Bạn có thể git checkout branch-name, nhưng bạn không thể git clone something branch-name. Trong Subversion, các nhánh là các thư mục. Trong Git, các nhánh là con trỏ tới một cam kết.

Tôi không thể tìm thấy một cách dễ dàng để xem tất cả các chi nhánh trong kho lưu trữ cục bộ của mình bằng GIT.

Chạy đi git branch. Theo mặc định, nó chỉ hiển thị các chi nhánh địa phương. Sử dụng git branch --remoteđể xem các chi nhánh từ xa.

Vì điều này được gắn thẻ với git, tôi hy vọng rằng sự thiếu hiểu biết về SVN của tôi là không thể bỏ qua.

Hiện tại tôi đang nhân bản một repo và nhân bản một chi nhánh cụ thể bằng gitk.

Bạn đang nhân bản toàn bộ kho lưu trữ từ xa không chỉ là một nhánh cụ thể.

Kho lưu trữ được tưởng tượng tốt nhất như một cơ sở dữ liệu, vì vậy bạn đang tạo một bản sao của trạng thái hiện tại của cơ sở dữ liệu từ xa. Nhưng sau đó, bạn đang làm việc trên bản sao của cơ sở dữ liệu đó; nếu bạn cam kết, bạn thay đổi cơ sở dữ liệu địa phương của bạn.

Các fetchlệnh được sử dụng để giữ cho cơ sở dữ liệu địa phương đồng bộ với một điều khiển từ xa.

Thông thường từ cơ sở dữ liệu cục bộ đó, bạn kiểm tra một chi nhánh để làm việc. Điều này không có gì khác giống như một điểm đánh dấu nội bộ cho git, nơi công việc hiện tại của bạn bắt đầu.

Giả sử, bạn đang làm việc trên một kho lưu trữ đơn giản, nơi không có chi nhánh bên cạnh master, bạn có thể xem qua .gitthư mục để tiết lộ "ma thuật":

Giả sử lần cam kết cuối cùng của bạn là (bạn master) 182e8220b404437b9e43eb78149d31af79040c66, bạn sẽ tìm thấy chính xác điều đó bên dưới cat .git/refs/heads/master.

Từ đó bạn rẽ nhánh ra một nhánh mới git checkout -b mybranch, bạn sẽ tìm thấy cùng một con trỏ trong tệp cat .git/refs/heads/mybranch.

Chi nhánh không có gì nhiều hơn "con trỏ". Điểm đánh dấu "làm việc" được gọi là a HEAD.

Nếu bạn muốn biết bạn HEADđang ở đâu:

cat .git/HEADtrong đó nói ví dụ: ref: refs/heads/mybranchlần lượt điểm ( cat .git/refs/heads/mybranch) đến hàm băm xác nhận78a8a6eb6f82eae21b156b68d553dd143c6d3e6f

Các cam kết thực tế được lưu trữ trong objectsthư mục (chủ đề của chính nó như thế nào).

Thư mục dự án chỉ chứa nội dung cho nhánh đó và tôi không thể thấy tất cả các nhánh như trong SVN, điều này hơi khó hiểu đối với tôi.

Đừng nhầm lẫn working directoryvới "cơ sở dữ liệu git" nói chung. Như tôi đã nói ở trên, thư mục làm việc của bạn chỉ là một ảnh chụp nhanh (có thể) một tập hợp con.

Giả sử bạn có các nhánh khác nhau, thư mục làm việc của bạn chỉ dành riêng để làm việc trên nhánh đó (mặc dù bạn có thể đặt công việc từ đó ở nơi khác).

Thông thường, nếu bạn muốn xem, những nhánh nào được xác định cho dự án, bạn có khả năng

• git branch cho các chi nhánh địa phương
• git branch --remote cho các chi nhánh từ xa
• git branch -a cho cả hai

(hoặc git branch -v)

Vì git là một hệ thống kiểm soát phiên bản phân tán, không chỉ có thể, mà còn được khuyến khích, để tạo các nhánh khác nhau cục bộ / từ xa.

Quy trình công việc điển hình của tôi là:

• rẽ nhánh một nhánh
• nhánh một nhánh WIP (đang tiến hành) từ đó
• làm việc như bạn muốn - ngay cả khi bạn cam kết sau một dòng duy nhất; nó không quan trọng

Khi tính năng hoàn tất:

• squash / làm lại WIPnhánh (với rebasing tương tác) = thực hiện một cam kết duy nhất từ ​​đó
• hợp nhất WIPnhánh vào nhánh tính năng và cung cấp rằng (nếu bạn làm việc với github, ưu đãi đó sẽ được gọi là "yêu cầu kéo") để tích hợp vào nhánh ổn định (chính).

Ngoài ra, tôi muốn biết làm thế nào để xử lý một quá trình mà tôi cần wprl trên hai nhánh cùng một lúc trong trường hợp, ví dụ, tôi cần phải tạo một hotfix trên master nhưng cũng giữ nội dung của một nhánh khác.

Nó phụ thuộc vào cách cấu trúc dự án của bạn:

Nói rằng bạn có một chủ ổn định. Và các tính năng chỉ được phát triển từ nhánh ổn định đó - vì vậy nó thường đứng sau một nhánh tính năng. Sau đó, bạn sẽ có một cam kết cuối cùng về chủ sẽ là gốc của nhánh tính năng.

Sau đó, bạn sẽ làm cho một cam kết về chi nhánh tổng thể và có thể quyết định, cho dù để hợp nhất cả hai chi nhánh với nhau hoặc để rebase (mà là một loại hợp nhất cho người dùng có nhu cầu cao như vậy để nói).

Hoặc bạn luôn có thể thực hiện các thay đổi trên các nhánh (ví dụ master) và chuyển chúng sang các nhánh khác.

Quy ước tên đề xuất là gì để tạo các thư mục bao gồm nhánh được sao chép từ repo trong GIT, ví dụ myproject-Branchname

Điều đó phụ thuộc vào bạn.

Thông thường, bạn kết thúc với tên kho lưu trữ.

Nhưng có những dịp, khi điều này không muốn:

ví dụ: bạn sao chép oh-my-zsh với git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh Ở đây .oh-my-zshđược đặt tên rõ ràng là mục tiêu.

Git clone thực sự nhân bản toàn bộ kho lưu trữ, nhưng đặt thư mục làm việc của bạn thành mặc định (thường là chủ).

Bạn có thể thấy các nhánh khác sử dụng git branchđể xem các nhánh cục bộ hoặc git branch -rđể xem các nhánh từ xa và sau đó git checkoutchuyển sang một nhánh hiện có hoặc tạo một nhánh mới dựa trên nhánh hiện tại.

Bạn nên đọc tài liệu git để biết thêm chi tiết và Atlassian cũng có một số bài viết hay về nó.

Các chi nhánh trong git và svn là những thứ khác nhau cơ bản.

Trong svn một nhánh (hoặc một thẻ) là một thư mục trong repo.

Trong git, một nhánh (hoặc một thẻ) là một con trỏ tới một cam kết.

Với svn bạn có thể nếu bạn muốn kiểm tra root của repo. Điều này có nghĩa là bạn có tất cả các chi nhánh và thẻ được kiểm tra cùng một lúc. Afaict đây không phải là cách bình thường để sử dụng svn.

Một nhánh git không phải là một thư mục, vì vậy không có gì tương đương để "kiểm tra gốc của repo". Có một số hỗ trợ cho nhiều cây làm việc, vì vậy tôi đoán bạn có thể cùng nhau viết một kịch bản để kiểm tra mọi chi nhánh cùng một lúc nếu bạn thực sự muốn nhưng nó sẽ là một suy nghĩ khá bất thường.

Hơn nữa với SVN có chính xác một repo. Với git mỗi nhà phát triển có repo riêng của họ. Điều này có nghĩa là các nhà phát triển có thể làm việc ngoại tuyến nhưng điều đó cũng có nghĩa là các nhà phát triển khác nhau có thể có một ý tưởng khác nhau về những gì trên mỗi chi nhánh.

Nhờ có các thư mục và nhờ các nhánh svn của mô hình lịch sử tuyến tính đơn giản của svn có lịch sử mạnh mẽ. Nếu bạn muốn biết những gì trên chi nhánh x vào ngày y, bạn có thể dễ dàng hỏi câu hỏi đó.

Mặt khác, các chi nhánh Git không thực sự có lịch sử. Có "reflog" nhưng nó được dự định là một cơ chế khắc phục thảm họa hơn là một lịch sử lâu dài. Cụ thể, reflog không thể được đọc từ xa và bị tắt theo mặc định cho repos trần.

Cam kết tất nhiên có lịch sử nhưng những lịch sử đó không đủ để trả lời câu hỏi "cái gì trên nhánh x của repo y vào ngày z".

Tôi không thể tìm thấy một cách dễ dàng để xem tất cả các chi nhánh trong kho lưu trữ cục bộ của mình bằng Git.

Bạn có thể liệt kê tất cả các chi nhánh địa phương bằng cách gõ "git chi nhánh".

Bạn có thể liệt kê tất cả các chi nhánh cả cục bộ và từ xa bằng cách sử dụng "git chi nhánh -a"

Ngoài ra, tôi muốn biết làm thế nào để xử lý một quá trình mà tôi cần phải làm việc trên hai nhánh cùng một lúc trong trường hợp, ví dụ, tôi cần tạo một hotfix trên master nhưng cũng giữ nội dung của một nhánh khác.

Một vài lựa chọn.

Bạn có thể cam kết thay đổi của mình trên "nhánh khác", chuyển sang làm chủ công việc của bạn ở đó và sau đó chuyển trở lại.

Bạn cũng có thể tạo một cây làm việc thêm. Google "git-worktree" để biết chi tiết về cú pháp.

Quy ước tên đề xuất để tạo các thư mục bao gồm nhánh được sao chép từ repo trong Git, ví dụ myproject-Branchname là gì?

Tôi không nghĩ có một quy ước được thành lập. Có nhiều cây làm việc được kiểm tra cùng một lúc là ngoại lệ không phải là quy tắc.