woose/90DaysOfDevOps
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #354 from vntechies/main

Browse Source
This commit is contained in:
Michael Cade 2023-03-18 06:14:23 +00:00 committed by GitHub
commit eb72224c1c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 808 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

140
2022/vi/Days/day35.md Normal file
View File

@ -0,0 +1,140 @@
---
title: '#90DaysOfDevOps - Bức tranh toàn cảnh: Git - Quản lý phiên bản - Ngày 35'
published: false
description: 90DaysOfDevOps - Bức tranh toàn cảnh Git - Quản lý phiên bản
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049041
---
## Bức tranh toàn cảnh: Git - Quản lý phiên bản
Trước khi bắt đầu tìm hiểu về git, chúng ta cần hiểu quản lý phiên bản là gì và tại sao chúng ta cần làm vậy? Trong bài mở đầu về git này, chúng ta sẽ đi qua khái niệm quản lý phiên bản và kiếm thức cơ bản về git.
### Quản lý phiên bản là gì?
Git không phải là hệ thống quản lý phên bản duy nhất, vì vậy ở đây chúng ta sẽ đề cập đến những lựa chọn và phương pháp có sẵn cho việc quản lý phiên bản.
Lợi ích rõ ràng nhất và lớn nhất của quản lý phiên bản là khả năng theo dõi lịch sử của dự án. Chúng ta có thể xem lại kho lưu trữ (repository) bằng cách sử dụng `git log` và xem lại toàn bộ các commit cũng như comments cũng như những gì đã diễn ra trong toàn bộ dự án. Đừng lo, chúng ta sẽ đi vào cách lệnh ở phần sau. Bây giờ, hãy tưởng tượng đây là một dự án phần mềm thực tế với rất nhiều mã nguồn và có nhiều người đang làm việc chung để phát triển sản phẩn tại các thời điểm khác nhau, tất cả các kỹ sư đã đóng góp code, và tất cả những người review code đều được ghi lại ở đây để cho chúng ta biết điều gì đã xảy ra, khi nào, bởi ai và ai đã review.
![](Images/Day35_Git1.png)
Quản lý phiên bản trước đây sẽ giống như việc tạo một bản sao phiên bản code của bạn theo cách thủ công trước khi bạn thực hiện các thay đổi. CÓ thể bạn cũng không cần sử dụng những phiên bản cũ nữa nhưng nó được tạo ra để bạn có thể yên tâm hơn, nhỡ đâu...
![](Images/Day35_Git2.png)
Tôi đã bắt đầu áp dụng quản lý phiên bản không chỉ đối với mã nguồn mà hầu hết mọi thứ, ví dụ như dự án này (90DaysOfDevOps). Tại sao lại không sử dụng các tính năng như khôi phục, ghi lại mọi thứ đã diễn ra.
Tuy nhiên, để tránh hiểu lầm **Quản lý phiên bản không hoạt động như một bản sao lưu**
Một lợi ích khác của quản lý phiên bản là khả năng quản lý nhiều phiên bản của một dự án. Lấy ví dụ như chúng ta có một ứng dụng miễn phí và sau đó là ứng dụng trả phí có sẵn trên tất cả các hệ điều hành. Phần lớn mã được chia sẽ giữa hai ứng dụng. Chúng tôi có thể sao chép và dán mã của mình cho từng commit vào từng ứng dụng, nhưng điều đó sẽ rất lộn xộn, đặc biệt là khi bạn mở rộng quy mô phát triển với nhiều nhân sự, cũng sẽ rất dễ mắc lỗi.
Ứng dụng trả phí là nơi chúng ta có các chứ năng bổ sung, hãy gọi chúng là các commit trả phí, bản miễn phí sẽ chỉ chứa các commit bình thường.
Cách chúng ta có thể làm được điều này trong quản lý phiên bản là thông qua phân nhánh (branching)
![](Images/Day35_Git3.png)
Phân nhánh cho phép hai luồng mã cùng tồn tại cho một ứng dụng như chúng ta đã nói ở trên. Nhưng chúng ta vẫn muốn các tính năm mới có trong phiên bản miễn phí có trong phiên bản trả phí, để làm được điều này, chúng ta có một thứ gọi là merge.
![](Images/Day35_Git4.png)
Bây giờ, điều này có vẻ dễ dàng nhưng việc merge có thể phức tạp vì bạn có thể có một nhóm làm việc trên phiên bản miễn phí và một nhóm khác làm việc với phiên bản trả phí và điều gì sẽ xảy ra nếu cả hai cùng thay đổi đến cấu trúc tổng thể của mã. CÓ thể một biến được cập nhật và làm hỏng phần nào đó. Sau đó, bạn có các conflict làm một chức năng không chạy được. Quản lý phiên bản không thể khắc phục được các conflict do bạn tạo ra. Nhưng quản lý phiên bản cho phép điều này được quản lý một cách dễ dàng.
Nói chung, lý do chính nếu bạn chưa sử dụng quản lý phiên bản cho tới thởi điểm này có thể là bạn chưa cộng tác bao giờ. Sẽ có ngày càng nhiều trường hợp mà chúng ta cần tới khả năng chia sẽ mã giữa các nhà phát triển. Có thể là một bài trình bày chung mà bạn đang làm việc với đồng nghiệp hoặc thử thách 90DaysOfDevOps, nơi bạn có cộng đồng và các chỉnh sửa, cập nhật sẽ được cộng đồng đóng góp trong suốt dự án.
Nếu không có quản lý phiên bản, làm thể nào các nhóm phát triển phần mềm có thể giải quyết vấn đề này? Tôi thấy thật khó khăn khi để theo dõi tất cả mọi thứ khi tôi đang thực hiện các dự án của mình. Tôi hi vọng họ sẽ chia nhỏ mã theo từng module chức năng một, có thể sẽ là từng miếng ghép nhỏ cho một bức tranh lớn để giải quyết các vấn đề trước khi tất cả được release.
Với quản lý phiên bản, chúng ta có một nguồn sự thật duy nhất (single source of truth). Chúng ta có thể làm việc trên các module khác nhau nhưng nó cho phép chúng ta cộng tác tốt hơn.
![](Images/Day35_Git5.png)
Một việc khác cần đề cập tới là không chỉ các nhà phát triển có thể hưởng lợi từ quản lý phiên bản, tất cả các thành viên và các công cụ có thể nhìn rõ dự án và tận dụng, các công cụ quản lý dự án có thể được liên kết và theo dõi tiến độ công việc. Chúng ta cũng có thể có một máy build, chẳng hạn như là một Jenkins server mà chúng ta sẽ nói trong phần sau. Một công cụ xây dựng mà nguồn và đóng gói hệ thống, tự động hoá quá trình kiểm thử và các metrics liên quan tới mã nguồn.
### Git là gì?
Git là một công cụ theo dõi các thay đổi đối với mã nguồn hoặc bất kỳ tệp nào hoặc cũng có thể nói Git là một hệt thống quản lý phiên bản phân tán mã nguồn mở.
Có nhiều cách à git có thể được sử dụng trên các hệ thống của chúng ta, phổ biến nhất hoặc ít nhất là đối với tôi, tôi đã sử dụng dòng lệnh (command line), nhưng chúng ta cũng có các công cụ và giao diện người dùng đồng hoạ như Visual Studio Code, các công cụ này có các chức năng của git mà chúng ta có thể tận dụng.
Bây giờ chúng ta sẽ xem qua một cách tổng quát trước khi cài đặt git trên máy của mình.
Hãy sử dụng thư mục mà chúng ta đã tạo trước đó.
![](Images/Day35_Git2.png)
Để sử dụng thư mục này với quản lý phiên bản, trước tiên chúng ta cần khởi tạo thư mục nào bằng lệnh `git init`. Hiện tại, chỉ cần nghĩ rằng lệnh này đặt thư mục của chúng ta làm kho lưu trữ trong cơ sở dữ liệu ở đâu đó trên máy tính của chúng ta.
![](Images/Day35_Git6.png)
Bây giờ chúng ta có thể tạo một số tệp và thư mục cho mã nguồn hoặc cũng có thể đã có sẵn từ trước đó. Sử dụng lệnh `git add .` sẽ đặt tất cả cá tệp và thư mục trong thư mục của chúng ta vào một chiếc hộp nhưng chúng ta chưa commit bất cứ thứ gì vào cơ sở dữ liệu đó. Thao tác này chỉ có nghĩ là tất cả các tệp có `.` đã sẵn sàng để được thêm vào.
![](Images/Day35_Git7.png)
Sau đó, chúng ta có thể muốn tiếp tục và commit các tệp của mình, việc này có thể thực hiện bằng lệnh `git commit -m "My First Commit"`. Chúng ta có thể đưa ra lý do cho commit của mình, điều này được khuyến khích để chúng ta có thể biết điều gì xảy ra trong mỗi commit.
![](Images/Day35_Git8.png)
Bây giờ chúng ta có thể thấy những gì xảy ra trong lịch sử của dự án. Sử dụng lệnh `git log`
![](Images/Day35_Git9.png)
Nếu chugns ta tạo một tệp bổ sung có tên là `samplecode.ps1`, thì trạng thái sẽ bị thay đổi. Chúng ta cũng có thể kiểm tra trạng thái của kho lưu trữ của mình bằng cách sử dụng `git status`, lệnh này cho chúng ta thấy không có gì để commit và chúng ta có thể thêm một tệp mới có thên samplecode.ps1. Sau đó, nếu chạy lại lệnh `git status` một lần nữa bạn sẽ thấy file mà chúng ta có thể commit.
![](Images/Day35_Git10.png)
Thêm tệp mới của chúng ta bằng lệnh `git add samplecode.ps1` và sau đó chạy lại lệnh `git status` một lần nữa và thấy tệp này đã được sẵn sàng để commit.
![](Images/Day35_Git11.png)
Sau đó dùng lệnh `git commit -m "My Second Commit"`.
![](Images/Day35_Git12.png)
`git status` bây giờ cũng thể hiện rằng chúng ta đã dọn dẹp mọi thứ.
![](Images/Day35_Git13.png)
Sau đó, chúng ta có thể sử dụng lệnh `git log` để hiện thị các commit mới nhất và commit đầu tiên.
![](Images/Day35_Git14.png)
Nếu chúng ta muốn xem các thay đổi giữa các lần commit của mình, tức là những tệp nào đã được thêm hoặc sửa đổi, chúng ta có thể sử dụng `git diff b8f8 709a`
![](Images/Day35_Git15.png)
Nó sẽ hiển thị những gì đã thay đổi, trong trường hợp của chúng ta, một tệp mới đã được thêm vào.
![](Images/Day35_Git16.png)
Chúng ta sẽ đi sâu hơn vào vấn đề này sau nhưng chúng ta có thể nhảy giữa các commit của mình, đại loại là chúng ta có thể du hành thời gian! Bằng cách sử dụng hash của commit, có thể sử dụng lệnh `git checkout 709a` để nhảy ngược thời gian mà không làm mất tệp mới của chúng ta.
![](Images/Day35_Git17.png)
Nhưng sau đó, chúng ta cũng sẽ muốn tiếp tục và có thể thực hiện điều này theo cách tương tự với hash của commit hoặc bạn có thể thấy như ở đây chúng ta sử dụng `git switch -` câu lệnh hoàn tác thao tác trước đó.
![](Images/Day35_Git18.png)
TLDR:
- Theo dõi lịch sử của một dự án
- Quản lý nhiều phiên bản khác nhau của một dự án
- Chia sẽ mã giữa các kỹ sư phát triển và mở rộng phạm vi các nhóm và công cụ sử dụng
- Phối hợp làm việc giữa các nhóm
- Ồ, và có thể du hành thời gian!
Điều này giống như một bước nhảy mới nhưng hy vọng rằng bạn có thể thấy bức tranh toàn cảnh đằng sau quản lý phiên bản mà không thực sự biết các câu lệnh cụ thể và sức mạnh của chúng.
Tiếp theo, chugsn ta sẽ cài đặt và thiết lập git trên máy cục bộ của bạn, đồng thời tìm hiểu sâu hơn một chút về một số trường hợp sử dụng và các câu lệnh trong Git.
## Tài liệu tham khảo
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
Hẹn gặp lại vào [ngày 36](day36.md)

154
2022/vi/Days/day36.md Normal file
View File

@ -0,0 +1,154 @@
---
title: '#90DaysOfDevOps - Cài đặt & Cấu hình Git - Ngày 36'
published: false
description: 90DaysOfDevOps - Cài đặt & Cấu hình Git
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048738
---
## Cài đặt & Cấu hình Git
GIt là một công cụ quản lý phiên bản ã nguồn mở, đa nền tảng. Nếu bạn giống tôi, sử dụng Ubuntu hoặc các hệ điều hành Linux khác, bạn có thể thấy rằng git đã được cài đặt sẵn, tuy nhiên chúng ta vẫn sẽ đi qua việc cài đặt và cấu hình nó.
Ngay cả khi bạn đã cài đặt git trên hệ thống của mình, bạn cũng nên đảm bảo rằng chúng ta luôn có bản cập nhật mới nhất.
### Cài đặt Git
Như đã đề cập, Git là công cụ đa nền tẳng, chúng ta sẽ nhắc tới Windows và Linux và bạn cũng có thể tìm thấy hướng dẫn cho macOS tại [đây](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
Đối với [Windows](https://git-scm.com/download/win), chúng ta có thể download trình cài đặt từ trang web chính thức.
Bạn cũng có thể sử dụng `winget` trên máy tính Windows của mình, và sử dụng nó như trình quản lý gói ứng dụng trên máy của bạn.
Trước khi chúng ta cài đặt bất cứ thứ gì, hãy kiểm tra phiên bản hiện tại trên máy của bạn. Mởi cửa sổ PowerShell và chạy `git --version`
![](Images/Day36_Git1.png)
Chúng ta cũng có thể kiểm tra phiên bản Git trên WSL Ubuntu của mình.
![](Images/Day36_Git2.png)
Tại thời điểm viết bài, bản phát hành mới nhất trên Windows là `2.35.1`, vì vậy tôi sẽ hướng dẫn việc update một vài thứ. Linux cũng có thể tương tự như vậy.
Sau khi tải xuống trình cài đặt phiên bản mới nhất và chạy qua trình hướng dẫn và ghi lại những điều đó tại đây. Lưu ý quan trọng là git sẽ gỡ cài đặt các phiên bản trước đó rồi mới cài đặt phiên bản mới nhất.
Có nghĩ là quy trình bên dưới cũng là quy trình mà chúng ta phải trải qua đối với việc bạn cài git lần đầu tiên.
Đây là một cài đặt khá đơn giản. Sau khi tài xuống, click đúp và bắt đầu. Đọc qua thoả thuận về giấy phép GNU. Nhưng hãy nhớ đây là phần mềm mã nguồn mở và miễn phí.
![](Images/Day36_Git3.png)
Bây giờ chúng ta có thể chọn các thành phần bổ sung mà chúng ta muốn cài đặt cũng như liên kết với git. Trên Windows, tôi luôn đảm bảo rằng mình đã cài đặt Git Bash vì điều này cho phép chúng ta chạy các lệnh bash trên Windows.
![](Images/Day36_Git4.png)
Sau đó, chúng ta có thể chọn phần mềm SSH mà chúng ta muốn sử dụng. Tôi chọn OpenSSH như bản có thể thấy trong phần tìm hiểu về Linux.
![](Images/Day36_Git5.png)
Chúng ta cũng có thể bật các tính năng thử nghiệm, đối với tôi, tôi không cần chúng nên đã không bật chúng, bạn luôn có thể quay lại việc cài đặt để bật các tính năng này.
![](Images/Day36_Git6.png)
Cài đặt hoàn tất, bây giờ chúng ta có thể chọn mở Git Bash hoặc đọc bản ghi chú cho bản phát hành mới nhất.
![](Images/Day36_Git7.png)
Bước kiểm tra cuối cùng là mở PowerShell và thử lại câu lệnh kiểm tra phiên bản git.
![](Images/Day36_Git8.png)
Sau các bước siêu đơn giản ở trên, chúng ta sẽ có phiên bản mới nhất của git. Đối với Linux, quá trình có thể sẽ mất thời gian hơn một chúng nhưng tôi cũng muốn nói qua về nó.
Tôi chỉ cần chạy lệnh `sudo apt-get install git`.
![](Images/Day36_Git9.png)
Bạn cũng có thể chạy các câu lệnh dưới dây để add thêm git repository cho các cài đặt phần mềm.
```
sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git -y
git --version
```
### Cấu hình Git
Khi lần đầu tiên sử dụng git, chúng ta phải xác định một số cài đặt sau.
- Tên
- Email
- Editor mặc định
- Ký tự kết thúc dòng
Điều này có thể thực hiện ở ba cấp độ.
- Hệ thống = tất cả người dùng
- Global = tất cả repositories của người dùng hiện tại
- Local = repository hiện tại
Ví dụ:
`git config --global user.name "Michael Cade"`
`git config --global user.email Michael.Cade@90DaysOfDevOPs.com"`
Tuỳ thuộc vào hệ điều hành của bạn, text editor mặc định sẽ được tự xác định. Với Ubuntu của tôi, câu lệnh tiếp theo sẽ sử dụng nano. Lệnh dưới đây sẽ thay đổi editor thành Visual Studio Code.
`git config --global core.editor "code --wait"`
bây giờ, nếu chúng ta muốn kiểm tra tất cả các cầu hình git thì có thể sử dụng lệnh sau
`git config --global -e`
![](Images/Day36_Git10.png)
Trên tất cả các máy, tệp này sẽ được đặt tên là `.gitconfig`. Trên máy Windows của tôi, bạn sẽ tìm thấy tệp này trong thư mục người dùng của mình.
![](Images/Day36_Git11.png)
### Lý thuyết Git
Tôi đã đề cập trong bài đăng ngày hôm qua rằng có các loại quản lý phiên bản khác nhau và chúng ta có thể chia thành hai loại chính. Một là Client-Server và loại còn lại là hệ phân tán.
### Quản lý phiên bản Client-Server
Trước khi git xuất hiện, Client-Server là phương thức chính để quản lý phiên bản. Ví dụ cho điều này sẽ là [Apache Subversion](https://subversion.apache.org/) là một một hệ thống kiểm soát phiên bản mã nguồn mở được ra mắt vào năm 2000.
Trong mô hình quản lý phiên bản Client-Server này, bước đầu tiên nhà phát triểu cần làm là tải xuống mã nguồn và các tệp từ máy chủ. Điều này không giải quyết các xung đột nhưng nó loại bỏ sự phức tạp của các xung đột và cách giải quyết chúng.
![](Images/Day36_Git12.png)
Bây giờ, giả sử chúng ta có hai nhà phát triển làm việc trên cùng một tệp và một người xong trước, upload file của họ lên server trước với những thay đổi của họ. Khi người thứ hai cập nhật file đó, xung đột sẽ xảy ra.
![](Images/Day36_Git13.png)
Vì vậy, bây giờ người thứ hai cần kéo thay đổi mã của người đầu tiên xuống và giải quyết các xung đột trong mã nguồn rồi sau đó mới commit lên máy chủ.
![](Images/Day36_Git15.png)
### Distributed Version Control
Git không phải là hệ thống quản lý phiên bản phân tán duy nhất. Nhưng nó rất thông dụng.
Một số lợi ích chính của Git là:
- Nhanh
- Thông minh
- Linh hoạt
- An toàn & Bảo mật
Khác với mô hình kiểm soát phiên bản Client-Server, mỗi nhà phát triển tải xuống một repository thì nó sẽ bao gồm tất cả mọi thứ. Lịch sử các commit, tất cả các nhánh,...
![](Images/Day36_Git16.png)
## Tài liệu tham khảo
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
Hẹn gặp lại vào [ngày 37](day37.md)

169
2022/vi/Days/day37.md Normal file
View File

@ -0,0 +1,169 @@
---
title: '#90DaysOfDevOps - Giới thiệu về Git - Ngày 37'
published: false
description: 90DaysOfDevOps - Giới thiệu về Git
tags: 'DevOps, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048707
---
## Giới thiệu về git
Trong hai bàì đăng trước, chúng ta đã tìm hiệu về quản lý phiên bản và một số quy trình, workflow của git với tư cách là một hệ thống quản lý phiên bản vào [ngày 35](day35.md) Sau đó chúng ta đã cài đặt git trên hệ thống, cập nhật và cấu hình. Chúng ta cũng đã đi sâu hơn một chút và điểm khác nhau cơ bản trong hệ thống quản lý phiên bản Client-Server và hệ thống quản lý phiên bản phân tán ví dụ như Git vào [ngày 36](day36.md).
Bây giờ, chúng ta sẽ tìm hiểu các câu lệnh cơ bản và trường hợp sử dụng chúng với git.
### Trợ giúp với git
Sẽ có lúc bạn không thể nhớ hoặc không biết lệnh cần sử dụng để hoàn thành công việc với git. Bạn sẽ cần giúp đỡ.
Google hoặc bất kỳ công cụ tìm kiểm nào có thể là điểm đến đầu tiên khi bạn tìm kiếm sự trờ giúp.
Tiếp sau đó có thể là trang chính thức của git và tài liệu. [git-scm.com/docs](http://git-scm.com/docs) Tại đây, bạn sẽ không những chỉ tìm thấy tài liệu tham khảo tốt cho tất cả các câu lệnh, mà còn có rất nhiều các tài nguyên khác.
![](Images/Day37_Git1.png)
Chúng ta cũng có thể truy cập tài liệu tương tự sau, điều này cực kỳ hữu ích nếu bạn không có kết nối nào từ terminal. Ví dụ: nếu chúng ta sử dụng lệnh `git add`, chúng ta có thể chạy `git add --help` và đọc hướng dẫn dưới đây.
![](Images/Day37_Git2.png)
Chúng ta cũng có thể dụng `git add -h` để cung cấp tống hợp các tuỳ chọn có sẵn mà chúng ta có thể sử dụng.
![](Images/Day37_Git3.png)
### Những câu chuyện xung quanh Git
"Git không có quyền kiểm soát truy cập" - bạn có thể trao quyền cho một leader để duy trì mã nguồn.
"Git quá nặng" - Git có thể cung cấp các kho lưu trữ nông (shallow repositories), có nghĩa là lịch sử git sẽ được cắt giảm nếu bạn có một project lớn.
### Những thiếu sót thực tế
Không phải là phương pháp lý tưởng cho các tệp nhị phân. Tuyệt vời cho mã nguồn nhưng không tuyệt vời cho các tệp thực thi hoặc video chẳng hạn.
Git không thân thiện với người dùng, việc chúng ta phải dành thời gian để nói và tìm hiểu các lệnh và chứng năng của công cụ có lẽ là minh chứng rõ ràng nhất cho việc đó.
Nhìn chung, git khó học nhưng dễ sử dụng.
### Hệ sinh thái git
Tôi muốn trình bày ngắn gọn về hệ sinh thái xung quanh git nhưng không đi quá sâu và việc đó. Điều quan trọng là phải nhắc đến ở góc độ high-level.
Hầu như tất cả các công cụ phát triển hiện đại đều hỗ trợ git.
- Công cụ phát triển - chúng ta đã đề cập tới Visual Studio Code, bạn sẽ tìm thấy các plugin và các tích hợp của git trong Sublime text và các trình soạn thảo văn bản và IDE khác.
- Công cụ nhóm - Cũng được đề cập trong các công cụ như Jenkins theo góc nhìn CI/CD, Slack từ góc độ dịch vụ nhắn tin và Jira từ góc độ quản lý dự án và theo dõi vấn đề.
- Cloud providers - Tất cả các nhà cung cấp điện toán đám mây lớn đều hỗ trợ git, Microsoft Azure, Amazon AWS và Google Cloud Platform.
- Các dịch vụ dựa trên Git - Sau đó, chúng ta có GitHub, GitLab và BitBucket mà chúng tôi sẽ đề cập rõ hơn ở phần sau. Các dịch vụ này có thể coi như là một mạng xã hội dành cho mã nguồn.
### Git Cheatsheet
Chúng ta chưa đề cập đến hầu hết các lệnh này nhưng sau khi xem xét một số cheatsheet có sẵ, tôi cũng muốn ghi lại một số câu lệnh git và mục đích sử dụng của chúng. Chúng ta không cần phải nhớ tất cả những câu lệnh này, với việc thực hành và sử dụng nhiều hơn, bạn sẽ học được một số điều cơ bản về git.
Tôi đã lấy những câu lệnh từ [atlassian](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet) nhưng viết lại chúng và đọc mô tả là một cách hay để biết các lệnh làm gì cũng như bắt đầu thực hành trong công việc hàng ngày.
### Cơ bản về Git
| Lệnh | Ví dụ | Mô tả |
| ------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| git init | `git init <directory>` | Tạo một git repository tron thư mục được chỉ định |
| git clone | `git clone <repo>` | Sao chép repository tại <repo> vào máy local |
| git config | `git config user.name` | Khai báo tên người sử dụng cho tất cả các commit ở repository hiện tại, có các flag `system`, `global`, `local` để tuỳ chọn. |
| git add | `git add <directory>` | Stage tất cả các thay đổi trong <directory> để chuẩn bị cho commit tiếp theo. Chúng ta có thể thêm <files> và <.> cho tất cả mọi thứ. |
| git commit -m | `git commit -m "<message>"` | Commit các file đã được staged, sử dụng <message> để làm rõ thay đổi được commit là gì. |
| git status | `git status` | Liệt kê các tệp được staged, unstaged và untracked. |
| git log | `git log` | Hiển thị tất cả lịch sử commit bằng định dạng mặc định. Có các tuỳ chọn bổ sung với lệnh này.
| git diff | `git diff` | Hiển thị các thay đổi của các thay đổi chưa được stage. |
### Git Hoàn tác thay đổi
| Lệnh | Ví dụ | Mô tả |
| ---------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| git revert | `git revert <commit>` | Tạo một commit mới hoàn tác lại tất cả các thay đổi trong <commit> trên branch hiện tại. |
| git reset | `git reset <file>` | Xoá <file> khỏi stage, nhưng không thay đổi thư mục làm việc. Điều này unstaged một tệp nhưng không ghi đè bất cứ thay đổi nào. |
| git clean | `git clean -n` | Hiển thị tệp nào sẽ bị xoá khỏi thư mục làm việc. Sử dụng `-f` thay cho `-n` để thực hiện việc xoá. |
### Git viết lại lịch sử
| Lệnh | Ví dụ | Mô tả |
| ---------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| git commit | `git commit --amend` | Thay thế commit gần nhất bằng các thay đỏi đã được staged và ghép nó với commit cuối cùng. Sử dụng trong trường hợp chưa có gì được stage để thay đổi nội dung commit. |
| git rebase | `git rebase <base>` | Rebase nhanh hiện tại và trong <base>. <base> có thể là một commit ID, tên branch, tag hoặc một tham chiếu tương đối đến HEAD. |
| git reflog | `git reflog` | Hiện thị log của các thay đổi với HEAD của kho lưu trữ cục bộ (local repository). Thêm --relative-date hiển thị ngày tháng và --all để hiện thị tất cả các refs. |
### Git Phân nhánh (Branch)
| Lệnh | Ví dụ | Mô tả |
| ------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------- |
| git branch | `git branch` | Liệt kê tất cả các branch trong repo của bạn. Thêm đối số <branch> để tạo một branch với với tên <branch>. |
| git checkout | `git checkout -b <branch>` | Tạo và checkout sang một branch mới tên <branch>. Bỏ -b flag để checkout sang một branch đã có sẵn. |
| git merge | `git merge <branch>` | Merge <branch> và branch hiện tại. |
### Git Remote Repositories
| Lệnh | Ví dụ | Mô tả |
| -------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| git remote add | `git remote add <name> <url>` | Tạo một kết nối mới đến một remote repo. Sau khi thêm một remote, bạn có thể dùng <name> thay cho <url> trong các lệnh của bạn. |
| git fetch | `git fetch <remote> <branch>` | Kéo một nhánh cụ thể có tên <branch>, từ repo. Bỏ <branch> để kéo tất cả các remote refs. |
| git pull | `git pull <remote>` | Kéo một bản sau của nhánh hiện tại từ remote repo và ngay lập tức merge nó vào bản sao local. |
| git push | `git push <remote> <branch>` | Đẩy nhánh tới <remote>, cùng với các commits và objects. Tạo nhánh có thên trong remote repo nếu nó không tồn tại. |
### Git Diff
| Lệnh | Ví dụ | Mô tả |
| ----------------- | ------------------- | ---------------------------------------------------------------------- |
| git diff HEAD | `git diff HEAD` | Hiển thị sự khác biệt giữa thư mục làm việc và commit cuối cùng. |
| git diff --cached | `git diff --cached` | Hiện thị sự khác biệt giữa các thay đổi đã được staged và commit cuối cùng |
### Git Config
| Lệnh | Ví dụ | Mô tả |
| ---------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| git config --global user.name <name> | `git config --global user.name <name>` | Khai báo tên người dùng sẽ được sử dụng cho tất cả các commit ủa người dùng hiện tại. |
| git config --global user.email <email> | `git config --global user.email <email>` | Khai báo email sẽ được sử dụng cho tất cả các commit của người dùng hiện tại. |
| git config --global alias <alias-name> <git-command> | `git config --global alias <alias-name> <git-command>` | Tạo một phím tắt cho lệnh git . |
| git config --system core.editor <editor> | `git config --system core.editor <editor>` | Cài đặt trình soạn thảo văn bản sẽ được sử dụng cho tất cả người dùng trên máy. <editor> phải là lệnh khởi chạy trình chỉnh sửa mong muốn |
| git config --global --edit | `git config --global --edit ` | Mở tệp cấu hình chung trong trình soạn thảo văn bản để chỉnh sửa thủ công. |
### Git Rebase
| Command | Example | Description |
| -------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| git rebase -i <base> | `git rebase -i <base>` | Rebase nhánh hiện tại vào <base>. Khởi chạy trình chỉnh sửa cho phép chỉnh sửa các commit khi chuyển qua base mới. |
### Git Pull
| Lệnh | Ví dụ | Mô tả |
| -------------------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| git pull --rebase <remote> | `git pull --rebase <remote>` | Kéo các bản sao của nhánh hiện tại trên remote và rebasse vào bản sao tại local. Sử dụng git rebase thay cho merge để gộp các nhánh. |
### Git Reset
| Lệnh | Ví dụ | Mô tả |
| ------------------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| git reset | `git reset ` | Reset khu vực staging về commit gần nhất nhưng giữ nguyên thư mục làm việc. |
| git reset --hard | `git reset --hard` | Reset khu vực staging về commit gần nhất và ghi đè lên tất cả các thay đổi trong thư mục làm việc. |
| git reset <commit> | `git reset <commit>` | Di chuyển branch hiện tại về <commit>, reset khu vực staging reset về commit đó nhưng giữ nguyên khu vực làm việc. |
| git reset --hard <commit> | `git reset --hard <commit>` | Giống với lệnh trước đó nhưng reset cả khu vực staging, thư mục làm việc. Xoá bỏ các thay đổi chưa được commit và tất cả các commit phía sau <commit>. |
### Git Push
| Lệnh | Ví dụ | Mô tả |
| ------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| git push <remote> --force | `git push <remote> --force` | Ép buộc git đảy lên ngay cả khi kết quả không phải là một non-fast-forward merge. Không sử dụng --force trừ khi bạn biết chắc chắn mình đang làm gì. |
| git push <remote> --all | `git push <remote> --all` | Đẩy tất cả các nhánh ở local đến một remote xác định. |
| git push <remote> --tags | `git push <remote> --tags` | Tage không được tự động đẩy lên khi bạn đẩy một nhánh hay sử dụng --all. --tags sẽ gửi tất cả những local tags lên remote repo. |
## Resources
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
Hẹn gặp lại vào [ngày 38](day38.md)

127
2022/vi/Days/day38.md Normal file
View File

@ -0,0 +1,127 @@
---
title: '#90DaysOfDevOps - Staging & Changing - Ngày 38'
published: false
description: 90DaysOfDevOps - Staging & Changing
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1049042
---
## Staging & Changing
Chúng ta đã đề cập đến một số điều cơ bản nhưng việc đưa mọi thứ vào một kịch bản hoàn chỉnh giúp tôi học và hiểu cách thức, lý do chúng ta thực hiện theo cách này tốt hơn. Trước khi chúng ta sử dụng bất kỳ dịch vụ dựa trên git nào như GitHub, git có các chức năng mà bạn có thể tận dụng trên máy của mình.
Chúng ta sẽ lấy thư mục dự án mà chúng ta đã tạo ở bài dầu tiên về git và đi qua lần lượt các bước với git. Chúng ta tạo một thư mục trên máy của mình và khởi tạo git với lệnh `git init`.
![](Images/Day38_Git1.png)
Chúng ta cũng có thể thấy rằng thư mục đã được khởi tạo có một thư mục ẩn.
![](Images/Day38_Git2.png)
Đây là nơi lưu trữ thông tin chi tết về git repository cũng như thông tin liên quan đến các nhánh và commit của chúng ta.
### Stage các tệp
Chúng ta bắt đầu làm việc với thư mục rỗng hoặc có thể chúng ta có một số mã nguồn vào những ngày làm việc trước đó. Đầu tiên, chúng ta tạo tệp readme.md và có thể thấy tệp đó trong thư mục, tiếp theo chúng ta kiểm tra với `git status` và git đã biết về tệp readme.md nhưng chúng ta chưa commit tệp đó.
![](Images/Day38_Git3.png)
Chúng ta có thể stage tệp readme.md với lệnh `git add README.md` và có thể thấy thay đổi có thể được commit mà trước đó cũng ta không có và một tệp mới màu xanh lá cây.
![](Images/Day38_Git4.png)
Tiếp theo chúng ta sẽ commit tệp này với commit đầu tiên của chúng ta. Chúng ta có thể làm điều này với lệnh `git commit -m "Meaningful message"` để có thể dễ dàng hiểu rằng mỗi commit đã thay đổi điều gì. Ngoài ra, hãy chú ý rằng chữ thập màu vàng bây giờ đã thay đổi thành dấu tính màu xanh lá cây. Đây là thứ tôi có trong terminal của mình với theme mà tôi sử dụng, thứ mà chúng ta đã đề cập trong phần nói về Linux.
![](Images/Day38_Git5.png)
### Commit các thay đổi
Chúng ta rất có thể muốn thêm nhiều tệp hơn hoặc thậm chí thay đổi các tệp chúng ta có trong thư mục của mình. Chúng tôi đã thực hiện commit đầu tiên của mình ở trên. Nhưng bây giờ, chúng ta sẽ thêm nhiều chi tiết và nhiều tệp hơn.
Chúng ta có thể lặp lại các quy trình của mình như trước đó, tạo hoặc chỉnh sửa tệp của mình > `git add .` để thêm tất cả các file vào khu vực staging sau đó sử dụng `git commit -m "meaningful message"`. Nhưng để đưa ra một thông điệp có ý nghĩa cho thay đổi trong commit của mình, bạn có lẽ không nên viết ra những thứ như `git commit -m "Chà, tôi đã thay đổi một số mã vì nó không hoạt động và khi tôi sửa mã đó, tôi cũng đã thêm một số thứ mới trong readme.md để đảm bảo rằng mọi người đều biết về trải nghiệm của người dùng và sau đó tôi pha một ấm trà."` Ý tôi là điều này cũng có thể sẽ hiệu quả mặc dù hơi dài dòng nhưng các tốt hơn ở đây là nên thêm thông điệp bằng một trình soạn thảo văn bản.
Nếu chúng ta chạy `git commit` sau khi chạy `git add`, git sẽ mở trình soạn thảo văn bản mặc định của chúng ta, trong trường hợp của tôi là nano. Dưới đây là các bước tôi đã thực hiện để thêm một số thay đổi vào tệp, chạy `git status` để thấy những thứ đã được staged và chưa được staged. Sau đó, tôi đã sử dụng `git add` để thêm tệp vào khu vực staging, cuối cùng là lệnh `git commit` để mở nano.
![](Images/Day38_Git6.png)
Khi nano mở ra, bạn có thể thêm mô tả ngắn hoặc dài của mình rồi lưu lại tệp.
![](Images/Day38_Git7.png)
### Best Practices khi Commit
Ở đây có sự cân bằng giữa việc commit khi nào và commit thường xuyên. Chúng ta không muốn đợi đến cuối dự án trước khi commit, mỗi commit phải có ý nghĩa và chúng cũng không được kết hợp các nhiệm vụ không liên quan tới nhau. Nếu bạn có một bản sửa lỗi và một lỗi đánh máy, hãy chắc chắn rằng chúng là hai commit riêng biệt như một best practice.
Làm cho thông điệp commit có ý nghĩa.
Về cách diễn đạt, nhóm hoặc bạn nên tuân theo một cách diễn đạt cho mỗi lần commit.
### Bỏ qua khu vực staging
Có phải chúng ta luôn phải stage các thay đổi của mình trước khi commit chúng?
Câu trả lời là có nhưng đừng coi đây là một lối tắt, bạn phải chắc chắn 100% rằng bạn không cần một snapshot để quay lại, đó là một việc làm mạo hiểm.
![](Images/Day38_Git8.png)
### Xoá tệp
Còn việc xoá tệp khỏi dự án của chúng tôi thì sao, có thể chúng ta có một tệp khác trong thư mục mà chúng ta đã cam kết nhưng hiện tại dự án không còn cần hoặc sử dụng tệp đó nữa, các tốt nhất là chúng ta nên xoá tệp đó.
Chỉ vì chúng ta xoá tệp đó khỏi thư mục, git vẫn biết tệp này và chúng ta cũng cần xoá tệp khỏi repository. Bạn có thể thấy workflow như bên dưới.
![](Images/Day38_Git9.png)
Nó có thể hơi khó nhớ hoặc khó thực hiện nếu bạn có một dự án lớn với nhiều tệp và thư mục cần xoá. Chúng ta có thể làm điều này với một lệnh duy nhất `git rm oldcode.ps1`.
![](Images/Day38_Git10.png)
### Đổi tên hoặc Di chuyển tệp
Trong hệ điều hành của chúng ta, chúng ta có thể đổi tên và di chuyển các tệp của mình. Chúng ta chắc chắn sẽ cần phải làm điều này rất nhiều lần trong dự án của chúng ta. Tương tự như xoá, quy trình sẽ gồn 2 bước, chúng ta thay đổi các tệp trên hệ điều hành của mình, sau đó sửa đổi và đảm bảo rằng khu vực staging hoặc các tệp được thêm vào một các chính xác. Các bước như sau:
![](Images/Day38_Git11.png)
Tuy nhiên, giống như xoá các tệp khỏi hệ điều hành và sau đó là git repository, chúng ta có thể thực hiện việc đổi tên này bằng cách sử dụng lệnh git.
![](Images/Day38_Git12.png)
### Bỏ qua tệp (ignore files)
Chugns ta có thể có yêu cầu bỏ qua các tệp hoặc thư mục trong dự án của mình, thứ mà chúng ta chỉ sử dụng ở local hoặc nó sẽ tốn không gian nếu chia sẻ với toàn bộ dự án, một ví dụ tốt có thể là các logs. Tôi cũng nghĩ nên sử dụng điều này cho các file bí mật (secrets) mà bạn không muốn chia sẻ công khai hoặc giữa các nhóm.
Chúng ta có thể bỏ qua các tệp bằng cách thêm các thư mục hoặc tệp vào tệp `.gitignore` trong thư mục dự án của chúng ta.
![](Images/Day38_Git13.png)
Bạn có thể mở tệp `.gitignore` và thấy rằng chúng ta có thư mục log/. Nhưng chúng ta vẫn có thể thêm các tệp và thư mục tại đây để chúng được bỏ qua.
![](Images/Day38_Git14.png)
Sau đó chúng ta có thể kiểm tra `git status` và xem điều gì đã xảy ra.
![](Images/Day38_Git15.png)
Cũng có những ách mà bạn có thể cần quay lại và bỏ qua các tệp và thư mục, có thể bạn muốn chia sẻ thư mục logs nhưng sau đó nhận ra bạn không muốn. Bạn sẽ phải dùng lệnh `git rm --cached ` để xoá tệp và thư mục khỏi khu vực staging nếu bạn có một thư mục đã theo dõi trước đó mà bây giờ bạn muốn bỏ qua.
### Trạng thái ngắn
Chúng ta đã sử dụng `git status` rất nhiều để hiểu những gì chúng ta có trong khu vực staging của mình và những gì chúng ta không có, đây là một lệnh rất toàn diện với nhiều thông tin chi tiết. Dần dần, hầu hết những gì bạn muốn biết là cái gì đã được sửa đổi hoặc có gì mới. Chúng ta có thể sử dụng `git status -s` cho một bản tóm tắt ngắn của các chi tiết này. Tôi thường đặt một phím tắt trên hệ thống của mình để chỉ sử dụng `git status -s` so với lệnh chi tiết đầy đủ
![](Images/Day38_Git16.png)
Trong bài đăng ngài mai, chúng ta sẽ tiếp tục xem qua các ví dụ ngắn về các lệnh git phổ biến.
## Tài liệu tham khảo
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
Hẹn gặp lại vào [ngày 39](day39.md)

212
2022/vi/Days/day39.md Normal file
View File

@ -0,0 +1,212 @@
---
title: '#90DaysOfDevOps - Xem, unstaging, loại bỏ & khôi phục - Ngày 39'
published: false
description: '90DaysOfDevOps - Xem, unstaging, loại bỏ & khôi phục'
tags: 'devops, 90daysofdevops, learning'
cover_image: null
canonical_url: null
id: 1048827
---
## Xem, unstaging, loại bỏ & khôi phục
Tiếp tục với ngày hôm qua sau khi đã thực hành một số lệnh của git và thực hành với dự án mới của bạn. Hãy nhớ rằng, chúng ta chưa nhắc tới GitHub hoặc bất kỳ dịch vụ nào dựa trên git. Tất cả những điều được nhắc tới cho đến bây giờ giúp bản kiểm soát cục bộ các dự án của mình tại thời điển này nhưng chúng sẽ trở nên hữu ích khi bạn tích hợp với các công cụ được nhắc đến ở trên.
### Xem các thay đổi được staged và chưa được staged
Bạn nên xem các đoạn mã đã đước staged và chưa được staged trước khi commit. Chúng ta có thể làm điều này với lệnh `git diff --staged`
![](Images/Day39_Git1.png)
Điều này sau đó cho chúng ta thấyt tất cả những thay đổi chúng ta đã thực hiện và tất cả các tệp mới mà chúng ta đã thêm hoặc xoá.
Các thay đổi trong các tệp được biểu thị bằng `---` hoặc `+++` bạn có thể thấy như dưới dây, chúng ta vừa thêm dòng mới "+add some text".
![](Images/Day39_Git2.png)
Chúng ta cũng có thể chạy `git diff` để so sánh khu vực staging với thư mục làm việc của chúng ta. Nếu như thực hiện một số thay đổi với tệp code.txt mới được thêm vào và thêm một số dòng.
![](Images/Day39_Git3.png)
Nếu sau đó chúng ta chạy lệnh `git diff`, chúng ta sẽ so sánh và có kết quả như dưới đây.
![](Images/Day39_Git4.png)
### Công cụ Diff trực quan
Đối với tôi, những hiển thị ở trên rất khó hiểu nên tôi muốn sử dụng một công cụ trực quan hơn, dưới đây là một vài công cụ trực quan để xem được diff:
- KDiff3
- P4Merge
- WinMerge (chỉ cho Windows)
- VSCode
Để thiết lập điều này với git, bạn chạy lệnh sau `git config --global diff.tool vscode`
Chúng ta sẽ chạy phần trên và sẽ đặt một số tham số khi khởi chạy VScode.
![](Images/Day39_Git5.png)
Chúng ta cũng có thể kiểm tra cấu hình của mình với `git config --global -e`
![](Images/Day39_Git6.png)
Sau đó, chúng ta có thể sử dụng `git difftool` để mở công cụ trực quan.
![](Images/Day39_Git7.png)
Sau đó, mở trang diff trên VSCode và so sánh 2 trang, chúng ta chỉ sửa đổi một tệp từ không có gì thành thêm một dòng mã như ở màn hình bên phải.
![](Images/Day39_Git8.png)
Tôi thấy phương pháp này dễ dàng hơn nhiều để theo dõi các thay đổi và đây là phương pháp tương tự như những gì chúng ta sẽ thấy khi sử dụng các dịch vụ dựa trên git như GitHub.
Chúng ta cũng có thể sử dụng `git difftool --staged` để so sánh stage với các tệp đã được commit.
![](Images/Day39_Git9.png)
Sau đó, chúng ta có thể duyệt qua các tệp đã thay đổi của mình trước khi commit.
![](Images/Day39_Git10.png)
Tôi đang sử dụng VSCode làm IDE của mình và giống như hầu hết các IDE khác, chúng có chức năng này được tích hợp sẵn, rất hiếm khi bạn cần chạy các lệnh này từ terminal, mặc dù nó rất hữu ích nếu bạn không có sẵn IDE bởi một lý do nào đó.
### Xem lại lịch sử
Trước đây chúng ta đã đề cập đến `git log` sẽ cung cấp một cái nhìn toàn diện về tất cả các commit mà chúng ta đã thực hiện trong kho lưu trữ của mình.
![](Images/Day39_Git11.png)
Mỗi commit có chuỗi thập lục phân, duy nhất cho kho lưu trữ. Tại đây, bạn có thể xem chúng ta đang làm việc trên nhánh nào và sau đó là tác giả, ngày tháng và nội dung commit.
Chúng ta cũng có `git log --oneline` và điều này mang lại một phiên bản ngắn gọn hơn nhiều của chuỗi thập lục phân mà chúng ta có thể sử dụng trong các lệnh `diff`. Chúng ta cũng chỉ có một dòng mô tả cho các commit.
![](Images/Day39_Git12.png)
Chúng ta có thể đảo ngược điều này và bắt đầu với commit hận đầu tiên bằng cách chạy `git log --oneline --reverse`, chúng ta thấy commit đầu tiên của mình ở đầu trang.
![](Images/Day39_Git13.png)
### Xem một commit
Việc có thể xem nội dung commit là một điều tuyệt vời nếu bạn có ý thức tuân theo các best practices và có những nội dung commit có ý nghĩa. Tuy nhiên, cũng có lệnh `git show` cho phép chúng tôi kiểm tra và xem một commit.
Chúng ta có thể sử dụng `git log --oneline --reverse` để lấy danh sách các commit của mình rồi lấy chúng và chạy `git show <commit ID>`
![](Images/Day39_Git14.png)
Đầu ra của lệnh đó sẽ giống như bên dưới với chi tiết về commit, tác giả và những gì đã thay đổi.
![](Images/Day39_Git15.png)
Chúng ta cũng có thể sử dụng `git show HEAD~1` trong đó 1 là số bước quay lại từ phiên bản hiện tại.
Điều này rất hữu ích nếu bạn muốn biết một số chi tiết về tệp của mình, nhưng nếu chúng ta muốn liệt kê tất cả các tệp trong một cây cho toàn bộ snapshot của thư mục. Chúng ta có thể sử dụng lệnh `git ls-tree HEAD~1`, một lần nữa quay lại một snapshot từ commit cuối cùng. Chúng ta có thể thấy có hai blobs, những blobs này biểu thị các tệp trong khi cây biểu thị một thư mục. Bạn cũng có thể thấy các commit và tags.
![](Images/Day39_Git16.png)
Sau đó, chúng ta có thể sử dụng phần trên để đi sâu vào và xem nội dung của tệp (blobs) bằng cách sử dụng lệnh `git show`.
![](Images/Day39_Git17.png)
Sau đó, nội dung của phiên bản cụ thể của tệp sẽ được hiển thị.
![](Images/Day39_Git18.png)
### Unstage tệp
Sẽ có lúc bạn có thể đã sử dụng `git add .` nhưng có những tệp bạn chưa muốn commit với snapshot đó. Trong ví dụ dưới đây, tôi đã thêm newfile.txt vào khu vực staging của mình nhưng tôi chưa sẵn sàng commit tệp này nên tôi sẽ sử dụng `git restore --staged newfile.txt` để hoàn tác bước `git add`.
![](Images/Day39_Git19.png)
Chúng ta cũng có thể thực hiện tương tự với các tệp đã sửa đổi, chẳng hạn như main.js và hủy thực hiện commit, như ở trên chúng tôi có chữ M màu xanh lá cây để sửa đổi và sau đó bên dưới chúng ta sẽ hủy thực hiện những thay đổi đó.
![](Images/Day39_Git20.png)
Tôi nhận thấy lệnh này khá hữu ích với 90DaysOfDevOps vì đôi khi tôi chuẩn bị cho nhiều ngày trước và cảm thấy muốn ghi chú lại nhưng tôi không muốn commit và đẩy lên kho lưu trữ GitHub công khai.
### Loại bỏ các thay đổi cục bộ
Đôi khi chúng ta có thể thực hiện các thay đổi nhưng chúng ta không hài lòng với những thay đổi đó và muốn loại bỏ chúng. Chúng ta sẽ sử dụng lại lệnh `git restore` và chúng ta sẽ có thể khôi phục các tệp từ snapshot hoặc các phiên bản trước đó. Chúng ta có thể chạy `git restore .` đối với thư mục của mình và nó sẽ khôi phục mọi thứ từ snapshot của mình, lưu ý rằng tệp chưa được theo dõi của chúng ta vẫn còn. Không có tệp có tên là newfile.txt được theo dõi trước đó.
![](Images/Day39_Git21.png)
Bây giờ để xóa newfile.txt hoặc bất kỳ tệp nào chưa được theo dõi. Chúng ta có thể sử dụng `git clean`.
![](Images/Day39_Git22.png)
Hoặc nếu chugns ta biết hậu quả, có thể muốn chạy `git clean -fd` để buộc và xóa tất cả các thư mục.
![](Images/Day39_Git23.png)
### Khôi phục tệp về một phiên bản cũ
Như chúng ta đã đề cập trong suốt phần lớn những gì Git có thể giúp là khôi phục các bản sao tệp của bạn từ các snapshot (đây không phải là bản sao lưu nhưng nó là một điểm khôi phục nhanh) Lời khuyên của tôi là bạn cũng nên lưu các bản sao mã của bạn ở các vị trí khác bằng giải pháp dự phòng cho việc này.
Ví dụ: hãy xóa tệp quan trọng nhất trong thư mục của chúng ta, lưu ý rằng chúng ta đang sử dụng các lệnh dựa trên Unix để xóa tệp này khỏi thư mục, không phải lệnh git.
![](Images/Day39_Git24.png)
Bây giờ, không còn readme.md trong thư mục làm việc của chúng tôi. Chúng ta có thể đã sử dụng `git rm readme.md` và nó sẽ được phản ánh trong cơ sở dữ liệu git. Chúng ta cũng hãy xóa nó khỏi đây để mô phỏng việc nó bị xóa hoàn toàn.
![](Images/Day39_Git25.png)
Let's now commit this with a message and prove that we no longer have anything in our working directory or staging area.
Bây giờ chúng ta hãy commit điều này và chứng minh rằng chúng ta không còn bất kỳ thứ gì trong thư mục làm việc hoặc khu vực tổ chức của mình.
![](Images/Day39_Git26.png)
Chúng ta đã sai lầm và giờ cần tệp đó trở lại!
Chúng ta có thể sử dụng lệnh `git undo` để hoàn tác commit cuối cùng, nhưng nếu đó diễn ra trước đó thì sao? Chúng ta có thể sử dụng lệnh `git log` để tìm các commit của mình và sau đó thấy rằng tệp nằm trong commit cuối cùng nhưng chúng ta không hoàn tác toàn bộ commit đó, vì vậy có thể sử dụng lệnh `git restore --source =HEAD~1 README.md` để tìm cụ thể tệp và khôi phục tệp từ snapshot của chúng ta.
Bạn có thể thấy bằng cách sử dụng quy trình này, giờ đây chúng ta có tệp trở lại trong thư mục làm việc.
![](Images/Day39_Git27.png)
We now have a new untracked file and we can use our commands previously mentioned to track, stage and commit our files and changes.
Bây giờ chúng ta có một tệp chưa được theo dõi mới và có thể sử dụng các lệnh đã đề cập trước đó để theo dõi, stage và commit các tệp và thay đổi của chúng ta.
### Rebase vs Merge
Đây dường như là vấn đề đau đầu nhất khi nói đến Git và khi nào nên sử dụng rebase hoặc merge trên kho git của bạn.
Điều đầu tiên cần biết là cả `git rebase` và `git merge` đều giải quyết cùng một vấn đề. Cả hai đều để tích hợp các thay đổi từ nhánh này sang nhánh khác. Tuy nhiên, chúng làm điều này theo những cách khác nhau.
Hãy bắt đầu với một tính năng mới trong một nhánh mới. Nhánh chính tiếp tục với các commit mới.
![](Images/Day39_Git28.png)
Lựa chọn dễ dàng ở đây là sử dụng `git merge feature main` sẽ hợp nhất nhánh main vào nhánh feature.
![](Images/Day39_Git29.png)
Merge rất dễ dàng vì nó không có tính phá hủy. Các nhánh hiện tại không bị thay đổi theo bất kỳ cách nào. Tuy nhiên, điều này cũng có nghĩa là nhánh tính năng sẽ có một merge commit không liên quan mỗi khi bạn cần kết hợp các thay đổi với upstream. Nếu main được commit liên tục và nhiều, điều này sẽ hoặc có thể làm bẩn lịch sử commit của nhánh feature.
Là một tùy chọn thay thế, chúng ta có thể đặt lại nhánh feature lên nhánh main bằng cách sử dụng
```
git checkout feature
git rebase main
```
Điều này chuyển nhánh feature (toàn bộ nhánh feature) kết hợp hiện quả với tất cả các commit mới trong nhánh main. Tuy nhiên, thay vì sử dụng một merge commit, việc rebase sẽ viết lại lịch sử commit bằng cách tạo các commit hoàn toàn mới cho mỗi commit trong nhánh ban đầu.
![](Images/Day39_Git30.png)
Lợi ích lớn nhất của việc rebase là lịch sử dự án rõ ràng hơn nhiều. Nó cũng loại bỏ các merge commit không cần thiết. Và khi bạn so sánh hai hình ảnh cuối cùng, bạn có thể theo dõi lịch sử dự án tuyến tính rõ ràng hơn nhiều.
Mặc dù đó vẫn không phải là một kết luận có thể bỏ qua, nhưng việc chọn lịch sử sạch hơn cũng đi kèm với sự đánh đổi. Nếu bạn không tuân theo [Quy tắc vàng của rebase](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) việc viết lại lịch sử dự án có thể là thảm họa đối với quy trình cộng tác của bạn. Và ít quan trọng hơn, việc rebase lại làm mất context được cung cấp bởi một merge commit — bạn không thể biết khi nào các thay đổi upstream được tích hợp vào feature.
## Tài liệu tham khảo
- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
- [Exploring the Git command line – A getting started guide](https://veducate.co.uk/exploring-the-git-command-line/)
Hẹn gặp lại vào [ngày 40](day40.md)

13
2022/vi/README.md
View File

@ -72,14 +72,13 @@ Cách nhanh nhất để liên lạc với tôi là thông qua Twitter tại [@M
### Cách sử dụng Git hiệu quả
- [✔️] 📚 35 > [The Big Picture: Git - Version Control](Days/day35.md)
- [✔️] 📚 36 > [Installing & Configuring Git](Days/day36.md)
- [✔️] 📚 37 > [Gitting to know Git](Days/day37.md)
- [✔️] 📚 35 > [Bức tranh toàn cảnh: Git - Quản lý phiên bản](Days/day35.md)
- [✔️] 📚 36 > [Cài đặt & Cấu hình Git](Days/day36.md)
- [✔️] 📚 37 > [Giới thiệu về Git](Days/day37.md)
- [✔️] 📚 38 > [Staging & Changing](Days/day38.md)
- [✔️] 📚 39 > [Viewing, unstaging, discarding & restoring](Days/day39.md)
- [✔️] 📚 40 > [Social Network for code](Days/day40.md)
- [✔️] 📚 41 > [The Open Source Workflow](Days/day41.md)
- [✔️] 📚 39 > [Xem, unstaging, loại bỏ & khôi phục](Days/day39.md)
- [✔️] 📚 40 > [Mạng xã hội dành cho code](Days/day40.md)
- [✔️] 📚 41 > [Quy trình làm việc với mã nguồn mở](Days/day41.md)
### Containers
- [✔️] 🏗️ 42 > [The Big Picture: Containers](Days/day42.md)