Workflow với git github

Trong các bài trước trong series git/github, mình đã giới thiệu về workflow về git trước khi push code lên github. Trong bài viết này, mình sẽ tiếp tục bổ sung thêm workflow cho github.

Trước tiên là workflow git

Đầu tiên là bắt đầu với 1 repository mới với lệnh sau trong project:

$ git init

Nếu bạn đã có sẵn repository, dùng lệnh sau để clone repository:

$ git clone <repository_url>

Quy tắc sử dụng branch trong git

• master: branch mặc định khi chạy git init, chứa mã nguồn khởi tạo của ứng dụng và các version đã sẵn sàng để realease cho người dùng có thể sử dụng.
• develop: được tạo từ master, dùng cho việc deploy lên staging server. Nhánh này cũng là nhánh để bắt đầu một tính năng mới (mặc định checkout từ branch develop khi dev một tính năng mới).
• feature: được tạo từ develop, lưu lại mã nguồn của feature mới, tất cả các tính năng mới khi dev sẽ tạo nhánh với tiền tố feature/<feature_name>.
• hotfix: thường checkout từ master và sẽ merge vào cả develop và master sau khi sửa đổi nếu tính năng đang gặp lỗi trên production.

Trình tự làm việc khi tạo 1 feature mới

Đầu tiên, cần tạo branch cho feature đó với:

$ git checkout -b feature/<feature_name>

Sau khi thực hiện code xong, kiểm tra lại status của nhánh hiện tại để xem xem có những file nào thay đổi, có file nào nhầm không.

$ git status

Add các file thay đổi, đưa vào stage area trước khi commit:

// thêm 1 file
$ git add file-name
// thêm tất cả các file theo 1 thư mục
$ git add folder-name/
// thêm tất cả các file trong toàn project
$ git add -A

Thực hiện commit:

git commit -m "Commit Message"

Trước khi thực hiện push code lên, bạn cần pull code ở branch chính lưu code của bạn (với mình là develop) để kiểm tra xem có các thay đổi mới nào nếu các thay đổi đó trong cùng 1 file với các file bạn đang sửa thì có thể bị conflict.

$ git pull origin develop

Nếu có conflict, bạn cần fix và commit lại.

$ git commit -m "Fix Conflict"

Và push lên nhánh hiện tại đang làm việc:

$ git push origin feature/<feature_name>

Bạn cần tạo pull request(PR) từ branch vừa tạo đến branch develop để các thành viên trong team review code của bạn. Sau khi review và được approved, PR sẽ merge code của bạn vào branch develop.

Tạo và gửi Pull Request trên github

Title của pull request
Title của Pull Request được gắn với chức năng hoặc phần sửa chữa được thêm vào. Có thể add thêm một số tiền tố liên quan tới các hệ thống khác để dễ quản lý.
Ví dụ: [UI] Home screen nghĩa là Dựng UI màn hình Home.
Trong trường hợp quản lý task bằng git, bạn nên thêm id của issue vào cuối title của PR để... như sau [Issue #3][UI] Home screen

Description của pull request:

• Mô tả rõ ràng về pull request.
• Lưu ý liên quan tới cài đặt (nếu có)
• Lưu ý liên quan tới deploy (nếu có)
• Linking PR to Issue (đọc thêm mục linking PR to Issue trong bài viết Github và các chức năng chính)
• Quay loom hoặc chụp Evident để người check dễ dàng hơn

Thời điểm gửi pull request:

1. Khi kết thúc việc code một task được assign. Chú ý không gửi sourcode của nhiều task trong cùng một pull request.
   (Gây khó khăn trong việc review, sửa đổi và merge pull request).

2. Kết thúc buổi làm việc
   Trong trường hợp chưa làm xong nhưng đã kết thúc buổi làm việc của mình, trước khi về, cần commit và push tất cả lên branch đang làm việc (để người khác có thể tiếp tục công việc nếu cần gấp, hoặc trong trường hợp hôm sau bạn nghỉ, bạn có sự cố về máy móc...)
   Tạo một pull request và thêm tiền tố [WIP] có nghĩa là Work In Progress (đang thực hiện) vào title của pull request để toàn bộ team member biết là bạn đang hoàn thiện chức năng đó và chưa hoàn thành, chưa cần review. Ngoài ra còn 1 số tiền tố khác thường được sử dụng là:
   [PENDING]: khi PR trong trạng thái chờ, chưa thực hiện
   
   [DONE]: PR đã thực hiện xong chờ review.

3. Trước khi bạn ra về hoặc dừng công việc.
   Tương tự như mục 2. Kết thúc buổi làm việc. Bạn cần gửi pull request khi bạn gặp vấn đề đột xuất không tiếp tục được công việc nữa, hoặc kết thúc làm việc

Check list khi gửi pull request.

1. Trước khi gửi pull request, nhớ merge từ develop vào branch bạn muốn gửi pull-request hoặc rebase để cập nhật code mới nhất từ develop, để giảm thiểu việc khi bạn gửi pull-request lên thì gặp conflict với develop branch mà thành viên khác phải nhắc bạn giải quyết conflict gây tốn thời gian cho các member khác.
2. Kiểm tra xem các file có trong pull request có file nào thừa thãi, chứa source code không cần thiết hay không?
3. Kiểm tra xem các file có trong pull request còn các lệnh liên quan tới việc debug hay không? Ví dụ: lệnh dd() trong Laravel, console.log() trong Javascript. Cần xoá các lệnh này đi để các chức năng hoạt động chính xác.
4. Trong trường hợp dự án có tích hợp CI server hay github action... cần kiểm tra xem kết quả chạy của có success hay không, nếu có lỗi cần fix.
5. Assign những người cần review vào phần reviewer của pull request để họ biết mà ưu tiên review issues cho bạn.
6. Trong trường hợp, issues cần review gấp, add high priority label vào PR để member dễ theo dõi, và alert qua Slack cho member.

Trên đây, mình vừa giới thiệu về workflow cơ bản với git&github đang được sử dụng tại Haposoft. Ngoài ra, các bạn có thể xem lại bài trước của series này, giới thiệu về Github và các chức năng chính để củng cố thêm kiến thức về git/github nhé.
(Link bài trước của series tại đây)