Inside

GitHub cho designer: hiểu cách hoạt động mà không cần biết code

Git, repository, commit, branch, pull request là gì? Giải thích GitHub cho designer chưa biết code, kèm cách cộng tác với dev và bước bắt đầu.

GitHub cho designer: hiểu cách hoạt động mà không cần biết code

Nếu bạn từng nghe dev nói "mình mở PR rồi, bạn review giúp nhé" hay "merge vào main chưa?" mà không chắc họ đang nói gì, bài này dành cho bạn. GitHub không chỉ là công cụ của lập trình viên. Hiểu cách nó hoạt động giúp designer theo dõi tiến độ, review giao diện thật trước khi ra mắt và cộng tác với dev mượt hơn.

Tóm gọn: Git ghi lại lịch sử thay đổi của một dự án, GitHub là nơi lưu dự án đó trên mạng để cả team cùng làm việc. Bạn không cần viết code để đọc, bình luận và review.

Git và GitHub khác nhau thế nào?

Git là một phần mềm quản lý phiên bản (version control). Nó theo dõi mọi thay đổi trong một thư mục: ai sửa gì, lúc nào, vì sao. Git chạy trên máy tính, không cần internet.

GitHub là một dịch vụ trên web, lưu các dự án dùng Git và thêm công cụ cộng tác: bình luận, review, quản lý công việc, phân quyền. Có thể hình dung Git là "bộ máy ghi lịch sử", còn GitHub là "văn phòng chung" nơi cả team gặp nhau. Các dịch vụ tương tự là GitLab và Bitbucket.

So với Figma: Figma có version history tự động. Git cũng lưu lịch sử, nhưng bạn chủ động quyết định khi nào lưu một mốc và viết mô tả cho mốc đó.

Git ghi lịch sử trên máy bạn, GitHub là nơi cả team làm việc cùng nhau

Repository: thư mục dự án kèm toàn bộ lịch sử

Repository (gọi tắt là repo) là một thư mục dự án: code, hình ảnh, file cấu hình, tài liệu, cộng với toàn bộ lịch sử thay đổi. Một repo thường có file README.md giới thiệu dự án và cách chạy nó.

Repo tồn tại ở hai nơi: bản trên GitHub (remote) và bản sao trên máy từng người (local). Mọi người làm trên máy mình rồi đồng bộ với GitHub.

Commit: một mốc lưu có ghi chú

Commit là một lần lưu ảnh chụp (snapshot) của dự án tại một thời điểm, kèm một thông điệp ngắn như "Sửa màu nút chính" hay "Thêm icon thông báo". Chuỗi commit tạo thành dòng thời gian của dự án.

Nhờ commit, team có thể xem chính xác dòng nào đã thay đổi, ai thay đổi, và quay lại phiên bản cũ khi cần. Giống như "Save version" có đặt tên trong Figma, nhưng chi tiết đến từng dòng.

Hai thao tác đi kèm: push là đẩy commit từ máy lên GitHub; pull là kéo thay đổi mới nhất từ GitHub về máy.

Commit lưu mốc trên máy, push đẩy lên GitHub, pull kéo thay đổi về

Branch: nhánh làm việc riêng

Branch là một nhánh song song của dự án. Nhánh chính thường tên main, là phiên bản ổn định, sẵn sàng phát hành. Khi làm tính năng mới, dev tạo một nhánh riêng như feature/new-navbar, thử nghiệm thoải mái mà không ảnh hưởng main.

Figma cũng có branching trong gói trả phí, với ý tưởng tương tự: tách ra làm thử, xong thì gộp lại. Điểm khác là trong Git, mỗi team member có thể có nhiều nhánh cùng lúc, và đây là cách làm việc mặc định hằng ngày.

Merge: gộp nhánh về lại

Merge là gộp các thay đổi từ một nhánh vào nhánh khác, thường là vào main. Git tự gộp những phần không đụng nhau. Nếu hai người sửa cùng một chỗ theo hai cách khác nhau, Git báo conflict (xung đột) và một người phải chọn giữ bản nào.

Tách nhánh để làm thử, xong thì merge lại vào main

Pull request: đề nghị gộp, kèm review

Pull request (PR) là lời đề nghị "hãy gộp nhánh của mình vào main". Đây là nơi designer tham gia nhiều nhất. Một PR thường có:

  • Mô tả thay đổi, đôi khi kèm ảnh chụp màn hình hoặc video.
  • Danh sách file và dòng thay đổi.
  • Bình luận và review từ đồng đội: Approve (đồng ý), Request changes (yêu cầu sửa) hoặc Comment.
  • Kết quả kiểm tra tự động (checks) và thường có link preview: một bản web chạy thử từ nhánh đó, do các dịch vụ như Vercel, Netlify hay Lovable tạo ra.

Chỉ khi PR được duyệt thì mới merge. Đây là "cổng chất lượng" của team.

Quy trình một pull request: mở PR, checks, preview, review rồi merge

Issues: danh sách việc cần làm

Issues là nơi ghi lại bug, đề xuất và công việc. Mỗi issue có tiêu đề, mô tả, ảnh minh hoạ, người phụ trách và nhãn (label). Issue có thể được liên kết với PR, khi PR merge thì issue tự đóng. Kết hợp với GitHub Projects, issue trở thành bảng Kanban giống Trello hay Jira.

Với designer, issue là cách tốt để báo lỗi giao diện: chụp màn hình, mô tả mong muốn, dán link Figma.

Clone và fork

Clone là tải một bản sao của repo về máy bạn, kèm toàn bộ lịch sử, để làm việc hoặc chạy thử.

Fork là tạo một bản sao của repo trên tài khoản GitHub của bạn. Fork thường dùng khi bạn muốn đóng góp cho dự án của người khác (như dự án mã nguồn mở) mà không có quyền ghi trực tiếp: bạn sửa trên bản fork rồi mở PR về dự án gốc. Giống như "Duplicate" một file Figma cộng đồng về drafts của mình.

Designer cộng tác với dev trên GitHub thế nào?

1. Review PR bằng link preview. Bạn không cần đọc code. Mở link preview, kiểm tra spacing, màu, trạng thái hover, responsive, rồi để lại comment hoặc ảnh chụp ngay trong PR. Đây là lúc rẻ nhất để sửa lỗi giao diện.

2. Design tokens trong repo. Màu, typography, spacing, bo góc thường được lưu thành file token (ví dụ JSON) trong repo. Khi bạn đổi biến (variables) trong Figma và xuất ra token, thay đổi đi vào code qua một PR. Các plugin như Tokens Studio có thể đồng bộ token với GitHub.

3. Handoff từ Figma sang code. Dán link frame Figma vào issue hoặc mô tả PR, để dev và reviewer đối chiếu. Các công cụ như Dev Mode và Code Connect giúp nối component Figma với component trong code.

4. Sửa những thay đổi nhỏ trực tiếp. Lỗi chính tả, đổi một màu, thay icon: bạn có thể tự sửa trên GitHub, tạo nhánh và mở PR để dev review.

Bắt đầu từ đâu?

  • Tạo tài khoản GitHub và nhờ dev thêm bạn vào repo của team.
  • Đọc README và tab Pull requests để hiểu dự án đang có gì và ai đang làm gì.
  • Dùng GitHub Desktop: ứng dụng có giao diện, cho phép clone, tạo nhánh, commit và push bằng nút bấm thay vì dòng lệnh.
  • Thử github.dev: trên một repo, nhấn phím . (dấu chấm) để mở trình soạn thảo ngay trên trình duyệt. Rất hợp để sửa text hay file token nhỏ.
  • Tạo repo cá nhân để tập: ví dụ lưu portfolio hoặc một file token, thử commit, tạo nhánh và mở PR cho chính mình.
  • Review một PR thật: mở preview, để lại một comment cụ thể kèm ảnh.

So sánh các khái niệm GitHub với Figma

Bảng thuật ngữ nhanh

  • Repo: thư mục dự án + lịch sử.
  • Commit: một mốc lưu có ghi chú.
  • Push / Pull: đẩy lên / kéo về GitHub.
  • Branch: nhánh làm việc riêng. main: nhánh chính.
  • Merge: gộp nhánh. Conflict: hai thay đổi đụng nhau.
  • Pull request (PR): đề nghị gộp, kèm review.
  • Issue: một việc cần làm hoặc một lỗi.
  • Clone / Fork: bản sao về máy / bản sao trên tài khoản của bạn.

Kết luận

GitHub nghe có vẻ là thế giới của dev, nhưng cơ chế của nó khá gần với cách designer vẫn làm: lưu phiên bản, tách nhánh để thử, xin góp ý rồi mới chốt. Khi hiểu repo, commit, branch và pull request, bạn có thể review sản phẩm thật sớm hơn, góp ý đúng chỗ và trở thành cầu nối giữa thiết kế và code.

Nguồn tham khảo