Android

Git, Bài 5: Sync lên Repo center và clone projects

Bạn cảm thấy project của mình quá hay và muốn open source nó cho mọi người cùng tham khảo? Hay công ty của bạn có một repo centre để chứa các projects của toàn thể tổ chức, và bạn sẽ đồng bộ hóa mã nguồn dự án của mình lên đó? Bài viết cuối cùng trong loạt bài về Git này sẽ giúp các bạn làm điều đó trong vòng 7 nốt nhạc trở xuống.

1. Sync project code lên Repo centre:

Ở đây, repo centre có nghĩa là nơi (mang tính “đám mây”) sẽ chứa project của bạn, có thể là GitHub, GitLab, SourceForge hay Repo nội bộ của tổ chức bạn. Nhưng cho dù trung tâm đó là gì đi nữa, thì việc sync project với Git không có gì khác biệt. Bước đầu tiên, quan trọng nhất, là bạn phải có kết nối mạng (internet hoặc intranet) tới máy chủ của Repo centre kia, bởi không kết nối được với server thì sync làm sao được? Thứ hai, hãy đảm bảo code của bạn đã ổn định rồi. Có thể đây là vơ-sần stable, snapshot, hay release candidate hay ổn hơn nữa là milestone, nhưng tốt nhất đừng sync code trong trạng thái đầy lỗi, trừ khi đó là trường hợp buộc cần phải làm, chẳng hạn như laptop của bạn sắp cạn pin.

Việc sync code được tiến hành dựa trên các commits. Vì vậy, hãy chắc chắn rằng bạn đã “chốt sổ” project của bạn với commit lần cuối. Nếu lần commit cuối cùng của cái Git ở project trên máy tính của bạn và Git trên server là giống nhau thì chúng không đồng bộ gì, tức nó sẽ báo “Nothing to change”, cho dù bạn đã thay đổi nội dung tất cả các tập tin trong project. Vì vậy, phải luôn nhớ rằng, “LUÔN COMMIT TRƯỚC KHI SYNC”.

Sau khi đã chốt code xong, trên Terminal, hay Command Prompt hoặc CMDER, bạn tiến hành “đẩy” lên. Và bạn có thể đoán được, động từ chúng ta dùng sẽ là “push”. Nhưng khoan, khi chúng ta tiến hành push là ta push một branch. Vì vậy, trước khi commit và push, bạn sẽ cần/nên “checkout” sang branch mà bạn sắp sửa tiến hành đồng bộ, và bạn commit chính là commit vào branch đó.

Nếu đây là lần đầu tiên bạn push lên, cũng như chưa nói cho Git biết là bạn sẽ push code đi đâu, thì giờ là lúc bạn nói cho nó biết. Rất đơn giản, bạn chỉ việc cóp URL trỏ tới thư mục project của bạn là được. Tuy nhiên, bạn phải nhớ là vị trí trên URL kia phải hoặc là đang trống, hoặc đó là nơi chứa đúng cái project của bạn. Để tiến hành gán remoteRepositoryURL cho project, bạn sẽ chạy các lệnh sau, đương nhiên Terminal đang đứng ở thư mục project của bạn. Ở đây tôi chọn tên remoteURL là origin, bạn có thể chọn tên khác nếu thích, thông thường, người ta hay đặt là origin hoặc upstream.

Trong đó, remoteRepositoryURL là URL trỏ tới nơi (sẽ) chứa project của bạn. Nếu cái vị trí đó đang chứa project khác thì nó sẽ báo lỗi bên dưới, và đương nhiên không có cách nào sync code vào đó.

Nếu nó không báo lỗi trên, tức là mọi chuyện đã “thuận buồm xuôi gió rồi”, thì tốt nhất bạn nên xác nhận lại lần nữa cho chắc. Câu lệnh bên dưới có đi kèm output để bạn dễ so sánh. Trong đó, remoteRepositoryURL chính là tham số bạn đã truyền khi add origin.

Khi mọi thứ đã chắc ăn rồi, thì (cuối cùng cũng tới) bạn sẽ tiến hành push lên origin.

Trong đó, branchName chính là tên branch mà bạn sẽ tiến hành push. Không nhất thiết là bạn phải push nhánh master, mà nó có thể là bất kì nhánh nào mà bạn muốn, chẳng hạn, là nhánh code bạn đang được phân công để thực hiện. Tuy nhiên, bạn cần duy trì nhánh master trên repo. Do đó, nếu đây là lần đầu push code và chưa tồn tại nhánh master trên repo, thì bạn nên push nhánh master trước, xong xuôi rồi thì tới nhánh bạn đang thao tác. Vd tôi push nhánh master lên origin thì tôi sẽ gõ:

Việc sync code không mất quá nhiều thời gian, vì thứ nhất, nó diễn ra theo hướng đa luồng, và thứ hai, nó tận dụng được sức mạnh của Git: chỉ thay đổi những gì có thay đổi mà thôi. Do vậy, nếu project nặng tới 250MB mà chỉ mất có 10 giây để sync với tốc độ internet chậm rì thì bạn cũng không nên lo lắng. Code của bạn vẫn sync như bình thường.

2. Thay đổi remoteURL:

Bạn có thể thêm hoặc thay đổi hoặc xóa luôn remoteRepositoryURL một cách thoải mái. Chẳng hạn bây giờ bạn muốn chuyển từ GitHub sang GitLab, hoặc đơn giản hơn là bạn muốn lưu project lên nhiều nơi. Điều vui mừng là Git đã có hỗ trợ các lệnh để chiều ý bạn.

Thực tế thao tác đầu tiên, tức là add origin thực chất là thêm một remoteRepositoryURL và gán cho nó biệt danh là origin. Bây giờ, tôi add thêm một newRemoteRepositoryURL và đặt biệt danh cho nó là upstream thì tôi làm tương tự:

Còn push? Cũng tương tự thôi. Lần này không push lên origin thì push lên upstream, và giả sử như tôi sẽ push nhánh backend thì tôi sẽ chạy lệnh sau:

Trong trường hợp bạn muốn đổi luôn origin thành newRemoteRepositoryURL thì Git cũng có cách. set-url là động từ mà bạn sẽ sử dụng. Cụ thể:

Xóa một remoteURL cũng không có gì quá khó khăn. Chẳng hạn tôi sẽ xóa upstream đi vì tôi không cần nó nữa:

Git cũng hỗ trợ đặt lại tên. Và như các bạn có thể đoán được, bạn sẽ dùng động từ rename, với hai tham số phía sau là tên cũ và tên mới. Ví dụ:

3. Clone project có sẵn về máy:

Đây có lẽ là thao tác dễ dàng nhất. Động từ lần này sẽ là clone, tức là nhân bản. Để nhân bản một project, bạn đương nhiên phải biết nó ở đâu, và ý tôi là bạn phải có cái remoteURL của nó để truyền vào làm tham số của clone. Yêu cầu là bạn phải cd vào thư mục đích mà bạn muốn.

Để đồng bộ project đã được clone xuống với phiên bản trên repo của nó (thao tác này có vẻ là đi ngược lại với push), mục đích là cập nhật code, thì bạn không cần clone lại, mà chỉ cần fetch mà thôi. Tuy nhiên, việc fetch code không có nghĩa là nó sẽ commit để đồng bộ cho bạn luôn đâu. Do đó, tôi khuyến nghị các bạn nên pull luôn cho gọn.

Để đồng bộ các nhánh lên lại repo thì bạn lại sẽ thực hiện các thao tác trong phần 1 tôi vừa trình bày. Quá dễ phải không. Nếu câu trả lời là không, bạn chưa hiểu lắm những gì tôi vừa trình bày, bạn có thể đọc các hướng dẫn rất hay của GitHub tại đây.

4. Một số Git Repo Centre nổi tiếng:

GitHub có lẽ là cái tên nổi cộm nhất. Được thành lập vào cuối 2007 đầu 2008, GitHub phát triển vô cùng nhanh chóng và hiện đã trở thành Repo Centre phổ biến nhất trong giới coder. Cái hay nhất của GitHub, theo tôi, là tốc độ truyền tải cũng như họ có nhiều máy chủ để lưu trữ các bản sao của dữ liệu. Điều này giúp các projects của bạn được an toàn, cũng như được đồng bộ với tốc độ cao nhất có thể. Ngoài ra, bạn còn được phép tạo một trang web MIỄN PHÍKHÔNG GIỚI HẠN VỀ BĂNG THÔNG được host trực tiếp trên GitHub nữa. Quá tuyệt vời. Tuy nhiên, cái gì cũng có hai mặt, và dịch vụ chất lượng hàng đầu của họ không phải sinh ra là để biếu không (vì bản thân họ là công ty cũng như GitHub không có quảng cáo). Bạn không thể chứa các project mang tính bí mật (private) trên đó mà không chuyển sang gói trả phí. Và nếu bạn là người dùng “thầy chùa”, mặc dù khả năng mất code là vô cùng nhỏ nhoi, nhưng lỡ có mất thì họ sẽ không hỗ trợ phục hồi cho bạn. Để tham khảo về mức giá cũng như các khả năng của các gói trả phí, hãy click vào đây.

GitLab là cái tên thứ hai tôi muốn nhắc tới. Nguyên tắc hoạt động của GitLab cũng tương tự như GitHub, và cũng có gói miễn phí mặc dù cũng không có hỗ trợ về mất mát. Nhưng cái hay và điều làm tôi phải kể tới họ trong bài này là việc họ hỗ trợ private repos ngay trong gói miễn phí. Cũng như GitHub, họ cũng có hỗ trợ host static website tại máy chủ của họ. Mặc dù vậy, gần đây tôi nghe đồn đại là việc mất code hay xảy ra trên GitLab mặc dù các repos của tôi chưa hề bị ảnh hưởng nên bản thân tôi không thể kết luận là có tình trạng mất code. Họ cũng không có số lượng máy chủ rộng rãi như GitHub nên khả năng rủi ro có phần cao hơn đôi chút, cũng như việc đồng bộ với các máy tính ở VN sẽ khó khăn hơn nhiều khi bài hát “Đứt cáp AAG” lại được cất lên. Nhưng dù vậy, tôi vẫn khuyến nghị các bạn dùng qua dịch vụ của cty được thành lập vào năm 2011 này, đặc biệt là để host các projects mà bạn không công khai mã nguồn. Để tham khảo các gói dịch vụ, bao gồm mức giá và các hỗ trợ, hãy tham khảo ở đây.

SourceForge là cái tên cuối cùng mà tôi đề cập. So với hai đàn em bên trên thì SourceForge là người của thế kỉ trước, vì nó được thành lập vào năm 1999. Chính vì thâm niên đó nên có khá nhiều các projects được host trên “Làn sương mù” mà tính tới giờ, có cái lên tới cả chục năm trở lên và các lập trình viên chưa bao giờ có ý định dời nhà, trong đó có nhiều cái tên gạo cội trong cộng đồng Linux mở. Nghe có vẻ hay, nhưng trên thực tế, tốc độ kết nối giữa server của SF và các máy tính ở VN ta là vô cùng ngán ngẫm trong những lúc cá mập hoành hành hệ thống cáp quang biển. Nếu bạn muốn thực sự làm việc với họ, hãy đọc qua các deals của họ ở đây, mặc dù gói miễn phí cũng khá đủ cho bạn sử dụng.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.