Git: SVN sang Git - chuẩn bị cho migration


Đăng ký nhận thông báo về những video mới nhất

Trong bài Tại sao dùng Git?, chúng tôi đã thảo luận về nhiều cách mà Git có thể giúp nhóm của bạn trở nên nhanh hơn.  Khi bạn đã quyết định thực hiện chuyển đổi, bước tiếp theo của bạn là tìm ra cách di chuyển quy trình phát triển hiện tại của bạn sang Git.

Bài viết này giải thích một số thay đổi lớn nhất bạn sẽ gặp phải khi chuyển nhóm của mình từ SVN sang Git. Điều quan trọng nhất cần nhớ trong quá trình di chuyển là Git không phải là SVN. Để nhận ra tiềm năng đầy đủ của Git, hãy cố gắng hết sức để mở ra những cách nghĩ mới về kiểm soát phiên bản.

Dành cho quản trị viên

Việc thông qua Git có thể mất từ ​​vài ngày đến vài tháng tùy thuộc vào quy mô nhóm của bạn. Phần này giải quyết một số mối quan tâm chính cho các nhà quản lý kỹ thuật khi nói đến việc đào tạo nhân viên về Git và di chuyển các kho lưu trữ từ SVN sang Git.

Các lệnh Git cơ bản

Git đã từng có một danh tiếng cho một đường cong học tập dốc. Tuy nhiên, những người duy trì Git đã liên tục đưa ra những cải tiến mới như mặc định hợp lý và thông điệp trợ giúp theo ngữ cảnh giúp quá trình lên máy bay trở nên dễ chịu hơn rất nhiều.

Atlassian cung cấp một loạt các hướng dẫn Git tự nhịp độ , cũng như các hội thảo trên web và các buổi đào tạo trực tiếp. Cùng nhau, những điều này sẽ cung cấp tất cả các tùy chọn đào tạo mà nhóm của bạn cần để bắt đầu với Git. Để giúp bạn bắt đầu, đây là danh sách một số lệnh Git cơ bản để giúp bạn tiếp tục với Git:

Nhiệm vụ Git Ghi chú Lệnh Git
Nói cho Git biết bạn là ai Định cấu hình tên tác giả và địa chỉ email sẽ được sử dụng với các cam kết của bạn. Lưu ý rằng Git loại bỏ một số ký tự (ví dụ: dấu chấm) từ user.name. git config --global user.name "Sam Smith" 
git config --global user.email sam@example.com
Tạo một kho lưu trữ cục bộ mới   git init
Kiểm tra một kho lưu trữ Tạo một bản sao làm việc của một kho lưu trữ cục bộ: git clone / path / to / repository
  Đối với một máy chủ từ xa, sử dụng: tên người dùng git clone @ host: / path / to / repository
Thêm các tập tin Thêm một hoặc nhiều tệp để dàn (chỉ mục): git thêm <tên tệp> git thêm *
Cam kết Cam kết thay đổi thành đầu (nhưng chưa có kho lưu trữ từ xa): git commit -m "Thông điệp cam kết"
  Cam kết bất kỳ tệp nào bạn đã thêm bằng git add và cũng cam kết mọi tệp bạn đã thay đổi kể từ đó: cam kết -a
Đẩy Gửi các thay đổi đến nhánh chính của kho lưu trữ từ xa của bạn: git đẩy nguồn gốc
Trạng thái Liệt kê các tệp bạn đã thay đổi và những tệp bạn vẫn cần thêm hoặc cam kết: tình trạng git
Kết nối với kho lưu trữ từ xa Nếu bạn chưa kết nối kho lưu trữ cục bộ của mình với máy chủ từ xa, hãy thêm máy chủ để có thể đẩy vào kho: git từ xa thêm nguồn gốc <máy chủ>
  Liệt kê tất cả các kho lưu trữ từ xa được cấu hình hiện tại: git từ xa -v
Chi nhánh Tạo một nhánh mới và chuyển sang nó: kiểm tra git -b <tên chi nhánh>
  Chuyển từ chi nhánh này sang chi nhánh khác: kiểm tra git <tên chi nhánh>
  Liệt kê tất cả các chi nhánh trong repo của bạn và cũng cho bạn biết bạn đang ở chi nhánh nào: chi nhánh git
  Xóa nhánh tính năng: nhánh git -d <tên nhánh>
  Đẩy chi nhánh vào kho lưu trữ từ xa của bạn để người khác có thể sử dụng nó: nguồn gốc git đẩy <tên nhánh>
  Đẩy tất cả các chi nhánh vào kho lưu trữ từ xa của bạn: git đẩy - nguồn gốc
  Xóa một nhánh trên kho lưu trữ từ xa của bạn: nguồn gốc git đẩy: <tên nhánh>
Cập nhật từ kho lưu trữ từ xa Tìm nạp và hợp nhất các thay đổi trên máy chủ từ xa vào thư mục làm việc của bạn: kéo git
  Để hợp nhất một nhánh khác vào nhánh hoạt động của bạn: hợp nhất git <tên nhánh>
  Xem tất cả các xung đột hợp nhất: Xem các xung đột đối với tệp cơ sở: Xem trước các thay đổi, trước khi hợp nhất: git diff 
git diff --base <tên tệp> 
git diff <sourcebranch> <targetbranch>
  Sau khi bạn đã giải quyết thủ công mọi xung đột, bạn đánh dấu tệp đã thay đổi: git thêm <tên tệp>
Thẻ Bạn có thể sử dụng gắn thẻ để đánh dấu một thay đổi quan trọng, chẳng hạn như một bản phát hành: thẻ git 1.0.0 <commitID>
  CommitId là ký tự hàng đầu của ID bộ thay đổi, tối đa 10, nhưng phải là duy nhất. Nhận ID bằng cách sử dụng: nhật ký git
  Đẩy tất cả các thẻ vào kho lưu trữ từ xa: git đẩy --tags nguồn gốc
Hoàn tác các thay đổi cục bộ Nếu bạn làm hỏng, bạn có thể thay thế các thay đổi trong cây làm việc của mình bằng nội dung cuối cùng trong đầu: Các thay đổi đã được thêm vào chỉ mục, cũng như các tệp mới, sẽ được giữ lại. kiểm tra git - <tên tệp>
  Thay vào đó, để loại bỏ tất cả các thay đổi và cam kết cục bộ của bạn, hãy tìm nạp lịch sử mới nhất từ ​​máy chủ và trỏ nhánh chính cục bộ của bạn vào đó, thực hiện việc này: git lấy nguồn gốc 
git reset - gốc / chủ
Tìm kiếm Tìm kiếm thư mục làm việc cho foo (): git grep "foo ()"

Công cụ di chuyển Git

Có một số công cụ có sẵn để giúp bạn di chuyển các dự án hiện tại của mình từ SVN sang Git, nhưng trước khi bạn quyết định sử dụng công cụ nào, bạn cần tìm ra cách bạn muốn di chuyển mã của mình. Lựa chọn của bạn là:

  • Di chuyển toàn bộ cơ sở mã của bạn sang Git và ngừng sử dụng SVN hoàn toàn.
  • Không di chuyển bất kỳ dự án hiện có nào sang Git, nhưng sử dụng Git cho tất cả các dự án mới.
  • Di chuyển một số dự án của bạn sang Git trong khi tiếp tục sử dụng SVN cho các dự án khác.
  • Sử dụng SVN và Git đồng thời trên cùng một dự án.

Chuyển đổi hoàn toàn sang Git giới hạn sự phức tạp trong quy trình phát triển của bạn, vì vậy đây là tùy chọn ưa thích. Tuy nhiên, điều này không phải lúc nào cũng có thể xảy ra ở các công ty lớn hơn với hàng chục nhóm phát triển và có khả năng hàng trăm dự án. Trong những tình huống này, một phương pháp lai là một lựa chọn an toàn hơn.

Sự lựa chọn của bạn về (các) công cụ di chuyển phụ thuộc phần lớn vào chiến lược nào bạn chọn. Một số công cụ di chuyển SVN-Git phổ biến nhất được giới thiệu dưới đây.

Tập lệnh di chuyển của Atlassian

Nếu bạn quan tâm đến việc thực hiện chuyển đổi đột ngột sang Git, tập lệnh di chuyển của Atlassian là một lựa chọn tốt cho bạn. Các tập lệnh này cung cấp tất cả các công cụ bạn cần để chuyển đổi các kho lưu trữ SVN hiện tại của bạn thành các kho lưu trữ Git. Lịch sử Git gốc kết quả đảm bảo bạn sẽ không cần phải xử lý bất kỳ vấn đề tương tác SVN-Git nào sau quá trình chuyển đổi.

Chúng tôi đã cung cấp một hướng dẫn kỹ thuật hoàn chỉnh cho việc sử dụng các tập lệnh này để chuyển đổi toàn bộ cơ sở mã của bạn thành một bộ sưu tập các kho Git. Hướng dẫn này giải thích mọi thứ từ trích xuất thông tin tác giả SVN đến tổ chức lại các cấu trúc kho lưu trữ SVN không chuẩn.

Plugin SVN Mirror for Stash (nay là Bitbucket Server)

SVN Mirror for Stash là một plugin Bitbucket Server cho phép bạn dễ dàng duy trì một cơ sở mã lai hoạt động với cả SVN và Git. Không giống như các tập lệnh di chuyển của Atlassian, SVN Mirror for Stash cho phép bạn sử dụng đồng thời Git và SVN trên cùng một dự án bao lâu tùy thích.

Giải pháp thỏa hiệp này là một lựa chọn tuyệt vời cho các công ty lớn hơn. Nó cho phép áp dụng Git gia tăng bằng cách cho phép các nhóm khác nhau di chuyển quy trình công việc một cách thuận tiện.

Git-SVN là gì?

Công cụ git-svn là giao diện giữa kho lưu trữ Git cục bộ và kho lưu trữ SVN từ xa. Git-svn cho phép các nhà phát triển viết mã và tạo các xác nhận cục bộ bằng Git, sau đó đẩy chúng lên một kho lưu trữ SVN trung tâm với hành vi kiểu cam kết svn. Điều này là tạm thời, nhưng rất hữu ích khi tranh luận về việc chuyển đổi từ SVN sang Git. 

git svn là một lựa chọn tốt nếu bạn không chắc chắn về việc chuyển sang Git và muốn cho một số nhà phát triển của bạn khám phá các lệnh Git mà không cần phải di chuyển toàn bộ. Nó cũng hoàn hảo cho giai đoạn huấn luyện, thay vì chuyển đổi đột ngột, nhóm của bạn có thể dễ dàng thực hiện nó bằng các lệnh Git cục bộ trước khi lo lắng về quy trình làm việc cộng tác.

Lưu ý rằng git svn chỉ nên là một giai đoạn tạm thời của quá trình di chuyển của bạn. Vì nó vẫn phụ thuộc vào SVN cho phần phụ trợ, nên nó không thể tận dụng các tính năng Git mạnh hơn như quy trình cộng tác phân nhánh hoặc nâng cao.

Chiến lược triển khai

Di chuyển cơ sở mã của bạn chỉ là một khía cạnh của việc áp dụng Git. Bạn cũng cần xem xét cách giới thiệu Git với những người đứng sau cơ sở mã đó. Chuyên gia tư vấn bên ngoài, nhà vô địch Git nội bộ và đội phi công là ba chiến lược chính để chuyển đội ngũ phát triển của bạn sang Git.

Tư vấn Git bên ngoài

Chuyên gia tư vấn Git về cơ bản có thể xử lý quá trình di chuyển cho bạn với một khoản phí danh nghĩa. Điều này có lợi thế là tạo ra một quy trình công việc Git hoàn toàn phù hợp với nhóm của bạn mà không cần đầu tư thời gian để tự mình tìm ra nó. Nó cũng làm cho các tài nguyên đào tạo chuyên gia có sẵn cho bạn trong khi nhóm của bạn đang học Git. Các chuyên gia của Atlassian rất thuận lợi khi nói đến SVN để di chuyển Git và là một nguồn tốt để tìm nguồn cung ứng tư vấn Git.

Mặt khác, tự mình thiết kế và thực hiện quy trình công việc Git là một cách tuyệt vời để nhóm của bạn hiểu được hoạt động bên trong của quy trình phát triển mới của họ. Điều này tránh nguy cơ nhóm của bạn bị bỏ lại trong bóng tối khi chuyên gia tư vấn của bạn rời đi.

Vô địch Git nội bộ

Nhà vô địch Git là một nhà phát triển bên trong công ty của bạn, người rất hào hứng khi bắt đầu sử dụng Git. Tận dụng một nhà vô địch Git là một lựa chọn tốt cho các công ty có văn hóa nhà phát triển mạnh mẽ và các lập trình viên háo hức thoải mái khi được chấp nhận sớm. Ý tưởng là cho phép một trong các kỹ sư của bạn trở thành chuyên gia Git để họ có thể thiết kế quy trình công việc Git phù hợp với công ty của bạn và làm tư vấn nội bộ khi đến lúc chuyển phần còn lại của nhóm sang Git.

So với một nhà tư vấn bên ngoài, điều này có lợi thế là giữ chuyên môn Git của bạn trong nhà. Tuy nhiên, nó đòi hỏi một khoản đầu tư thời gian lớn hơn để đào tạo nhà vô địch Git đó và nó có nguy cơ chọn sai quy trình công việc Git hoặc thực hiện không chính xác.

Đội thí điểm

Tùy chọn thứ ba để chuyển sang Git là thử nghiệm nó trên một nhóm thử nghiệm. Điều này hoạt động tốt nhất nếu bạn có một nhóm nhỏ làm việc trong một dự án tương đối cô lập. Điều này có thể hoạt động tốt hơn nữa bằng cách kết hợp các chuyên gia tư vấn bên ngoài với các nhà vô địch Git nội bộ trong đội thí điểm để có được một chiến thắng kết hợp.

Điều này có lợi thế là yêu cầu mua từ toàn bộ nhóm của bạn và cũng hạn chế rủi ro chọn sai quy trình công việc, vì nó nhận được đầu vào từ toàn bộ nhóm trong khi thiết kế quy trình phát triển mới. Nói cách khác, nó đảm bảo bất kỳ phần còn thiếu nào được bắt gặp sớm hơn khi một nhà tư vấn hoặc nhà vô địch tự thiết kế quy trình công việc mới.

Mặt khác, sử dụng nhóm thí điểm có nghĩa là thời gian đào tạo và thiết lập ban đầu nhiều hơn: thay vì một nhà phát triển tìm ra quy trình làm việc mới, có cả một nhóm có khả năng tạm thời giảm năng suất trong khi họ cảm thấy thoải mái với quy trình làm việc mới. Tuy nhiên, nỗi đau ngắn hạn này hoàn toàn xứng đáng với lợi ích lâu dài.

Bảo mật và quyền

Kiểm soát truy cập là một khía cạnh của Git, nơi bạn cần suy nghĩ lại về cách bạn quản lý cơ sở mã của mình.

Trong SVN, bạn thường lưu trữ toàn bộ cơ sở mã của mình trong một kho lưu trữ trung tâm duy nhất, sau đó giới hạn quyền truy cập vào các nhóm hoặc cá nhân khác nhau theo thư mục. Trong Git, điều này là không thể: các nhà phát triển phải truy xuất toàn bộ kho lưu trữ để làm việc với nó. Bạn thường không thể truy xuất một tập hợp con của kho lưu trữ, như bạn có thể với SVN. quyền chỉ có thể được cấp cho toàn bộ kho Git.

Điều này có nghĩa là bạn phải chia kho lưu trữ SVN lớn, nguyên khối của mình thành nhiều kho Git nhỏ. Chúng tôi thực sự đã trải nghiệm điều này đầu tiên tại Atlassian khi  nhóm phát triển Jiracủa chúng tôi di chuyển đến Git. Tất cả các plugin Jira của chúng tôi từng được lưu trữ trong một kho lưu trữ SVN duy nhất, nhưng sau khi di chuyển, mỗi plugin kết thúc trong kho lưu trữ của riêng nó.

Hãy nhớ rằng Git được thiết kế để tích hợp an toàn các đóng góp mã từ hàng ngàn nhà phát triển Linux độc lập, do đó, nó chắc chắn cung cấp một số cách để thiết lập bất kỳ loại kiểm soát truy cập nào mà nhóm của bạn cần. Tuy nhiên, điều này có thể yêu cầu một cái nhìn mới về chu kỳ xây dựng của bạn.

Nếu bạn lo lắng về việc duy trì sự phụ thuộc giữa bộ sưu tập Git mới của mình, bạn có thể thấy lớp quản lý phụ thuộc trên Git hữu ích. Một lớp quản lý phụ thuộc sẽ giúp ích cho thời gian xây dựng vì khi dự án phát triển, bạn cần có bộ nhớ cache trong bộ nhớ cache để tăng tốc thời gian xây dựng. Một danh sách các công cụ lớp quản lý phụ thuộc được đề xuất cho mọi ngăn xếp công nghệ có thể được tìm thấy trong bài viết hữu ích này: "Git và dự án phụ thuộc" .

Cho các nhà phát triển

Kho lưu trữ cho mọi nhà phát triển

Là nhà phát triển, thay đổi lớn nhất bạn cần điều chỉnh là bản chất phân tán của Git. Thay vì một kho lưu trữ trung tâm duy nhất, mỗi nhà phát triển có bản sao riêng của toàn bộ kho lưu trữ. Điều này thay đổi đáng kể cách bạn cộng tác với các lập trình viên đồng nghiệp của bạn.

Thay vì kiểm tra kho lưu trữ SVN với thanh toán svn và nhận bản sao hoạt động, bạn sao chép toàn bộ kho Git vào máy cục bộ của mình bằng bản sao git.

Sự hợp tác xảy ra bằng cách di chuyển các nhánh giữa các kho với git đẩy, git fetch hoặc git pull. Chia sẻ thường được thực hiện ở cấp chi nhánh trong Git nhưng có thể được thực hiện ở cấp cam kết, tương tự như SVN. Nhưng trong Git, một cam kết đại diện cho toàn bộ trạng thái của toàn bộ dự án thay vì sửa đổi tệp. Vì bạn có thể sử dụng các chi nhánh trong cả Git và SVN, nên điểm khác biệt quan trọng ở đây là bạn có thể cam kết cục bộ với Git mà không cần chia sẻ công việc của mình. Điều này cho phép bạn thử nghiệm tự do hơn, hoạt động ngoại tuyến hiệu quả hơn và tăng tốc gần như tất cả các lệnh liên quan đến kiểm soát phiên bản.

Tuy nhiên, điều quan trọng là phải hiểu rằng kho lưu trữ từ xa không phải là một liên kết trực tiếp đến kho lưu trữ của người khác. Nó chỉ đơn giản là một dấu trang ngăn bạn khỏi phải nhập lại toàn bộ URL mỗi khi bạn tương tác với một kho lưu trữ từ xa. Cho đến khi bạn rõ ràng kéo hoặc đẩy một nhánh đến một kho lưu trữ từ xa, bạn sẽ làm việc trong một môi trường bị cô lập.

Sự điều chỉnh lớn khác cho người dùng SVN là khái niệm về kho lưu trữ từ xa cục bộ và từ xa. Các kho lưu trữ cục bộ nằm trên máy cục bộ của bạn và tất cả các kho lưu trữ khác được gọi là các kho lưu trữ từ xa. Mục đích chính của kho lưu trữ từ xa là làm cho mã của bạn có thể truy cập được với phần còn lại của nhóm và do đó không có sự phát triển tích cực nào diễn ra trong đó. Các kho lưu trữ cục bộ nằm trên máy cục bộ của bạn và đó là nơi bạn thực hiện tất cả việc phát triển phần mềm của mình.

Đừng sợ phân nhánh hoặc sáp nhập

Trong SVN, bạn cam kết mã bằng cách chỉnh sửa các tệp trong bản sao làm việc của mình, sau đó chạy svn commit để gửi mã đến kho lưu trữ trung tâm. Mọi người khác sau đó có thể kéo những thay đổi đó thành bản sao làm việc của riêng họ với bản cập nhật svn. Các chi nhánh SVN thường được dành cho các khía cạnh lớn, dài hạn của dự án vì sáp nhập là một thủ tục nguy hiểm có khả năng phá vỡ dự án.

Quy trình phát triển cơ bản của Git khác nhau nhiều. Thay vì bị ràng buộc vào một dòng phát triển duy nhất (ví dụ: thân cây /), cuộc sống xoay quanh việc phân nhánh và hợp nhất.

Khi bạn muốn bắt đầu làm việc với bất cứ điều gì trong Git, bạn tạo và kiểm tra một chi nhánh mới với thanh toán git -b <tên chi nhánh>. Điều này cung cấp cho bạn một dòng phát triển chuyên dụng, nơi bạn có thể viết mã mà không lo ảnh hưởng đến bất kỳ ai khác trong nhóm của bạn. Nếu bạn phá vỡ một cái gì đó ngoài việc sửa chữa, bạn chỉ cần ném nhánh đi với nhánh git -d <tên nhánh>. Nếu bạn xây dựng một cái gì đó hữu ích, bạn gửi yêu cầu kéo yêu cầu hợp nhất nó vào nhánh chính.

Quy trình công việc Git tiềm năng

Khi chọn quy trình làm việc Git, điều quan trọng là phải xem xét nhu cầu của nhóm bạn. Một quy trình công việc đơn giản có thể tối đa hóa tốc độ phát triển và tính linh hoạt, trong khi quy trình công việc phức tạp hơn có thể đảm bảo tính nhất quán và kiểm soát công việc cao hơn. Bạn có thể điều chỉnh và kết hợp các cách tiếp cận chung được liệt kê dưới đây để phù hợp với nhu cầu của bạn và các vai trò khác nhau trong nhóm của bạn. Một nhà phát triển cốt lõi có thể sử dụng các nhánh tính năng trong khi một nhà thầu làm việc từ một ngã ba chẳng hạn.

  • Một quy trình làm việc tập trung cung cấp các trận đấu gần nhất với quá trình SVN chung, vì vậy đó là một lựa chọn tốt để bắt đầu.
  • Dựa trên ý tưởng đó, sử dụng quy trình làm việc của nhánh tính năng cho phép các nhà phát triển giữ cho công việc của họ tiến triển tách biệt và các nhánh chia sẻ quan trọng được bảo vệ. Các nhánh tính năng cũng tạo thành cơ sở để quản lý các thay đổi thông qua các yêu cầu kéo.
  • Một workflow Gitflow là một cấu trúc mở rộng chính thức hơn với tính năng phân nhánh, làm cho nó một lựa chọn tuyệt vời cho các đội lớn hơn với chu kỳ phát hành được xác định rõ.
  • Cuối cùng, hãy xem xét một quy trình làm việc nếu bạn cần cách ly và kiểm soát tối đa các thay đổi hoặc có nhiều nhà phát triển đóng góp cho một kho lưu trữ.

Nhưng, nếu bạn thực sự muốn tận dụng tối đa Git như một nhóm chuyên nghiệp, bạn nên xem xét quy trình làm việc của nhánh tính năng. Đây là một quy trình làm việc thực sự phân tán, có độ an toàn cao, có khả năng mở rộng đáng kinh ngạc và nhanh nhẹn.

Phần kết luận

Chuyển nhóm của bạn sang Git có thể là một nhiệm vụ khó khăn, nhưng nó không phải như vậy. Bài viết này đã giới thiệu một số tùy chọn phổ biến để di chuyển cơ sở mã hiện tại của bạn, triển khai Git cho các nhóm phát triển của bạn và xử lý bảo mật và quyền. Chúng tôi cũng giới thiệu những thách thức lớn nhất mà các nhà phát triển của bạn nên chuẩn bị trong quá trình di chuyển.

Hy vọng rằng, bây giờ bạn có một nền tảng vững chắc để giới thiệu phát triển phân tán cho công ty của bạn, bất kể quy mô hoặc thực tiễn phát triển hiện tại của nó.

Đăng ký nhận thông báo về những video mới nhất
« Prev: Git: Stash
» Next: Git: Tiến hành chuyển từ SVN sang Git
Copied !!!