From 6ca02b7e32bfe4def6e3d159112bf45b24fb42d5 Mon Sep 17 00:00:00 2001 From: Mau Date: Tue, 14 Mar 2023 17:10:27 +0900 Subject: [PATCH] added vi translation for git sections --- 2022/vi/Days/day36.md | 154 ++++++++++++++++++++++++++++++ 2022/vi/Days/day37.md | 169 +++++++++++++++++++++++++++++++++ 2022/vi/Days/day38.md | 127 +++++++++++++++++++++++++ 2022/vi/Days/day39.md | 212 ++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 662 insertions(+) create mode 100644 2022/vi/Days/day36.md create mode 100644 2022/vi/Days/day37.md create mode 100644 2022/vi/Days/day38.md create mode 100644 2022/vi/Days/day39.md diff --git a/2022/vi/Days/day36.md b/2022/vi/Days/day36.md new file mode 100644 index 0000000..1acdab4 --- /dev/null +++ b/2022/vi/Days/day36.md @@ -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) diff --git a/2022/vi/Days/day37.md b/2022/vi/Days/day37.md new file mode 100644 index 0000000..98ae179 --- /dev/null +++ b/2022/vi/Days/day37.md @@ -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 ` | Tạo một git repository tron thư mục được chỉ định | +| git clone | `git clone ` | Sao chép repository tại 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 ` | Stage tất cả các thay đổi trong để chuẩn bị cho commit tiếp theo. Chúng ta có thể thêm và <.> cho tất cả mọi thứ. | +| git commit -m | `git commit -m ""` | Commit các file đã được staged, sử dụng để 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 ` | Tạo một commit mới hoàn tác lại tất cả các thay đổi trong trên branch hiện tại. | +| git reset | `git reset ` | Xoá 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 ` | Rebase nhanh hiện tại và trong . 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ố để tạo một branch với với tên . | +| git checkout | `git checkout -b ` | Tạo và checkout sang một branch mới tên . Bỏ -b flag để checkout sang một branch đã có sẵn. | +| git merge | `git merge ` | Merge và branch hiện tại. | + +### Git Remote Repositories + +| Lệnh | Ví dụ | Mô tả | +| -------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | +| git remote add | `git remote add ` | 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 thay cho trong các lệnh của bạn. | +| git fetch | `git fetch ` | Kéo một nhánh cụ thể có tên , từ repo. Bỏ để kéo tất cả các remote refs. | +| git pull | `git pull ` | 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 ` | Đẩy nhánh tới , 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 | `git config --global user.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 | `git config --global user.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 | `git config --global alias ` | Tạo một phím tắt cho lệnh git . | +| git config --system core.editor | `git config --system core.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. 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 | `git rebase -i ` | Rebase nhánh hiện tại vào . 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 | `git pull --rebase ` | 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 | `git reset ` | Di chuyển branch hiện tại về , reset khu vực staging reset về commit đó nhưng giữ nguyên khu vực làm việc. | +| git reset --hard | `git reset --hard ` | 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 . | + +### Git Push + +| Lệnh | Ví dụ | Mô tả | +| ------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| git push --force | `git push --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 --all | `git push --all` | Đẩy tất cả các nhánh ở local đến một remote xác định. | +| git push --tags | `git push --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) diff --git a/2022/vi/Days/day38.md b/2022/vi/Days/day38.md new file mode 100644 index 0000000..4361a6c --- /dev/null +++ b/2022/vi/Days/day38.md @@ -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) diff --git a/2022/vi/Days/day39.md b/2022/vi/Days/day39.md new file mode 100644 index 0000000..a58086a --- /dev/null +++ b/2022/vi/Days/day39.md @@ -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 ` + +![](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)