Quang Vũ Lưu Công

3 tháng. - 5 phút đọc

Cơ bản về Gitflow Workflow

Giới thiệu

Gitflow Workflow là một thiết kế quy trình làm việc được sử dụng lần đầu tiên và làm cho phổ biến bởi Vincent Driessen at nvie. Gitflow Workflow định nghĩa một cấu trúc phân nhánh nghiêm ngặt xung quanh bản release của dự án. Điều này cung cấp thêm một framework mạnh mẽ để quản lý các dự án lớn.

Gitflow Workflow phù hợp với những mô hình phát triển phần mềm có thời gian release có chu kỳ như scrum. Workflow này không có thêm concepts hoặc commands mới nào ngoài những tính năng cho Feature Branch Workflow. Thay vào đó chúng chỉ định vai trò cụ thể của các branches khác nhau và thời điểm mà chúng cần tương tác. Ngoài ra còn có các branches đặc biệt cho việc preparing, maintaining và release. Tất nhiên, bạn có thể tận dụng các lợi thế của Feature Branch Workflow để tăng tính hiệu quả.

Tổng quan

Gitflow chỉ là một ý tưởng trừu tượng về quy trình sử dụng Git, Nó chỉ ra cách thức setup các loại branchs khác nhau và cách thức để merge chúng lại với nhau.

Ngoài ra các bạn có thể cấu hình CICD trên mỗi Git responsitoty khác nhau: GitHub, GitLab để tự động deloy các feature khi có sự thay đổi về code trên các branchs.

Mô tả tổng quan về Gitflow workflow:

Master: Master branchs có sẵn trong git và là branchs 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 (đặt Tag trên mỗi version). Thường cấu hình cho manage tương tác.

Hotfix: Được base trên nhánh master để sửa nhanh những lỗi trên UIT hoặc sửa những cấu hình đặc biệt chỉ có trên môi trường productions.

Khi cần thay đổi cấu hình cho bản release học hotfix ở môi trường production, teamlead sẽ tạo branchs base trên branchs Master để hotfix sau đó merge lại vào Master (thường thì sẽ không được thay đổi trược tiếp mã nguồn trên branch master nên phải lm cách này)

Release: Trước khi Release một phần mềm dev team cần được tạo ra để kiểm tra lại lần cuối trước đi release sản phần để người dùng có thể sử dụng (Thuông thường mã nguồn tại thời điểm này sẽ tạo ra bản build để test và kiểm tra lại bussiness).

khi đến thời điểm release ứng dụng, teamlead sẽ merge lên branchs Release để chuẩn bị bản build release cho ngời dùng.

Develop: Được khởi tạo từ master branches để lưu lại tất cả lịch sử thay đổi của mã nguồn. Develop branchs là merge code của tất cả các branchs feature.

Khi dev team hoàn thành hết feature của một topic, teamlead sẽ review ứng dụng và merge đến branchs release để tạo ra bản một bản release cho sản phẩm.

Feature: Được base trên branchs Develop. Mỗi khi phát triển một feature mới chúng ta cần tạo một branchs để việt mã nguồn cho từng feature.

khi có một feature mới dev tạo một branchs mới (thường đặt theo tên feature/<tên feature đó>) base trên branchs Develop để code cho feature đó. Sau khi code xong, dev tạo merge request đến branchs develop để teamlead review mà merge lại vào branchs Develop.

Ngoài ra còn một số branchs mà chúng ta thường tạo ra tùy vào yêu cầu của dự án: Pre-pro môi trường chưa mã nguồi của bản buil chạy trên môi trường user test, QC Môi trường chứa mã nguồi của bản build chạy trên môi trường test, BugFix: để chứa mã nguồn khi thực hiện công việc fix bug.

Lưu ý khi sử dụng Git

Sử dung merge request: Nhiều người không có thói quen tạo merge request mà merge trực tiếp code vào branchs develop rồi push lên, điều này là không tốt. Thứ nhất, tạo merge request để teamlead hoặc review có thể review mã nguồi trước khi merge để đảm bảo tính toàn vẹn của mã nguồn, điều này là cực kì quan trọng khi phát triển phần mềm với một team nhiều người. Thứ hai: người review sẽ comment trực tiếp cần thay đổi lên merge request để giảm thời gian trao đổi tăng tính hiệu quả khi làm việc nhóm. Thứ ba, tạo merge request để lưu lại lịch sử thay đổi của mã nguồi.Khi có vấn đề về lỗi, chất lượng phần mềm.... chúng ta có thể xem lại tất cả những sự thay đổi trên từ dòng code ( việc này có thể kiếm tra bằng cách kiểm tra trên từng commit nhưng commit thì rất nhiều). Ngoài ra, đây còn là nơi để lưu lại các comment của người review, các lỗi thông thường để các member sao không còn mắc lại lỗi cũ và là nơi để học hỏi code lẫn nhau thông qua việc xem lại sự thay đổi từng dòng code của member khác.

Thông thường thì tất cả các thay đổi về mã nguồi của branchs develop, release, master đều thông qua merge request (trừ mã nguồn lúc khởi tạo dự án).

Để tạo một merge request (pull request) trong GitHub, GitLab.

conflict code: đây là câu chuyện muôn thủa và không thể tránh khỏi khi làm việc nhóm, nhất là với những nhóm dự án đông người. vậy làm thế nào để hạn chết việc conflict code: chia nhỏ code thành từ module độc lập và hạn chế viết quá nhiều code vào một file, thường xuyên merge code ở branchs về để đảm bảo code hiện tại là mới nhất, merge code của branchs trước và sau khi code nếu có conflict thì merge conflict trước khi tạo merge request.

Nguồn tham khảo:

Quang Vũ Lưu Công

3 tháng. - 5 phút đọc

Cơ bản về Gitflow Workflow

Giới thiệu

Tổng quan

Ngoài ra các bạn có thể cấu hình CICD trên mỗi Git responsitoty khác nhau: GitHub, GitLab để tự động deloy các feature khi có sự thay đổi về code trên các branchs.

Mô tả tổng quan về Gitflow workflow:

Master: Master branchs có sẵn trong git và là branchs 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 (đặt Tag trên mỗi version). Thường cấu hình cho manage tương tác.

Hotfix: Được base trên nhánh master để sửa nhanh những lỗi trên UIT hoặc sửa những cấu hình đặc biệt chỉ có trên môi trường productions.

Release: Trước khi Release một phần mềm dev team cần được tạo ra để kiểm tra lại lần cuối trước đi release sản phần để người dùng có thể sử dụng (Thuông thường mã nguồn tại thời điểm này sẽ tạo ra bản build để test và kiểm tra lại bussiness).

khi đến thời điểm release ứng dụng, teamlead sẽ merge lên branchs Release để chuẩn bị bản build release cho ngời dùng.

Develop: Được khởi tạo từ master branches để lưu lại tất cả lịch sử thay đổi của mã nguồn. Develop branchs là merge code của tất cả các branchs feature.

Khi dev team hoàn thành hết feature của một topic, teamlead sẽ review ứng dụng và merge đến branchs release để tạo ra bản một bản release cho sản phẩm.

Feature: Được base trên branchs Develop. Mỗi khi phát triển một feature mới chúng ta cần tạo một branchs để việt mã nguồn cho từng feature.

Lưu ý khi sử dụng Git

Thông thường thì tất cả các thay đổi về mã nguồi của branchs develop, release, master đều thông qua merge request (trừ mã nguồn lúc khởi tạo dự án).

Để tạo một merge request (pull request) trong GitHub, GitLab.

Nguồn tham khảo:

Quang Vũ Lưu Công

2 năm. - 7 phút đọc

Chiến lược tối ưu hoá SQL

Trong môi trường phát triển phần mềm, hiệu suất của cơ sở dữ liệu là một yếu tố cực kỳ quan trọng. SQL Server là một trong những hệ quản trị cơ sở dữ liệu phổ biến nhất, và việc tối ưu hóa truy vấn trên nền SQL Server có thể mang lại nhiều lợi ích đáng kể, từ việc cải thiện hiệu suất đến giảm tải cho hệ thống. Trong bài viết này, chúng ta sẽ tìm hiểu về 13 chiến lược tối ưu hóa truy vấn SQL Server để nâng cao hiệu suất.

1. Chỉ chọn các cột cần thiết (SELECT)

Một trong những cách đơn giản nhất để cải thiện hiệu suất của truy vấn SQL là chỉ chọn các cột cần thiết thay vì chọn tất cả. Thực hiện điều này giúp giảm dung lượng dữ liệu được trả về từ cơ sở dữ liệu, làm giảm tải cho mạng và tăng tốc độ truy vấn.
Ví dụ: Thay vì sử dụng SELECT *, bạn nên chọn chỉ các cột cần thiết như SELECT username, email FROM users.

2. Sử dụng chỉ mục index (INDEX)

Chỉ mục index là một cách hiệu quả để tối ưu hóa truy vấn SQL. Bằng cách tạo chỉ mục trên các cột thường xuyên được truy vấn, bạn có thể cải thiện tốc độ truy vấn đáng kể.
Ví dụ: Tạo chỉ mục trên cột email trong bảng users để cải thiện tốc độ truy vấn khi bạn thường xuyên tìm kiếm theo email.

3. Thận trọng khi sử dụng JOIN

JOIN là một phần không thể thiếu trong việc truy vấn dữ liệu từ nhiều bảng. Tuy nhiên, việc sử dụng JOIN không đúng cách có thể làm giảm hiệu suất của truy vấn. Sử dụng INNER JOIN khi cần lấy dữ liệu từ hai bảng có quan hệ một-một, và sử dụng LEFT JOIN khi cần lấy dữ liệu từ bảng chính và có hoặc không có dữ liệu từ bảng thứ cấp.
Ví dụ: Sử dụng INNER JOIN để kết hợp dữ liệu từ bảng orders và bảng customers khi cần lấy thông tin về đơn hàng và thông tin về khách hàng tương ứng.

4. Sử dụng EXISTS hoặc IN thay vì JOIN

Trong một số trường hợp, sử dụng EXISTS hoặc IN có thể nhanh hơn và tối ưu hơn so với việc sử dụng JOIN, đặc biệt là khi bạn chỉ cần kiểm tra sự tồn tại của dữ liệu trong một bảng con.
Ví dụ: Sử dụng EXISTS để kiểm tra xem có dữ liệu phù hợp trong một bảng con hay không.

SELECT * FROM orders
WHERE EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id);

5. Thực hiện phân trang

Phân trang là một kỹ thuật quan trọng trong việc truy vấn dữ liệu từ cơ sở dữ liệu. Sử dụng câu lệnh OFFSET và FETCH NEXT để phân trang kết quả truy vấn giúp giảm tải cho cơ sở dữ liệu và tăng trải nghiệm người dùng.
Ví dụ: Sử dụng câu lệnh OFFSET và FETCH NEXT để phân trang kết quả truy vấn.

SELECT * FROM products ORDER BY name OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;

6. Tối ưu hóa cấu trúc bảng

Thiết kế cấu trúc bảng đúng cách có thể đóng vai trò quan trọng trong việc cải thiện hiệu suất của cơ sở dữ liệu. Tránh lặp lại dữ liệu và thiết kế bảng sao cho phản ánh đúng quan hệ giữa các thực thể có thể giúp tối ưu hóa hiệu suất của truy vấn.
Ví dụ: Thay vì lưu trữ thông tin khách hàng trong mỗi bản ghi đơn hàng, bạn có thể tạo một bảng riêng cho thông tin khách hàng và tham chiếu đến nó từ bảng đơn hàng.

7. Thực hiện partitioning

Partitioning là một kỹ thuật mạnh mẽ để tối ưu hóa hiệu suất của cơ sở dữ liệu, đặc biệt là khi bạn có một bảng lớn chứa dữ liệu lịch sử. Bằng cách chia dữ liệu thành các phần nhỏ dựa trên các tiêu chí như thời gian, bạn có thể cải thiện tốc độ truy vấn và quản lý dữ liệu hiệu quả hơn.
Ví dụ: Sử dụng partitioning để chia dữ liệu lịch sử thành các phần nhỏ dựa trên thời gian.

8. Sử dụng view cho các truy vấn phức tạp

View là một công cụ mạnh mẽ trong SQL Server giúp giảm lặp lại code và tăng tính tái sử dụng của mã. Đặc biệt là khi bạn có các truy vấn phức tạp, việc sử dụng view có thể giúp tối ưu hóa hiệu suất và quản lý mã dễ dàng hơn.
Ví dụ: Tạo một view để kết hợp dữ liệu từ nhiều bảng và sử dụng view này trong các truy vấn thường xuyên.

9. Sử dụng stored procedure

Stored procedure là một cách hiệu quả để thực hiện các thao tác phức tạp trên cơ sở dữ liệu. Bằng cách sử dụng stored procedure, bạn có thể giảm tải cho cơ sở dữ liệu bằng cách lưu execute plan vào cache và giảm thiểu việc tạo mới execute plan mỗi lần chạy truy vấn.
Ví dụ: Tạo một stored procedure để tính tổng số đơn hàng được đặt trong một ngày cụ thể.

10. Giảm thiểu sử dụng DISTINCT

DISTINCT là một câu lệnh hữu ích khi bạn cần lấy giá trị duy nhất từ một cột. Tuy nhiên, việc sử dụng DISTINCT có thể tốn nhiều tài nguyên và ảnh hưởng đến hiệu suất của truy vấn.
Ví dụ: Giảm thiểu sử dụng DISTINCT và xem xét cách khác để loại bỏ các bản sao từ kết quả truy vấn.

11. Sử dụng ORDER BY khi cần thiết

Sử dụng ORDER BY để sắp xếp kết quả truy vấn là một cách hiệu quả để tổ chức dữ liệu trả về. Tuy nhiên, việc sắp xếp dữ liệu có thể tốn nhiều tài nguyên nếu không được thực hiện đúng cách.
Ví dụ: Sử dụng ORDER BY để sắp xếp kết quả truy vấn theo một cột cụ thể như ORDER BY date_created.

12. Sử dụng table value parameters (TVP)

Table value parameters (TVP) là một tính năng mạnh mẽ của SQL Server cho phép truyền một bảng dữ liệu như tham số. Bằng cách sử dụng TVP, bạn có thể giảm dung lượng dữ liệu truyền độc lập nhiều lần và tối ưu hóa hiệu suất của truy vấn.
Ví dụ: Sử dụng TVP để truyền một danh sách các ID vào một stored procedure thay vì truyền từng ID một cách độc lập.

13. Phân tích câu truy vấn sử dụng execute plan

Phân tích và đánh giá hiệu suất của câu truy vấn là bước quan trọng trong quá trình tối ưu hóa truy vấn SQL. Sử dụng câu lệnh EXPLAIN để xem execute plan của một truy vấn và tìm cách tối ưu hóa nó dựa trên kết quả.
Ví dụ: Sử dụng câu lệnh EXPLAIN để phân tích hiệu suất của một truy vấn và tìm cách tối ưu hóa nó.

Kết luận

Tối ưu hóa truy vấn SQL Server là một phần quan trọng trong việc cải thiện hiệu suất và độ tin cậy của cơ sở dữ liệu. Bằng cách áp dụng các chiến lược tối ưu hóa như chỉ chọn các cột cần thiết, sử dụng chỉ mục index và thận trọng khi sử dụng JOIN, bạn có thể tăng tốc độ truy vấn và giảm tải cho cơ sở dữ liệu của mình. Hãy thử áp dụng những chiến lược này trong dự án của bạn và theo dõi sự cải thiện trong hiệu suất và hiệu quả làm việc của bạn!

Quang Vũ Lưu Công

2 năm. - 7 phút đọc

Bạn đang ở level nào của SQL

Bắt đầu cuộc dạo của chúng ta ngay thôi nào

Đừng chỉ dừng hành trình SQL của bạn với JOIN.

Các cấp độ của SQL

Về cấp độ, tôi chia kiến thức SQL được chia ra làm 6 giai đoạn.

Very Basic: gồm các lệnh select, from, where
Basic: gồm các lệnh group by và having
Beginners: lệnh join, left/right/outer/inner/self join.
Intermediate: Subqueries.

(Hầu hết mọi người dừng ở giai đoạn 4- intermediate 🤣🤣🤣. Giai đoạn 5 có thể giúp bạn cải thiện đáng kể khả năng viết những câu truy vấn phức tạp (complex queries). Điều này xảy ra do 95% các trường hợp, nó đủ với một backend CRUD cơ bản. Hôm nay ta sẽ vượt qua khoảng cách từ 4 đến 5, tức là từ Intermediate tới Advanced.)

Advanced: Làm việc với CTEs (Common Table Expressions), window functions, lệnh partition by.

Nội dung ở cấp độ ‘Pro’ cũng rất hay và hữu ích.

Pro

Tại sao ta cần biết SQL?

Viết truy vấn SQL là một trong những công cụ tuyệt vời, hữu ích nhất mà một manager cần có, vì 3 lý do chính sau:

Bạn có thể trả lời câu hỏi kinh doanh. Kĩ năng này vô cùng giá trị cho sự gắn kết giữa bạn với những người từ phía thương mại.
Hầu hết các thiết kế kỹ thuật bắt đầu với dữ liệu. Mặc dù bạn không cần khả năng viết truy vấn ở cấp độ cao để tạo và hiểu ERD, nhưng nó vẫn có thể giúp bạn hiểu được tình huống chính xác và DB cũng như cách mọi thứ được kết nối với nhau.
Tỉ lệ effort/benefit lớn. SQL rất dễ thành thạo. Đó có thể là kỹ năng ‘Át chủ bài’ của bạn, trở thành người tiếp cận những câu hỏi/truy vấn phức tạp.

Thử viết một vài câu lệnh SQL đơn giản

Tôi giả sử rằng các bạn đã quen thuộc với các câu lệnh cơ bản, joins, subqueries.

Ví dụ dưới đây dựa trên một bảng đơn với 5 cột, có kiểu dữ liệu đơn giản. Bảng này đại diện cho các ưu đãi của khách hàng trên các khu vực khác nhau.

CREATE TABLE deals (
  deal_id INT PRIMARY KEY,
  deal_amount DECIMAL(10, 2),
  customer_name VARCHAR(255),
  region VARCHAR(255),
  deal_date DATE 
);

Ta có 20 dòng dữ liệu như dưới đây: Ta tiến hành chèn 20 dòng dữ liệu vào trong bảng trên

INSERT INTO deals 
 (deal_id, deal_amount, customer_name, region, deal_date) 
VALUES
(1, 25000.00, 'Acme Corporation', 'North America', '2023-01-15'),
(2, 25000.00, 'Globex Corporation', 'North America', '2023-01-20'), 
(3, 12500.00, 'Acme Corporation', 'North America', '2023-02-11'),
(4, 30000.00, 'Initech', 'Europe', '2023-03-22'),
(5, 20000.00, 'Hooli', 'Europe', '2023-03-27'), 
(6, 20000.00, 'Vehement Capital Partners', 'Europe', '2023-04-05'), 
(7, 15000.00, 'Massive Dynamic', 'North America', '2023-04-15'),
(8, 15000.00, 'Soylent Corp', 'Asia', '2023-05-01'), 
(9, 17000.00, 'Initech', 'Europe', '2023-05-20'), 
(10, 15000.00, 'Pied Piper', 'Asia', '2023-06-03'), 
(11, 7500.00, 'Globex Corporation', 'North America', '2023-06-25'),
(12, 8000.00, 'Pied Piper', 'Asia', '2023-07-12'),
(13, 17000.00, 'Hooli', 'Europe', '2023-07-18'), 
(14, 12000.00, 'Soylent Corp', 'Asia', '2023-08-02'),
(15, 9000.00, 'Massive Dynamic', 'North America', '2023-08-21'),
(16, 23000.00, 'Vehement Capital Partners', 'Europe', '2023-09-11'),
(17, 3000.00, 'Pied Piper', 'Asia', '2023-09-30'),
(18, 40000.00, 'E Corp', 'North America', '2023-10-05'),
(19, 35000.00, 'E Corp', 'North America', '2023-10-20'),
(20, 6000.00, 'Hooli', 'Europe', '2023-11-04');

Ta bắt đầu với các truy vấn con:

SELECT deal lớn nhất trong mỗi khu vực.

Lời giải ngây thơ (naive solution) SELECT * FROM deals d1 WHERE d1.deal_amount = ( SELECT MAX(d2.deal_amount) FROM deals d2 WHERE d2.region = d1.region ); Vấn đề ở đây là truy vấn con tham chiếu đến một cột của truy vấn bên ngoài. Điều này khiến cho truy vấn con phải thực hện một lệnh cho mỗi hàng ở bảng bên ngoài, nó có thể rất chậm.
Cách giải quyết:Ta có thể tạo truy vấn con tốt hơn nhưng tôi muốn giới thiệu CTE - Common Table Expression. Một CTE là một bảng tạm thời, nó trông như sau: WITH max_deals_by_region AS ( SELECT region, MAX(deal_amount) AS max_deal_amount FROM deals GROUP BY region ) SELECT d.* FROM deals d JOIN max_deals_by_region rmd ON d.region = rmd.region AND d.deal_amount = rmd.max_deal_amount; CTE được định nghĩa bằng mệnh đề WITH, theo sau đó là CTE name và sau dó là truy vấn để tạo ra CTE. Sau khi định nghĩa xong có thể chọn CTE như bảng bình thường trong cơ sở dữ liệu.
Tại sao nó hữu ích?CTE không cho một khả năng mới (nghĩa là ta có thể giải quyết vấn đề với một truy vấn con thích hợp), nó chỉ hỗ trợ ta viết truy vấn tốt hơn:Khi sử dụng CTEs, ta không bị rơi vào bẫy truy vấn con liên quan, nó buộc ta phải suy nghĩ về cách giải quyết vấn đề một cách chính xác.Nó cải thiện khả năng dễ đọc của câu truy vấn.

Điều thú vị hơn nằm ở dưới đây!!!

Ta sẽ thử sức với câu truy vấn khó hơn một chút.

Select top 3 deals trong mỗi khu vực.

WITH ranked_deals AS (
  SELECT
    deal_id, deal_amount, customer_name, region, deal_date,
    RANK() OVER (PARTITION BY region ORDER BY deal_amount DESC) AS deal_rank
  FROM deals
)
SELECT deal_id, deal_amount, customer_name, region, deal_date
FROM  ranked_deals
WHERE deal_rank <= 3
ORDER BY region, deal_rank;

Ta nhận được 11 bản ghi, trong khi đó chỉ có 3 khu vực, đáng ra là 9 bản ghi thôi chứ? Ta sẽ hiểu tại sao có điều này sớm thôi!

Vậy rank/over/partition là những câu lệnh gì mà thú vị như vậy?

Các kiểu window function

Có 3 kiểu chính:

Ranking functions
Aggregate functions
Positional functions

1. Ranking Window Functions.

Giống như cái tên của nó, họ xếp hạng các hàng trong mỗi phân vùng. Các Ranking function chính là:

SELECT deal_id, deal_amount, customer_name,   
    ROW_NUMBER() OVER (PARTITION BY region ORDER BY deal_amount DESC)  
  AS row_number,   
    RANK() OVER (PARTITION BY region ORDER BY deal_amount DESC)  
  AS rank,   
    DENSE_RANK() OVER (PARTITION BY region ORDER BY deal_amount DESC)  
  AS dense_rank 
FROM deals 
ORDER BY region, deal_amount DESC;

2. Aggregation Window Functions.

Rất giống với GROUP BY nhưng có một ưu điểm rất lớn là có thể giữ toàn bộ dữ liệu của mỗi dòng.
Có thể sử dụng tất cả những cái quen thuộc như: SUM(), AVG(), MAX(),…

Với mỗi deal, tính % deal trong mỗi khu vực.

SELECT
  deal_id, deal_amount, customer_name, region, deal_date,
  ROUND((deal_amount / SUM(deal_amount) OVER (PARTITION BY region)) * 100, 2) AS percentage_of_total_in_region
FROM deals
ORDER BY region, deal_date;

3. Positional Window Functions

Các hàm này trả về một giá trị từ một hàng cụ thể trong mỗi window frame. Ví dụ:

Đối với mỗi deals, tính toán sự thay đổi về deal_amount so với deals trước đó của cùng một khách hàng trong cùng khu vực.

Lời nhắn

Chúng mình có tạo Group cho các bạn cùng chia sẻ và học hỏi về thiết kế hệ thống nha 😄😄😄

Bài viết được lấy trên viblo mình thấy khá bổ ích Bạn đang ở level nào SQL

Quang Vũ Lưu Công

2 năm. - 7 phút đọc

Tổng hợp ý tưởng tối ưu Dockerfile

Dockerfile là gì?

Sơ lược 1 chút về ý nghĩa của Dockerfile, Dockerfile là một file văn bản chứa các lệnh để tự động xây dựng một image Docker (Docker image), hay Dockerfile dùng để đóng gói ứng dụng lại thành một Image và có thể chạy được trên nhiều nền tảng khác nhau như Windows, Linux, MacOS,.... sử dụng công nghệ container.

Các lệnh được khai báo trong Dockerfile dùng để:

Cấu hình hệ điều hành
Cài đặt các phần mềm cần thiết
Sao chép dữ liệu
Cấu hình ứng dụng
Xác định lệnh khởi động

Lợi ích của việc sử dụng Dockerfile:

Tính nhất quán: Đảm bảo rằng ứng dụng được xây dựng giống nhau trên mọi môi trường.
Tái sử dụng: Có thể sử dụng Dockerfile để xây dựng các hình ảnh Docker cho các ứng dụng khác nhau.
Dễ dàng chia sẻ: Chia sẻ Dockerfile với người khác để họ có thể dễ dàng xây dựng và chạy ứng dụng của bạn.

Ví dụ về Dockerfile đơn giản:

FROM ubuntu:18.04

RUN apt-get update && apt-get install -y nginx

COPY index.html /usr/share/nginx/html

CMD ["nginx", "-g", "daemon off;"]

Dockerfile này sẽ:

Sử dụng hình ảnh Ubuntu 18.04 làm cơ sở. (Dòng 1)
Cài đặt Nginx. (Dòng 2)
Sao chép tệp index.html vào thư mục /usr/share/nginx/html. (Dòng 3)
Khởi động Nginx với chế độ daemon off. (Dòng 4)

Tại sao phải tối ưu Dockerfile

Có nhiều lý do cần tối ưu Dockerfile, đơn giản nhất có thể chỉ ra một vài ý chính:

Tiết kiệm dung lượng: Image Docker nhỏ gọn sẽ giúp tiết kiệm dung lượng lưu trữ và băng thông mạng khi pull và push image
Tăng tốc độ build: Build hình ảnh Docker nhanh hơn giúp đẩy nhanh quá trình phát triển và triển khai ứng dụng. Ví dụ team dev ở công ty bạn build 1 project hết 20 phút và một ngày cần build 3 lần để deploy test trên dev. Giả dụ bạn tối ưu để quá trình build chỉ còn 5 phút, vậy là mỗi ngày bạn đã tiết kiệm được thêm (20-5) x 3 = 45 phút/ngày cho team dev, nhân lên 1 năm thì sẽ tiết kiệm được vô cùng nhiều thời gian và tiền bạc.
Tăng cường bảo mật: Giảm thiểu các lỗ hổng bảo mật bảo vệ ứng dụng khỏi các mối đe dọa, lộ lọt thông tin.
Dễ dàng sử dụng: Tối ưu Dockfile sẽ giúp developers dễ dàng hiểu và sửa đổi Dockerfile khi cần thiết.

Các ý tưởng tối ưu Dockfile

1. Sử dụng Image tối giản

Ví dụ khi dockerize ứng dụng Python, thay vì sử dụng base image python:3.9.19, hãy sử dụng python:3.9.19-alpine.

Image Alpine có kích thước nhỏ hơn nhiều vì nó chỉ bao gồm các thành phần cần thiết. Trong ví dụ trên nếu sử dụng image alpine ta đã tiết kiệm được hơn 300MB trên mỗi lần build image.

2. Không cài đặt các công cụ thừa thãi

Chỉ cài đặt các thư viện và công cụ cần thiết cho ứng dụng của bạn.

Tránh cài đặt các gói "full" hoặc "dev" vì chúng bao gồm nhiều công cụ không cần thiết.
Đôi khi để dễ cho công việc debug, nhiều bạn còn cài thêm nhiều các công cụ debug.

Để biết được công cụ nào là cần, công cụ nào không cần mình hay tự hỏi bản thân câu hỏi "Thứ này có cần để chạy ứng dụng không?" trước khi thêm bất cứ dòng lệnh nào vào Dockerfile.

Ví dụ:


# Không nên
RUN apt install curl python-pip jq bash speedtest net-tools

# Nên
RUN apt install python-pip

3. Gộp nhiều câu lệnh RUN

Viết nhiều câu lệnh RUN tách biệt với nhau có thể sẽ giúp Dockerfile của bạn dễ nhìn hơn, tuy nhiên với mỗi câu lệnh Docker sẽ tạo ra 1 layer image tương ứng. Việc gộp các câu lệnh RUN liên tiếp thành một để giảm số lượng layer trong hình ảnh Docker, tối ưu được cache từ đó giảm thời gian build image.

Ví dụ:

# Không nên
RUN pip install flask
RUN pip install gunicorn

# Nên
RUN pip install flask gunicorn

4. Sử dụng nhiều stage để build image

Sử dụng nhiều stage trong Dockerfile giúp tách biệt các giai đoạn trong quá trình build. Điều này đặc biệt hữu ích khi các thành phần phụ thuộc tại quá trình build khác với các thành phần phụ thuộc trong quá trình chạy ứng dụng. Nó giúp tạo ra Image cuối cùng chỉ với các thành phần cần thiết, giúp cho image cuối cùng để chạy ứng dụng là nhỏ gọn nhất và an toàn hơn. Dockerize cho ứng dụng Java rất hay sử dụng phương thức này

Sử dụng chỉ 1 stage

FROM openjdk:11-jre-slim

WORKDIR /app

COPY pom.xml .

RUN mvn clean install

COPY target/my-app-1.0.0.jar .

CMD ["java", "-jar", "my-app-1.0.0.jar"]

Sử dụng multi-stage

#Build Stage
FROM maven:3.8-jdk-11 AS build

WORKDIR /app

COPY pom.xml .

RUN mvn clean install

# Run Stage
FROM openjdk:11-jre-slim

COPY --from=build /app/target/my-app-1.0.0.jar .

CMD ["java", "-jar", "my-app-1.0.0.jar"]

5. Không thêm các file không cần thiết

Trong quá trình viết Dockerfile các bạn dev hoặc devops đôi khi sẽ lười mà chọn phương thức đơn giản nhất COPY . . để chép toàn bộ source code vào trong container, tuy nhiên điều này thường là không cần thiết. Loại bỏ các file không cần thiết như .gitignore, .env, README.md khỏi quá trình chép source code vào image để giảm kích thước.

# Không nên
RUN pip install -r requirements.txt
COPY . .

# Nên
RUN pip install -r requirements.txt
COPY app.py .

6. Sắp xếp các câu lệnh cho hợp lý để tối ưu Docker build cache

Docker khi build image sẽ đọc các câu lệnh từ trên xuống dưới, khi gặp một layer mới có sự thay đổi, Docker sẽ build mà không sử dụng cache từ layer đó. Chính vì vậy có một nguyên tắc là, những layer (hay câu lệnh) có ít sự thay đổi thì nên được để ở trên cùng trong Dockerfile.

Ví dụ:

# Không nên
FROM openjdk:11-jre-slim

WORKDIR /app

COPY pom.xml .

RUN mvn clean install

COPY target/my-app-1.0.0.jar .

EXPOSE 8888

CMD ["java", "-jar", "my-app-1.0.0.jar"]

# Nên

FROM openjdk:11-jre-slim

WORKDIR /app

EXPOSE 8888

COPY pom.xml .

RUN mvn clean install

COPY target/my-app-1.0.0.jar .

CMD ["java", "-jar", "my-app-1.0.0.jar"]

Thường các thành phần như WORKDIR, EXPOSE, file thư viện pom.xml, cài đặt thư viện sẽ không có thay đổi nhiều ta nên để lên trên cùng.

7. Sử dụng cache từ các image đã build trước đó

Không liên quan lắm đến Dockerfile nhưng để giảm thời gian trong quá trình build trong những môi trường mà image được build trước đó của ứng dụng không tồn tại sẵn trong môi trường build thì bạn có thể sử dụng cache bằng cách pull image phiên bản trước về và build từ image đó.

Docker có hỗ trợ trường --cache-from, sử dụng docker build --cache-from để tận dụng cache từ các image đã build trước đó, giúp tăng tốc độ build.

Ví dụ:

docker build --cache-from <image-id> -t my-app .

8. Sử dụng .dockerignore

Định nghĩa file .dockerignore và liệt kê các file không cần thiết trong quá trình build sẽ giúp Docker loại bỏ các file này vào trong quá trình build Ví dụ với ứng dụng python:

#.dockerignore

__pycache__
*.pyc
*.pyo
*.pyd
.Python
env
pip-log.txt
pip-delete-this-directory.txt
.tox
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.log
.git
.mypy_cache
.pytest_cache
.hypothesis

Kết

Hy vọng bài viết này giúp ích được cho bạn trong công việc. Nếu bạn có ý tưởng gì thêm về việc tối ưu quá trình build hay xây dựng Dockerfile thì comment dưới chia sẻ với mình nhé.

Nếu thấy bài viết hay và muốn đọc thêm nhiều bài viết khác từ mình thì UpVote và Follow mình để tiếp thêm động lực cho mình nhé! Chúc bạn một ngày tốt lành 🤟🤟🤟

container DevOps Dockerfile dockerize optimizing

Quang Vũ Lưu Công

2 năm. - 3 phút đọc

Những kiến thức, công nghệ hay mà có thể dự án, team của cậu sẽ cần

MinIO

Hệ thống lưu trữ mã nguồn mở, hiệu suất cao, có thể dùng để lưu hình ảnh, video, các loại file khác nhau. Các cậu có thể thông qua API hoặc SDK để thực hiện chức năng upload, download file với MinIO

Elasticsearch

Hệ thống lưu trữ, tìm kiếm, phân tích, thống kê dữ liệu một cách nhanh chóng và hiệu quả. Tích hợp dễ dàng thông qua API

ELK

“3 chàng lính ngự lâm” giúp quá trình thu thập, lưu trữ, xử lý và phân tích log trở nên dễ dàng và hiệu quả hơn bao giờ hết

Kafka, RabbitMQ

Hai lựa chọn hàng đầu cho việc xử lý message queue và event streaming

Docker, Docker compose, K8S, Helm

“Bộ tứ siêu phàm” trong việc triển khai, quản lý và mở rộng ứng dụng dựa trên các container

JMeter

Công cụ hiệu quả để thực hiện test hiệu năng của ứng dụng, hỗ trợ thực hiện các thể loại test khác nhau như Load Testing, Stress Testing, Volume Testing, Endurance Testing, ...

Socket.IO

Socket.IO là một thư viện được sử dụng rất nhiều trong việc triển khai các tính năng kinh điển ví dụ như quả chuông thông báo 🔔 (realtime notification)

Dotfuscator

Nếu dự án của cậu đang xây dựng ứng dụng .NET, thì Dotfuscator là một công cụ mà cậu nên xem xét sử dụng từ sớm. Nó sẽ giúp ứng dụng của cậu khó bị dịch ngược (reverse engineering) hơn

Prometheus và Grafana

Combo “thần thánh” được các dự án sử dụng trong việc giám sát hệ thống (monitoring)

Redis

Redis hẳn là một công cụ quá phổ biến rồi. Thường được các dự án sử dụng để caching. Bên cạnh đó, nó còn có thể được dùng như một message queue hoặc một database nếu muốn

Jenkins

Công cụ phổ biến được sử dụng để triển khai CI/CD trong các dự án

gRPC

Một trong những công nghệ được nhiều dự án sử dụng để tăng tốc độ request-response giữa các server với server trong hệ thống microservices chằng chịt

Neo4j

Là 1 trong những graph database mã nguồn mở phổ biến nhất, thường được sử dụng trong việc xây dựng các ứng dụng mạng xã hội, hoặc hồi dịch COVID thì có thể sử dụng làm ứng dụng truy vết bệnh nhân COVID, ...

Cassandra

Thường được sử dụng trong các hệ thống xử lý dữ liệu lớn. Điển hình như là chat app. Discord cũng từng sử dụng Cassandra, cho đến khi số lượng user phát triển quá nhanh, lưu đến hàng nghìn tỉ message dẫn đến việc phải chuyển qua ScyllaDB

Ansible

Anh em DevOps thường xuyên sử dụng tool này để tự động hóa các công việc infrastructure provisioning, configuration management, deploy app, ...

ArgoCD

Cái tên nói lên tất cả. Cùng với Jenkins, ArgoCD là công cụ được nhiều dự án sử dụng để xây dựng mô hình GitOps. Trong đó dùng CI dùng Jenkins và CD dùng ArgoCD

Quang Vũ Lưu Công

2 năm. - 2 phút đọc

Viết Git commit message sao cho hiệu quả trong dự án thực tế

Phải bạn không? Cùng sửa nhé 😉

Cấu trúc chung của 1 commit message

<type>: <description>[body]

Trong đó:

type và description là phần BẮT BUỘC
body là phần TÙY CHỌN, có thể có hoặc không

Ví dụ:

feat: add email notifications on new messagesrefers to JIRA-1234

<type>

feat: Một tính năng mới (feature)
fix: Sửa lỗi (fix bug)
docs: Cập nhật tài liệu (sửa documents)
style: Thêm khoảng trắng, format code, thiếu dấu chấm phảy, ...
refactor: Đổi tên hàm, tên biến dễ hiểu hơn, tách hàm con, xóa code thừa, ...
perf: Cải tiến hiệu năng
test: Thêm test case còn thiếu, sửa unit test, ...
build: Những thay đổi ảnh hưởng đến quá trình build
ci: Thay đổi file cấu hình hoặc script CI

<description>

Mô tả ngắn gọn về nội dung commit
Không dài quá 50 ký tự để có thể dễ dàng đọc trên GitHub, cũng như các git tool khác
Sử dụng câu mệnh lệnh, ở thì hiện tại. Ví dụ: “change ...“ thay vì “changed ...“
Không viết hoa chữ cái đầu tiên
Không sử dụng dấu chấm ở cuối câu

[body]

Là phần TÙY CHỌN, sử dụng để mô tả chi tiết hơn về commit nếu cần
Cách phần <type>: <description> ở bên trên bởi 1 dòng trắng (blank line)
Nên dùng để giải thích câu hỏi What (để làm gì), hoặc Why (tại sao cần), chứ KHÔNG PHẢI How (làm như thế nào)

Kết quả ✅

Tài liệu tham khảo

Contributing to Angular: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format

Hi vọng kiến thức này hữu ích với cậu. Hẹn gặp lại 👋

Quang Vũ Lưu Công

2 năm. - 13 phút đọc

Giới thiệu và cách sử dụng github trong dự án thực tế

Introduce

Những gì cần biết khi làm việc với Git trong dự án

Giới thiệu về Git

Git thì chắc không phải nói nhiều các bạn cũng biết về nó rồi đúng không. Bài này mình không nói nhiều mà các bạn chỉ cần Google là ra cả đống giới thiệu về Git. Mình chỉ nói tóm tắt ngắn gọn cho các bạn mới dùng Git hoặc mới tìm hiểu về Git được biết nó là gì và tại sao cần dùng nó?

Git gần đây nổi lên phổ biến nhất trong số các hệ thống quản lý mã nguồn hoàn toàn mở và miễn phí trên thị trường và nó gần như thay thế hoàn toàn và tuyệt đối ưu thế. Chỉ còn một số dự án cũ vẫn dùng SVN để quản lý tài liệu mà thôi còn lại dần dần họ cũng migrate hết lên Git. Ngay cả cha đẻ của TFS là Microsoft cũng hỗ trợ Git một hệ quản trị mã nguồn (SCM – Source Control Management) song song với TFS trên Azure DevOps. Các bạn cũng thấy có một platform là Github đang thống trị thị trường chia sẻ code với một lượng developer và repository khổng lồ.

Vậy Git là gì? Nó là hệ thống quản lý mã nguồn phi tập trung và nó được phát triển bởi chính cha đẻ của Linux là Linux Torvald. Cái hay của nó chính là ở sự phi tập trung mà mình làm việc nhiều mới thấy nó hay. Ví dụ trước đây chúng ta làm việc với Visual Source Safe, SVN, TFS…thì đều là quản lý ở dạng tập trung tức là làm xong phải đẩy code lên server để tracking, server quản lý toàn bộ nhánh code và nếu server chết thì cũng chết luôn không commit gì được?

Còn phi tập trung hay cái là chúng a cứ thao tác bình thường trên mỗi máy local, bao gồm các thao tác thường thấy như commit, merge, rebase… Và chỉ khi nào cần push code chia sẻ cho các member khác trong team mới cần Git server.

Một tình huống nữa là nếu lỡ không may code trên Git server bị mất thì bất cứ máy nào có nhánh code đó đều có thể push lên được, rất tiện và an toàn phải không nào?

Giờ có 1 điểm quan trọng là chúng ta phải hiểu được Git nó có những trạng thái nào khi làm việc thì chúng ta mới hiểu được nó:

mô hình hoạt động git

Đây là sơ đồ trạng thái của file từ khi tạo ra đến khi chúng ta đẩy lên Git, cơ bản thì nó có 3 trạng thái dưới local và 1 trạng thái đẩy lên server hay chưa (qua câu lệnh git push). Về cơ bản chúng ta chỉ cần nhớ git có 3 trạng thái thay vì 2 trạng thái như cac thằng khác.

1. Workspace: tức là file tạo ra chưa add vào git change, sau lệnh git add thì mới add vào staging

2. Staging là các thay đổi được chuẩn bị để commit

3. Trạng thái đã commit vào local repository

Trạng thái sau cùng là được push lên server hay chưa, cái này thì tùy nếu bạn đã add repository vào local repository thì mới cần còn không thì làm việc nguyên dưới local là đủ. Nhìn vào hình trên ta cũng thấy mỗi giai đoạn cần dùng lệnh gì trực quan phải không nào?

Giờ chúng ta sẽ tìm hiểu một số từ khóa cần biết trong Git nhé.

Các từ khóa cần biết trong Git

Git: Tên hệ thống quản trị mã nguồn (nó tương đương SVN hay TFS…) và nó không phải Github nhé.

Github: Là một dịch vụ lưu trữ và chia sẻ mã nguồn sử dụng hệ thống quản trị Git, ngoài ra có Azure DevOps, Bitbucket…

Repositories: Là nơi đặt mã nguồn git, thường là 1 project sẽ tạo 1 Repository riêng hoặc 1 Repository chứa nhiều mã nguồn nhiều project con. Nói chung nó là một bộ mã nguồn nếu muốn lưu trữ trên git thì chúng ta đều phải tạo ra 1 repository và đẩy code lên đó. Thường thì 1 account Git hoặc 1 project sẽ cho tạo nhiều Repository trên đó. Ví dụ: https://github.com/vuluu2k đây là Github account của mình chứa nhiều Repository trên đó, mỗi repository là một mã nguồn.

Branch: Mỗi một repository chúng ta chia ra nhiều nhánh code, để giúp các developer hay nhóm phát triển các tính năng độc lập của phần mềm mà không bị ảnh hưởng đến nhau, mỗi nhánh sẽ là một danh sách các commit mà không ảnh hưởng đến danh sách commit của nhánh khác, chúng được sắp xếp theo thời gian trước sau. Chỉ khi merge nhánh này với nhánh kia thì code mới được nhập chung với nhau.

Commit: Mỗi lần chúng ta làm xong chúng ta muốn báo cho Git lưu lại các thay đổi so với code nguyên bản trước khi sửa thì chúng ta cần lưu lại các thay đổi trong commit. Một commit là một lần chúng ta lưu lại code vào Git nó sẽ tự sinh ra 1 commit Id, chúng ta có thể quay về bất cứ commit nào trong lịch sử sửa code. Hoặc là tra xem sự khác nhau giữa các commit ra sao?

Merge code: Là hành động merge code giữa 2 nhánh code từ một nhánh A vào 1 nhánh B hoặc ngược lại, nhánh được merge sẽ chứa code của cả 2 nhánh và tạo ra một commit mới là merged commit.

Rebase code: Cũng là một hành động merge code nhưng không tạo ra commit mới là merged commit mà sắp xếp các commit theo thứ tự thời gian của cả 2 nhánh, history sẽ đẹp tuy nhiên 2 nhánh mà lâu không rebase sẽ phải so sánh theo thời gian từng commit một sẽ mất thời gian.

Conflict: Là sự xung đột khi merge code hay rebase khi mà cả 2 thành viên cùng sửa một đoạn code ở cả 2 nhánh lúc merge vào sẽ xung đột và Git hỏi xem muốn lấy sự thay đổi nào hoặc lấy cả 2.

Stash: Là tính năng lưu tạm các sự thay đổi vào local khi chúng ta đang làm code dở ở nhánh A nhưng lại chưa muốn commit thì chúng ta phải sang nhánh B để fix bug nên chúng ta phải stash lại để không bị mất code cũng không phải commit. Khi quay lại nhánh A sẽ apply stash để sửa tiếp.

Gitignore: Là file nằm trong repository chúng ta tạo ra với tên. gitignore nằm liệt kê các file hay folder nằm trong folder git mà chúng ta không muốn git tracking mà chỉ lưu ở local thôi. Nó sẽ không đánh dấu sự thay đổi khi có thay đổi trong cac file này.

Cài đặt Git trên máy Windows

Trên Windows hay Mac các bạn cứ vào đây download rồi cài trên máy: https://git-scm.com/ cài xong bật CMD Prompt chạy thử lệnh git nếu không lỗi là ok.

Các tính năng của Git cần thiết cho dự án mà bạn cần biết

Có rất nhiều lệnh trong Git nhưng trong quá trình mình làm việc thì mình chỉ cần sử dụng 15 lệnh như sau để làm việc với Git. Nên các bạn cũng không cần nhớ nhiều quá mà chỉ cần nhớ các lệnh bên dưới để làm việc tốt với Git.

Lệnh git init

Lệnh này dùng để khởi tạo một Repository trên máy local, tuy nhiên nó chưa được push lên server mà chúng ta vẫn có thể thao tác với tất cả các lệnh như bình thường và nó hoạt động như một repository thực thụ trừ share code cho các thành viên khác.

Copy

git init

Để init một repository thì chỉ cần vào một folder trống mở Command Prompt rồi gõ lệnh git init nếu thành công thì thư mục đó sẽ thành một Git repository các bạn có thể show hidden file and folders sẽ thấy thư mục tên là. git ẩn.

Lệnh git clone

Cách 2 để tạo một git repository là lệnh clone, lệnh này sẽ lấy code từ một Git service trên mạng được public và download về máy sau đó tự tạo luôn một Git repository local kết nối với git remote luôn. Ví dụ chúng ta cần download code của repository có tên eShopSolution về máy chúng ta cần chạy:

Copy

git clone https://github.com/teduinternational/eShopSolution.git

Lệnh git pull

Lệnh git pull dùng để cập nhật code mới từ trên remote server và nó cũng tự động merge code từ nhánh tương ứng trên server về, ví dụ chúng ta có nhánh develop trên server nó sẽ là tên của origin remote (origin/develop) nếu có ai commit và push code lên nhánh đó khi pull về nó sẽ tự merge code của họ ở nhánh đó vào nhánh develop trên máy chúng ta. Nhánh local trên máy và nhánh origin/develop liên kết với nhau qua cơ chế set upstream. Cú pháp là git pull origin hoặc git pull đều được. Nếu git pull thì mặc định nó sẽ lấy từ nhánh hiện tại còn chỉ ra nhánh sẽ pull từ nhánh đó. Thông thường chỉ cần switch sang nhánh cần pull bằng lệnh git checkout rồi gọi git pull. Trong trường hợp chúng ta có 1 remote repository thì chỉ cần git pull là đủ. Trừ khi có 2 repo thì chỉ ra tên remote repository

Copy

git pull

Lệnh git add

Lệnh git add nhằm add các file mới được tạo vào git tracking (stage), một file mới tạo ra sẽ ở chế độ unstage, khi chúng ta add vào stage thì mới commit được vào Git repository.

Để add toàn bộ sự thay đổi chúng ta dùng

Copy

git add *

Nếu không sẽ cần chỉ ra tên của file cần add thay vì dấu *

Lệnh git fetch

Git fetch cũng cập nhật thay đổi từ server nhưng không tự merge như git pull mà chỉ đóng vai trò get latest xem có commit nào mới từ server hay không nó tương đương F5 refresh vậy.

Copy

git fetch

Lệnh git remote

Lệnh này để thao tác với origin remote của chúng ta, ví dụ chúng ta có repository local nhưng khi muốn đưa code lên server Github chúng ta cần tạo một Repository trên Github và tạo origin trên đó sau đó mới đẩy code lên. Để tạo origin thì phải dùng lệnh này.

Lện dưới dùng để thêm một remote repository vào local repository với tên và url.

Copy

git remote add <remote_name> <url>

Lấy danh sách remote origin

Copy

git remote

Lệnh git reset

Lệnh này để xóa sự thay đổi của chúng ta về trạng thái ban đầu chưa sửa hoặc về bất cứ commit nào trong quá khứ

Reset về HEAD tức là về commit cuối cùng của nhánh đó:

Copy

git reset --hard HEAD       (về commit HEAD)
git reset --hard HEAD^      (về commit trước HEAD)
git reset --hard HEAD~1     (về trước 1 commit so với "^")
git reset --hard HEAD~2     (về commit trước 2 commit với HEAD)

Lệnh git checkout

Lệnh này chuyển nhánh trong Git giữa nhánh nọ nhánh kia

Copy

git checkout <branch_name>

Lệnh git commit

Lệnh này commit code changes vào Git với một commit message. Ví dụ: chúng ta commit sự thay đổi với message là "First commit":

Copy

git commit -m "First commit"

Lệnh git push

Lệnh này đẩy code đã commit lên remote repository

Copy

git push <remote_repository_name> <branch_name>

Lệnh git config

Lệnh này config các loại trong Git repository như user, email, tool merge code, tool editor...

tham khảo tại: https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-config

Ví dụ config user hiển thị trong các commit:

Copy

git config user.email "[email protected]"

Lệnh git merge

Lệnh này merge code nhánh nọ vào nhánh kia. Ví dụ đang ở nhánh A merge code vào nhánh B.

Copy

git merge nhanh_b

Lệnh git stash

Lệnh này tạo stash từ code change hoặc apply stash.

Copy

git stash save --lưu change hiện tại vào stash
git stash list --hiển thị danh sách stash
git stash apply <stash_name> --đẩy changes từ 1 stash vào một nhánh

Lệnh git status

Lệnh xem trạng thái của git repository xem đang ở nhánh nào có thay đổi gì không.

Copy

git status

Lệnh git branch

Lệnh này giống checkout để chuyển nhánh nhưng lại có thêm tính năng tạo nhánh mới.

Copy

git branch <branch_name> --tạo nhánh mới
git branch -b <branch_name> --checkout và tạo nhánh mới

Ngoài ra chúng ta có các lệnh khác như git log để xem lịch sử commit hay git diff để xem sự khác nhau trước khi commit nhưng thực tế thì ít dùng vì mình toàn xem thay đổi hay lịch sử ở Visual Studio hoặc ở Source Tree. Ít khi gõ lệnh vì xem ở đó trực quan hơn.

Ví dụ case thực tế

Để dễ hình dung hơn thì mình nêu ra một case thực tế trong dự án khi chúng ta khởi tạo một repository đồng thời commit tạo nhánh các kiểu nhé. Để xem mình sẽ phải chạy những lệnh nào nhé.

Copy

git init --> Khởi tạo một git repository trên local
git add README.md --> Add một file bất kỳ nên là 1 file README.md để mô tả (sử dụng markdown để ghi)
git commit -m "first commit" --> Commit file đó vào git
git branch -M master --> đổi tên nhánh thành master
git remote add origin https://github.com/teduinternational/test.git --> add một remote repository tên là origin với url là repository trên Github/
git push -u origin master --> Push nhánh master từ local lên nhánh master trên origin.

Sau khi có commit đầu tiên chúng ta có thể cần tạo thêm nhánh mới tên là develop để phát triển, nhánh master để nguyên bản đó để khi nào release bản 1.0 mới merge lên master vì master luôn đại diện cho code version đang chạy ở môi trường production.

Copy

git branch -b develop --> Tạo nhánh develop và thực hiện một số sự thay đổi
git add .gitignore --> Tạo file gitignore để thêm các thành phần muốn bỏ qua
git status --> Kiểm tra xem sự thay đổi có đúng không
git add * --> Thêm file gitignore vào stage area
git commit -m "Add gitignore file"
git push origin develop --> đẩy nhánh develop lên remote repository
git status --> Check tiếp xem có gì thay đổi và nhánh hiện tại là gì
git checkout master --> Chuyển nhánh hiện tại sang master
git fetch origin --> Lấy trạng thái mới nhất xem có ai commit lên master hay không
git pull origin master --> Nếu có thì pull về để lấy code mới nhất
git merge develop --> Merge file gitignore đang đặt ở nhánh develop sang master
git push origin master --> Lại đẩy sự thay đổi ở master dưới local lên master trên server.

Cứ như thế là chúng ta làm thử xem sao. Tự tạo tài khoản Github để thực hành nhé.

Tổng kết

Trên đây là tổng quan các lệnh của Git mà chúng ta cần biết khi làm việc với nó. Các bạn có thể tam khảo danh sách các tính năng của nó ở đây: https://git-scm.com/docs.

Các lệnh này để các bạn hiểu còn thực tế làm dự án khi nào cần dọa ai đó thì mới gõ lệnh còn lại thì IDE nào họ cũng hỗ trợ thao tác với git nên các thao tác chúng ta thường làm trên Editor như VSCode, Visual Studio hay tool UI phổ biến như Source Tree.

Tuy nhiên các bạn cần nên biết để nếu có không quen dùng tool hoặc thao tác nào tool không hỗ trợ thì gõ lệnh cho pro. Với lại ưu điểm thì lệnh chúng ta tua sẽ nhanh vì gõ xong họ lưu history nếu chỉ cần bấm mũi tên là nó hiện lại lệnh chúng ta vừa thực thi.