Làm việc cùng Git

Làm việc cùng Git

1. Gitとは

• Là một công cụ để quản lí version （バージョン管理システム）
• Git giúp quản lí lịch sử sửa đổi của file bất cứ khi nào.
  • Có thể xem lại toàn bộ lịch sử edit của file
  • Có thể đưa file về trạng thái trước khi sửa đổi
  • Đưa ra cảnh báo khi xảy ra conflict với bản edit của người khác
• Là một hệ thống quản lí Version hoạt động theo cơ chế phân tán DVCs

2. So sánh DVCs và CVCs

CVCs (Centralized Version Control Systems)

• CVS, Subversion, Perforce
• Hoạt động dựa trên cơ chế Centralize (Hệ thống quản lí phiên bản tập trung)
  • Bao gồm một máy chủ có chứa tất cả các tập tin đã được phiên bản hoá và danh sách các máy khác có quyền thay đổi tập tin này trên máy chủ trung tâm đó

Demerit của CVCs

• Bị phụ thuộc vào máy chủ quá nhiều
  • Chỉ commit được lên máy chủ, không lưu lại được lịch sử ở môi trường local → Dẫn đến việc cần phải kết nối với máy chủ thì mới có thể edit được
• Khi ổ cứng cơ sở dữ liệu ở máy trung tâm bị mất và các sao lưu dự phòng chưa được tạo ra ở thời điểm đó => toàn bộ lịch sử của dự án đó sẽ bị mất

DVCs (Distributed Version Control Systems)

• Git, ~~Mercural~~ Mercurial
• Hoạt động trên cơ chế quản lý hệ thống phân tán
  • Mỗi máy khách là một bản sao chép toàn bộ dữ liệu của kho chứa

Merit so với CVCs

• Commit
  • 「CVCs」
    • Ko commit được ở môi trường local, chỉ có thể commit trực tiếp lên môi trường remote
    • Ko commit được những thay đổi chưa hoàn thiện, dẫn tới khó tracking được xem mình đã nhầm ở đâu
    • Có thể lock file ngăn không có người khác edit file
  • 「DVCs」
    • Commit được ở local và commit bất cứ lúc nào
    • Có thể check được sự thay đổi theo từng commit => dễ tracking khi có bug
    • Code revew dễ đàng do có thể nhìn vào commit
• Branch
  • 「CVCs」
    • Việc merge branch mẹ và branch con có thể làm tự động nhưng ko thể merge branch mẹ với branch cháu
    • Việc tạo branch tốn nhiều cost hơn so với Git
  • 「DVCs」
    • Tạo branch dễ dàng, auto merge
• Others
  • DVCs cho phép cộng tác với nhiều nhím khác nhau theo những các khác nhau trong cùng 1 dự án
  • Có nhiều tính năng hỗ trợ làm việc nhóm và quản lý chất lượng sản phẩm
  • Liên kết được với nhiều service thứ 3
  • Đã trở thành tiêu chuẩn của thế giới nên có rất nhiều know-how

3. Các khái niệm cơ bản của GIT

Repository （リポジトリ）

• Repository là nơi lưu file và directory cùng các trạng thái của nó
  • Khi muốn quản lí lịch sử của file hoặc diretory nào thì chỉ cần đặt nó vào một repository

※Thường gọi là Repo (レポ)

Phân loại

TypeWhatWho

Remote Repo	Repository được lưu trên server	All of members
Local Repo	Repository được lưu ở local	Only you

Hoạt động

• Đẩy từ local repo lên remote repo để public công việc bạn làm
• Get từ remote repo về local repo để lấy về nội dung thay đổi của người khác

Directory （ディレクトリ）

• Nơi chưa các file (tương đương với folder ở window)

Branch （ブランチ）

• Mỗi nhánh trong git là một workspace riêng biệt
• Dùng để phát triển các chức năng mới

Working Tree và Index（ワークングツリーとインデックス）

• Những thư mục được đặt trong sự quản lý của Git mà mọi người đang thực hiện công việc trong thực thế được gọi là working tree
• Index là trạng thai nằm giữa repo và working tree, giúp lưu lại toàn bộ những thay đổi của bạn. Index là nơi để chuẩn bị cho việc commit lên reposity

Conflict

• Là khái niệm chỉ sự xung đột giữa nội dung bạn thay đổi và mội dung người khác thay đổi
  • Tham khảo thêm Resolve Conflict

4. Các action cơ bản trong GIT

Init

• Init 1 git local repo tại thư mục hiện tại

Checkout (チェックアウト)

• Tạo ra một branch mới là một bản copy của branch hiện tại

Add

• Add một hoặc nhiều file vào trạng thái staging – Chuẩn bị cho commit

Commit（コミット）

• Là thao tác thêm/thay đổi nội dung của file(s) hoặc directory
• Thao tác commit sẽ sinh ra một commit (revision) được phân định bằng một mã HASH duy nhất để ghi lại sự khác biệt từ trạng thái lần trước với trạng thái hiện tại
• Commit được lưu lại trên repo
• Mỗi commit cần bao gồm commit message để giải thích cho công việc bạn muốn làm

Push （プッシュ）

• Là thao tác ~~public~~ publish những thay đổi của mình lên remote repo
• Sau khi push xong thì local repo và remote repo sẽ cùng 1 trạng thái

Clone （クーロン）

• Là thao tác download remote repo về máy tính cá nhân. Tạo ra một local repo ở môi trường cá nhân, có bao gồm cả lịch sử thay đổi của các file và directory

Pull（プル）

• Là thao tác lấy nội dung thay đổi mới nhất từ remote repo và update vào local repo

Fetch （フェッチ）

• Là thao tác get những thay đổi mới nhất từ remote repo với mục đích confirm

Merge （マージ）

• Là thao tác kết hợp các nhánh làm việc vào thân cây to chung 🙂

Log (ログ)

• Xem lại lịch sử thao tác đã được commit lên branch git
• Một số command thường dùng với git log
  git log --oneline --decorate
  Kết quả

• Ngoài ra có thể filter log theo số lượng, ngày tháng, người commit, theo file…

5. Git flow in real project

Khái niệm về git-flow

• Là một luồng làm việc dựa trên git
  Refer hình bên dưới

Git-flow branch model

Master Branch

• Branch chuẩn, bắt buộc luôn ở trong tình trạng product mới nhất
• Branch dùng với mục đích lưu gữ source code ở trạng thái product
• Tuyệt đối nghiêm cấm làm việc trực tiếp(commit trực tiếp) trên master branch.

Develop

• Branch dùng với mục đích lưu giữ source code ở trạng thái ổn định, sẵn sàng release
• Luôn phải duy trì trạng thái luôn sẵn sàng release (Có nghĩa là code để merge vào develop là code đã được review và test UT)

Feature Branches

• Branch được dùng để phát triển các chức năng riêng biệt
• Luôn cần được cắt ra từ branch develop
• Chỉ merge vào Develop Branch sau khi hoàn thành chức năng đó

Hotfixes

• Branch được dùng để sửa gấp khi xảy ra bug sau khi release
• Khi xảy ra bug sau khi release

Release Branches

• Là branch dùng để chuẩn bị để release product
• Cắt ra từ Develop Branch
• Chỉ commit thay đổi về release version, sau khi chuẩn bị xong thì merge vào master và thêm tag release. Sau đó merge vào Develop Branch.

Luồng làm việc với git

Tổng quan

Step 1: Initial

• Khi start một project thì cần tạo Master Branch và Develop Branch

Step 2: Create Branch

• Tạo Feature Branch từ Develop Branch để phát triển 1 chức năng mới
• Naming Rule : developer_name/feature_name
  • linhnk/login
• Đối với những chức năng lớn cần nhiều người tham gia vào dev thì có cắt nhỏ thêm các nhánh chức năng nữa từ Feature Branch

Step 3: Commit

• Commit với các đơn vị nhỏ
• Tên commit cần đặt sát với mục đích đoạn code

Step 4: Merge Request

• Sau khi phát triền xong thì cần gửi một Merge Request/ Pull Request đến nhánh mẹ
  • Cần assign team member review
  • Tuyệt đối không được merge cho đến khi có approve của Reviewer
  • Chỉ tạo Merge Request đã hoàn thành:
    • Implement
    • Testing
• Template cho Merge Request
  • Overview
  • Spectification Document
  • Implemented Functions
  • Test check list
• Reviewer có trách nhiệm review trong thời gian chậm nhất là 2 ngày kể từ khi nhận được Merge Request.
• Developer sau khi nhận được feedback thì cần sửa lại hoặc đưa ra ý kiến tranh luận. Sau khi đã sửa xong => Yêu cầu review thêm lần nữa.
• Các hạng mục cần được review
  • Code
    • Có đảm bảo coding-rule không ?
    • Có đảm bảo chất lượng code không ?
    • Nếu có phương pháp implement tốt hơn thì có thể recommend
      • Mục đích là share know-how
  • Logic
    • Có đảm bảo chức năng cần thực hiện không
    • Có đảm bảo không ảnh hưởng tới các source hiện tại không
  • Format
    • Check format các file
• Tinh thần review : 気持ちをこめてレビューしましょう
  • Tránh chỉ trích, khuyến khích đưa ra tranh luận để tìm được giải pháp tốt nhât
  • Cố gắng đưa ra lời khuyên nếu có
  • Nếu developer đưa ra giải pháp hay => とりあえずほめましょう。

Step 5: Merge

• Sau khi được approve Merge Request, bạn có thể merge vào branch mẹ
• Xoá branch hiện tại sau khi merge để tránh tồn tại branch rác

Step 6: Prepare Release

• Khi mọi chức năng đã được sẵn sàng và đã được merge vào Develop Branch thì developer đảm nhận nhiệm vụ release cần cắt Release Branch từ Develop Branch
• Naming Rule: release/release_{version}
• Edit version và commit
• Create pull request with tag -> chỉ cần tạo tag khi release môt tính năng lớn
• Merge to Master Branch
• Release

Step 7: Release

• Release sản phẩm lên môi trường product

Step 8: Hotfixes

• Chỉ dùng khi release xong xảy ra bug cần fix gấp
• Thứ tự làm việc:
  • Cắt 1 branch hotfix/fix_{reason} (cắt từ branch đang lỗi, ví dụ master đang có bug thì cần cắt ra từ master, fix xong nhớ phản ánh xuống develop nếu lỗi đó cũng xuất hiện ở develop)
  • Sửa bug
  • Commit
  • Nhờ ai đó review gấp
  • Merge
  • Release
  • Clean up : xoá branch đã dùng để đối ứng (chỉ xoá sau khi lỗi đã được fix và khách hàng đã confirm ok )

6. Tham khảo

• [サルでもわかるGIT] (https://www.backlog.jp/git-guide/)
• SVNを捨ててGitを使うべき5つの理由
• [A successful git branching model] (http://nvie.com/posts/a-successful-git-branching-model/)