[Công nghệ Thông tin] -- [Web] -- [Công nghệ phần mềm] -- [PhoThong] -- [TỪ ĐIỂN] -- [----] -- [Học viên cũ] -- [10.000 giờ]
--------------- <> -----------------
---  KHOA HỌC - CÔNG NGHỆ - GIÁO DỤC - VIỆC LÀM ---
---  Nhận làm website, web app, chạy quảng cáo, digital marketing --->>>  LIÊN HỆ...

Tìm kiếm trong Blog

Hiển thị các bài đăng có nhãn Git. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn Git. Hiển thị tất cả bài đăng

Học làm web (58_1) - Mini project HTML CSS

Tiếp theo của: Học làm web (58) - CSS căn bản (34)
----
Mini project (hosting, domain, git, HTML, CSS)

1) Tạo tài khoản trên hệ thống remote git bất kì (github, gitlab)

2) Tạo mỗi kho chứa cho mỗi dự án nhỏ, làm được dự án nào thì push code lên remote git

3) Tạo một hosting trên internet, tạo một trang index.html, trên đó có chứa link tới từng dự án của cá nhân

4) Mini project 1. Làm theo clip để tạo ra một số website hoàn chỉnh, học thêm về bố cục (layout) của một trang web.


5) Mini project 2. Làm theo clip để tạo một website hoàn chỉnh, đơn giản


6) Xem một số nguyên tắc khi viết mã HTML, CSS


7) Sử dụng Sublime Text hiệu quả


8) Sử dụng VS Code hiệu quả


9) Mini project 3. CSS3, Layout, Flex, Responsive, Mobile First

Xem và làm theo.

https://www.youtube.com/watch?v=8gNrZ4lAnAw

Hình ảnh và mã nguồn tham khảo: https://drive.google.com/open?id=17h5l4sLiKciOQr3afqr-Fn5rBfTULBuk

Một số ý lượm được từ clip trên:

– Để làm Front-end cần học HTML, CSS, JavaScript.

– Hai code editor được nhiều người đang sử dụng là VC code và Sublime Text.

– Khai báo class và id trong HTML để CSS và JavaScript sử dụng sau này

– HTML validation

– w3schools.com là một trong những website tin cậy để tham chiếu

– Đơn vị đo tương đối (relative) và tuyệt đối (absolute) trong CSS

– CSS functions, ví dụ: background-color: rgba(0,0,0,0.4)

– CSS media queries giúp thực hiện responsive giao diện

– Học một số lệnh cd, mkdir

– Sử dụng Live server trong VS code để tự động cập nhật kết quả trên trang web khi lập trình HTML, CSS

– Cách tổ chức bố cục (layout) của một trang web

– Để ý tính ngữ nghĩa khi dùng các phần tử HTML

– Mobile first trong HTML và CSS

– Sử dụng flex

– Tạo đường xiên của một hình bằng transform: skewY()

– Cách tạo góc nhọn của một hình bằng phần tử pseudo, ví dụ: container:before

– Responsive

10) Mini project 4. Tự làm theo mẫu có sẵn:



Hướng dẫn, gợi ý:

– Xem bố cục trang web gồm mấy vùng, tên mỗi vùng, cấu trúc cha-con

Đăt outline cho phần tử body để thấy được bố cục trên trang mẫu, thấy được quan hệ phân cấp của các phần tử

– Viết HTML, và CSS cho từng vùng

Do tính chất kế thừa của CSS, nên sẽ thực hiện CSS cho các phần tử cha trước sau đó đến các phần tử con.

Một bố cục tham khảo:

<body>
    <section id="page">
        <div id="main">
            <header id="header">
                <div class="header_top"></div>
                <div class="header_mid"></div>
                <div class="header_bot"></div>
            </header>
            <section id="middle"></section>
        </div>
        <footer id="footer"></footer>
    </section>
</body>

– fontello:


-----------
Cập nhật [09/12/2019]
-----------
Xem thêm: Tổng hợp các bài viết về Học làm web
Xem thêm: Học làm web (59) - JS căn bản (1)

Làm web (13) - Git: tích hợp căn bản

Bài học trước: Làm web (12) - Git: phân nhánh căn bản
-----
Cơ bản về tích hợp

Giả sử bạn đã hoàn thành công việc trên nhánh iss53 và quyết định tích hợp vào nhánh master. Nhánh master là nhánh được tích hợp vào, tạm gọi là nhánh chính, nhánh iss53 gọi là nhánh phụ. Để tích hợp, bạn cần chuyển con trỏ HEAD về nhánh chính, sau đó tích hợp bằng lệnh $ git merge.

Ví dụ,

Maxsys@DESKTOP-7LPDOL6 MINGW64 /e/langbiang (iss53)
$ git checkout master
Switched to branch 'master'

$ git merge iss53
Merge made by the 'recursive' strategy.
 index.html              |   2 +
 ting) test chuyen nhanh | 238 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 240 insertions(+)
 create mode 100644 index.html
 create mode 100644 ting) test chuyen nhanh

Sau khi gõ lệnh $ git merge iss53, Git sẽ mở một cửa sổ soạn thảo, cho phép nhập thông điệp (message) cho việc merge, bạn nhập thông điệp, đóng cửa sổ soạn thảo để Git hoàn thành việc tích hợp. Nếu không muốn Git mở cửa sổ soạn thảo thì thêm tham số -m “nội dung thông điệp” ngay trong lệnh $ git merge.

Ví dụ,

$ git merge iss53 -m “tich hop iss53 vao master”

Lần tích hợp này khác so với lần tích hợp nhánh hotfix trước đây. Ở lần này, lịch sử commit của master và iss53 đã đi theo hai nhánh khác nhau, do vậy, việc tích hợp không đơn là di chuyển con trỏ master tiến lên như khi tích hợp hotfix.

Xem hình minh họa,



Trong lần tích hợp này, Git sẽ tạo một commit mới, mà snapshot của commit chính là sự kết hợp của 3 snapshot khác, gồm: hai snapshot mới nhất của master và iss53, cùng với snapshot là “cha” chung (common ancestor) của master và iss53. Không giống như các commit thông thường chỉ có một commit cha, commit được tạo ra bởi quá trình merge này sẽ có hai commit cha.

Xem kết quả,

$ git log --oneline --decorate --all --graph
*   7e24aee (HEAD -> master) Merge branch 'iss53'
|\
| * b765740 (iss53) da them logo [issue 53]
| * 1cef1be them logo cho home page
* | e31a627 sua lai logo
|/
* 47ed23e thay doi tren master branch
| * cd69866 (testing) test chuyen nhanh
|/
* a89362e (tag: v1.4-lw, tag: v1.3, tag: v1.2,

Xem hình minh họa,


  
Việc tích hợp đã hoàn thành, nhánh iss53 không còn cần thiết nữa, do vậy bạn có thể xóa nó đi, và kết thúc công việc có số hiệu #53.

$ git branch -d iss53
Deleted branch iss53 (was b765740).

$ git log --oneline --decorate --all --graph
*   7e24aee (HEAD -> master) Merge branch 'iss53'
|\
| * b765740 da them logo [issue 53]
| * 1cef1be them logo cho home page
* | e31a627 sua lai logo
|/
* 47ed23e thay doi tren master branch
| * cd69866 (testing) test chuyen nhanh
|/
* a89362e (tag: v1.4-lw, tag: v1.3, tag: v1.2,

Giải quyết xung đột khi tích hợp

Việc trộn nhánh không phải luôn luôn thành công. Có thể có xung đột (confict) giữa hai nhánh. Xung đột sẽ xảy ra nếu trước đó, ở trên cả hai nhánh, bạn đều sửa trên cùng một vị trí của cùng một tập tin, nghĩa là Git không thể lấy nội dung này đè lên nội dung kia. Khi đó Git sẽ thông báo nội dung tích hợp bị xung đột.

Ví dụ,

Maxsys@DESKTOP-7LPDOL6 MINGW64 /e/langbiang (master)
$ git merge iss123 -m "tich hop iss123 vao master"
Auto-merging conflict_test.txt
CONFLICT (content): Merge conflict in conflict_test.txt
Automatic merge failed; fix conflicts and then commit the result.

Khi bị xung đột, Git sẽ không tự động tạo ra commit mới cho việc tích hợp. Nó sẽ ngưng lại, và chờ bạn xử lý phần nội dung bị xung đột. Để biết tập tin nào không được tích hợp do bị xung đột, sử dụng lệnh $ git status.

Ví dụ,

$ git status
On branch master
Your branch is ahead of 'origin/master' by 7 commits.
  (use "git push" to publish your local commits)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   conflict_test.txt

Các tập tin có xung đột mà chưa được xử lý được gọi là unmerged (chưa được tích hợp). Git sẽ sử dụng định dạng chuẩn (do Git quy định) để đánh dấu vùng nội dung bị xung đột. Bạn có thể mở tập tin có xung đột bằng trình soạn thảo mã nguồn bất kì (ví dụ notepad) để quan sát vùng xung đột. Ví dụ nội dung của tập tin conflict_test.txt sẽ như sau:

viet tren nhanh master
<<<<<<< HEAD
viet tren nhanh hotfix
=======
viet tren nhanh iss123
>>>>>>> iss123

Nội dung bị xung đột được đánh dấu bằng khối: <<<<<     ====     >>>>>. Trong đó, phần trên dấu ==== thuộc “nhánh chính” (trong ví dụ này là nhánh master, con trỏ HEAD đang trỏ tới master), phần dưới dấu ==== thuộc “nhánh phụ” (trong ví dụ này là nhánh iss123). Để xử lý xung đột, bạn có thể chọn phần trên, phần dưới hoặc kết hợp cả hai phần lại cho hợp lý. Ví dụ, bạn có thể xử lý xung đột trên bằng cách thay thế toàn bộ khối “<<<< …. >>>> iss123” bằng nội dung: “viet tren nhanh”.

Ba hàng có chứa <<<<, ====, và >>>> sẽ bị xóa đi. Sau khi đã xử lý các xung đột trên mỗi tập tin, bạn cần lưu lại, đóng chương trình soạn thảo, chạy lệnh $ git add <tên tập tin> để báo cho Git biết là xung đột đã được xử lý. Git xem các tập tin được đưa vào khu vực tổ là đã được xử lý xung đột.

Sau khi đã xử lý xung đột xong, bạn gõ lệnh $ git commit để hoàn thành việc tích hợp đang bị ngưng lại. Git sẽ mở lại thông điệp bạn đã nhập trong lệnh $ git merge trước đó, bạn có thể chỉnh sửa lại thông điệp nếu cần thiết, đóng cửa sổ soạn thảo thông điệp để hoàn thành việc trộn nhánh.

Ví dụ,

$ git commit
[master e71b39c] tich hop iss123 vao master

Xem kết quả,

$ git log --all --graph --decorate --oneline
*   e71b39c (HEAD -> master) tich hop iss123 vao master
|\
| * a8ac313 (iss123) them noi dung tren iss123
* | e90d0e6 (hotfix) them noi dung tren hotfix
|/
* 3993e98 them conflict_test file
*   7e24aee Merge branch 'iss53'

Bạn có thể cài đặt các công cụ giao diện đồ hoạ để xử lý xung đột. Ví dụ, công cụ meld (http://meldmerge.org/). Đọc thêm về các công cụ merge tại đây: https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_advanced_merging

Lab 30. Tạo ra tình huống có xung đột khi tích hợp.

– Làm việc trên local repo

– Trên nhánh master, tạo tập tin conflict_test.txt, nhập nội dung vào dòng đầu tiên “viet tren nhanh master”, commit

– Tạo hai nhánh hotfix và iss123

– Chuyển qua nhánh hotfix, nhập thêm nội dung cho conflict_test.txt vào dòng thứ 2 là “viet tren nhanh hotfix”, commit

– Chuyển qua nhánh iss123, nhập thêm nội dung cho conflict_test.txt vào dòng thứ 2 là “viet tren nhanh iss123”

– Tích hợp hotfix vào master

– Tích hợp iss123 vào master

– Xử lý xung đột thủ công bằng một trình soạn mã


– Thực hiện các thao tác còn lại để hoàn thành việc tích hợp.
-----------
Cập nhật [14/10/2019]
-----------
Xem thêm: Tổng hợp các bài viết về Làm web
Xem thêm: Làm web (14) - Git: quản lý nhánh

Làm web (06) - Git: xem lịch sử commit

Bài học trước: Làm web (05) - Git: thao tác với kho chứa (tiếp)
-----

3.3        Xem lịch sử commit

3.3.1     Git log


Đọc thêm ở đây (tiếng Anh):


Đọc thêm ở đây (tiếng Việt):


Xem clip (tiếng Việt):


Sau khi thực hiện nhiều commit hoặc lấy một kho chứa (clone) từ trên mạng về. Để xem những gì đã xảy ra, sử dụng lệnh git log.

Có thể sử dụng kho chứa đơn giản sau để chạy các ví dụ minh họa,

$ git clone https://github.com/legiacong/langbiang.git

Chạy lệnh git log để xem kết quả (lưu ý kết quả hiển thị có thể thay đổi),

$ git log
commit 0cf8354bcbd0ad93ebf5bf336f3e49a47a00d8f4 (HEAD -> master, origin/master, origin/HEAD)
Author: Lê Gia Công <legiacong@gmail.com>
Date:   Wed Mar 6 15:47:47 2019 +0700

    doi ten tap tin

commit a6c7b4268d5c421c6fe1b6e444bcff8abeb89c19
Author: Lê Gia Công <legiacong@gmail.com>
Date:   Wed Mar 6 15:45:27 2019 +0700

    doi ten

commit fa9d0684fe9914399e4fe75e1b996df3049176cd
Author: Lê Gia Công <legiacong@gmail.com>
Date:   Wed Mar 6 14:25:30 2019 +0700

    xóa log

commit 0918f5bf74cb0b08abb2e4aea3bfa84ae8b1eea5
Author: Lê Gia Công <legiacong@gmail.com>
Date:   Wed Mar 6 14:23:28 2019 +0700
:

(bấm Enter để xem các nội dung còn lại, bấm q để thoát)

Mặc định, khi không có tham số, lệnh git log sẽ liệt kê các commit của kho chứa theo thứ tự thời gian, từ mới nhất đến cũ hơn. Thông tin của mỗi commit gồm: mã băm SHA-1, tên người commit, địa chỉ email, ngày commit và thông điệp đi kèm.

Lệnh git log có nhiều tham số đi kèm, giúp quan sát thông tin theo nhiều tiêu chí khác nhau. Phần sau sẽ tìm hiểu một số trường hợp hay sử dụng.

Tham số -p sẽ hiển thị diff của từng commit, sử dụng thêm tham số -2 để chỉ hiển thị 2 commit gần nhất.

$ git log -p -2
commit 0cf8354bcbd0ad93ebf5bf336f3e49a47a00d8f4 (HEAD -> master, origin/master, origin/HEAD)
Author: Lê Gia Công <legiacong@gmail.com>
Date:   Wed Mar 6 15:47:47 2019 +0700

    doi ten tap tin

diff --git a/taptin1.doc b/taptin2.doc
similarity index 100%
rename from taptin1.doc
rename to taptin2.doc
C:\Users\Maxsys\AppData\Local\Temp/9Gifna_taptin1.doc is not a Word Document.
C:\Users\Maxsys\AppData\Local\Temp/OZlbYa_taptin2.doc is not a Word Document.

commit a6c7b4268d5c421c6fe1b6e444bcff8abeb89c19
Author: Lê Gia Công <legiacong@gmail.com>
Date:   Wed Mar 6 15:45:27 2019 +0700

    doi ten

diff --git a/abc/New Text Document.txt b/abcd/New Text Document.txt
similarity index 100%
rename from abc/New Text Document.txt
rename to abcd/New Text Document.txt

Nhờ tham số diff, giúp bạn xem lướt qua các thay đổi đã được thực hiện trên kho chứa, ai đã thực hiện, thực hiện vào thời gian nào.

Đối với văn bản lớn, có thể sử dụng thêm tham số --word-diff để xem thông tin một cách tổng quát.

Ví dụ,

$ git log -p -2 --word-diff

Để xem thống kê tóm tắt, sử dụng tham số --stat.

Ví dụ,

$ git log --stat

Để xem hiển thị theo nhiều cách khác nhau, sử dụng tham số --pretty.

Ví dụ hiển thị mỗi commit trên một dòng,

$ git log --pretty=oneline

Để định dạng hiển thị từng thông tin, sử dụng tham số --pretty=format.

Ví dụ,

$ git log --pretty=format:"%h - %an, %ar : %s"
0cf8354 - Lê Gia Công, 17 hours ago : doi ten tap tin
a6c7b42 - Lê Gia Công, 17 hours ago : doi ten
fa9d068 - Lê Gia Công, 18 hours ago : xóa log
0918f5b - Lê Gia Công, 18 hours ago : them thu muc log
c0b9a94 - Lê Gia Công, 18 hours ago : them thu muc log
79e4308 - Lê Gia Công, 19 hours ago : da xoa thumuc
f195a19 - Lê Gia Công, 19 hours ago : them thumuc

Bảng sau là một số giá trị của tham số format,

%H: mã băm commit
%h: mã băm commit rút gọn
%T: băm hiển thị dạng cây
%t: băm hiển thị dạng cây rút gọn
%P: các mã băm gốc
%p: các mã băm gốc rút gọn
%an: tên tác giả
%ae: email tác giả
%ad: ngày commit của tác giả
%ar: thời gian đã commit của tác giả (tính đến hiện tại)
%cn: tên người commit
%ce: email người commit
%cd: ngày commit
%cr: thời gian đã commit (tính đến hiện tại)
%s: thông điệp gửi kèm commit


Tác giả (author) là người tạo ra bản vá (patch) đầu tiên, người commit là người cuối cùng áp dụng bản vá đó.

Để hiện thị các nhánh và lịch sử tích hợp, sử dụng thêm tham số --graph kết hợp với oneline hoặc format. Ví dụ,

$ git log --pretty=format:"%h %s" --graph

Bảng sau tổng hợp một số kiểu định dạng xuất hữu ích của git log,

Tùy chọn
Mô tả
-p
Hiển thị bản vá của mỗi commit
--word-diff
Hiển thị bản vá ở định dạng rút gọn
--stat
Hiển thị thống kê của các tập tin được chỉnh sửa trong mỗi commit
--shortstat
Hiển thị ngắn gọn thống kê của các tập tin được chỉnh sửa trong mỗi commit
--name-only
Hiển thị danh sách các tập tin bị thay đổi (sau thông tin commit)
--name-status
Hiển thị danh sách các tập tin bị ảnh hưởng như thêm/sửa/xóa thông tin
--abbrev-commit
Hiển thị mã băm (SHA-1) ở dạng rút gọn
--relative-date
Hiển thị khoảng thời gian từ lúc commit đến thời điểm hiện tại
--graph
Hiển thị thông tin về rẽ nhánh, trộn nhánh và các thông tin khác
--pretty
Hiển thị thông tin theo định dạng tùy chỉnh (oneline, full, fuller, format)
--oneline
Dạng rút gọn của --pretty=oneline --abbrev-commit

Lab 16. Các chế độ xem lịch sử commit.

Sử dụng repo sau,


Thực hiện xem lịch sử commit với các tham số sau, ghi lại kết quả của mỗi trường hợp.

Lệnh
Tham số
Tham số phụ
$ git log


$ git log
-p
-2
$ git log
-p
-2 --word-diff
$ git log
-- stat

$ git log
-- pretty=oneline
-- pretty=short
-- pretty=full
-- pretty=fuller

$ git log
--shortstat

$ git log
--name-only

$ git log
--name-status

$ git log
--abbrev-commit

$ git log
--relative-date


3.3.2     Giới hạn thông tin xuất


Mặc định, lệnh git log sẽ xuất thông tin của các commit theo từng trang, theo thứ tự từ mới nhất đến cũ hơn. Ngoài ra, bạn cũng có thể sử dụng thêm các tham số khác, để giới hạn các commit được hiển thị.

Sử dụng tham số -n, với n là một số tự nhiên, để xác định số commit được hiển thị.

Ví dụ sau sẽ hiển thị 3 commit mới nhất,

$ git log -3

Sử dụng tham số --since hoặc --until để hiển thị các commit trong một khoảng thời gian cụ thể.

Ví dụ sau sẽ hiển thị các commit trong 2 ngày gần nhất (tính từ thời điểm hiện tại),

$ git log --since=2.days

Ví dụ sau sẽ hiển thị các commit cho tới ngày 8 tháng 3 năm 2019,

$ git log --until="2019-3-8"

Bảng dưới đây tổng hợp một vài tham số để tiện sử dụng,

Tham số
Mô tả
- (n)
Hiển thị n commit mới nhất
--since, --after
Chỉ hiển thị các commit được thực hiện sau ngày cụ thể
--until, --before
Chỉ hiển thị các commit được thực hiện trước ngày cụ thể
--author
Hiển thị các commit theo tên tác giả
--commiter
Hiển thị các commit theo tên người commit
--grep
Hiển thị các commit dựa vào nội dung thông điệp khi commit (message)
Ví dụ: git log --grep="ten"
-S
Hiển thị các commit dựa vào nội dung đã bị thay đổi (thêm/xóa) trong các tập tin
Ví dụ: $ git log -Sword

Lab 17. Lọc các commit theo yêu cầu.

Sử dụng repo sau,


Thực hiện lọc các commit theo các yêu cầu sau, ghi lại thông tin kết quả.

Tham số
Lệnh & Kết quả
- (n)

--since, --after

--until, --before

--author

--commiter

--grep

-S



Khi cài đặt Git, sẽ có sẵn một chương trình cho phép bạn quan sát lịch sử commit một cách trực quan bằng giao diện đồ họa. Trong cửa sổ Git Bash, gõ lệnh gitk để trải nghiệm.

</////06
-----------
Cập nhật [08/10/2019]
-----------
Xem thêm: Tổng hợp các bài viết về Làm web
Xem thêm: Làm web (07) - Git: hủy bỏ & remote repo

Git (01): Tổng quan

1         Tổng quan

1.1       Hệ thống quản lý phiên bản


Định nghĩa về quản lý phiên bản

Phiên bản (version) là các bản khác nhau của một hoặc nhiều tập tin, thư mục hay cả dự án (từ đây gọi chung là tập tin để tiện trình bày). Trong quá trình làm việc, nội dung của tập tin luôn thay đổi, vì vậy nhu cầu xem lại hoặc khôi phục lại trạng thái của tập tin tại một thời điểm nào đó trong quá khứ rất cần thiết. Hệ thống quản lý phiên bản (Version Control System – VCS) sẽ giúp làm được điều này. 

Hệ thống quản lý phiên bản bao gồm phần mềm và cách thức làm việc đi kèm với nó.

Một vài chức năng chính của hệ thống quản lý phiên bản:

– Khôi phục lại trạng thái của một tập tin ở các thời điểm khác nhau trong quá khứ

– Biết được ai đã thực hiện các thay đổi trên tập tin, và đã thay đổi những gì

– Dễ dàng khôi phục lại các nội dung hoặc tập tin bị xóa  

– Dễ dàng so sánh những thay đổi của tập tin theo các mốc thời gian

Dựa trên cách tổ chức và hoạt động, các hệ thống quản lý phiên bản được chia thành ba loại, gồm: hệ thống cục bộ, hệ thống tập trung và hệ thống phân tán.

Hệ thống quản lý phiên bản cục bộ

Đây là cách làm thủ công, đơn giản, không nhất thiết phải dùng tới phần mềm. Nó đơn giản chỉ là việc người dùng tự lưu trữ các tập tin ở các thời điểm khác nhau trong quá trình làm việc thành các tên khác nhau. Để tiện theo dõi, người dùng có thể đặt tên tập tin bao gồm thời gian, cộng với một vài từ khóa nhận diện. Ví dụ: logo_2020_02_20_xanh.gif, logo_2020_02_21_do.gif.

Với hệ thống này, người dùng rất khó để quản lý khi số lượng tập tin nhiều, liên tục thay đổi theo thời gian. Để hỗ trợ, các lập trình viên đã tạo ra các công cụ giúp quản lý các thay đổi, dùng cơ sở dữ liệu cục bộ để lưu trữ và quản lý các thay đổi.

Công cụ phổ biến được dùng để quản lý phiên bản cục bộ là RCS. Tìm hiểu thêm về RCS tại đây: https://www.gnu.org/software/rcs/

Hệ thống quản lý phiên bản cục bộ có thể lưu mỗi phiên bản trong một thư mục, sử dụng cơ sở dữ liệu để quản lý thông tin các thư mục. Tuy nhiên, hệ thống này không hỗ trợ làm việc trên môi trường cộng tác nhiều người. Xem hình minh họa [2],




Hệ thống quản lý phiên bản tập trung

Với hệ thống quản lý phiên bản cục bộ, các thành viên trong nhóm rất khó chia sẻ và cộng tác trong quá trình làm việc. Hệ thống quản lý phiên bản tập trung sẽ giải quyết được vấn đề này.


Hệ thống quản lý phiên bản tập trung (Centralized Version Control Systems – CVCS) gồm máy chủ chứa các phiên bản của tập tin và danh sách các máy khách được phép thay đổi các tập tin trên máy chủ. Các máy khách sẽ lấy các phiên bản của tập tin từ máy chủ về, thực hiện các thay đổi trên tập tin và cập nhật lại các thay đổi về máy chủ.
Xem hình minh họa,



Một số hệ thống quản lý phiên bản tập trung: CVS, Subversion (SVN), Perforce.

Hạn chế của hệ thống quản lý phiên bản tập trung là nếu máy chủ bị trục trặc sẽ dẫn tới gián đoạn việc cập nhật phiên bản của các thành viên, hoặc bị mất toàn bộ các phiên bản của tập tin trên server.

Hệ thống quản lý phiên bản phân tán

Hệ thống quản lý phiên bản phân tán giúp khắc phục hạn chế của hệ thống quản lý phiên bản tập trung.

Với hệ thống quản lý phiên bản phân tán, các máy client không chỉ chép phiên bản mới nhất của các tập tin từ server về, mà nó còn chép toàn bộ cả kho chứa (repository, repo), trong đó bao gồm cả lịch sử các phiên bản. Do vậy, nếu máy chủ gặp trục trặc thì vẫn có thể lấy bất kì kho chứa tại các máy client để khôi phục lại toàn bộ kho chứa cho máy server. Ví dụ các hệ thống quản lý phiên bản phân tán: Git, Mercurial, Bazaar, Darcs.


Xem hình minh họa,


Ngoài ra, hệ thống này cũng cho phép một máy client có thể liên kết với nhiều kho chứa ở xa cùng lúc, do vậy bạn có thể cùng lúc cộng tác với nhiều nhóm làm việc khác nhau.  

1.2       Lịch sử sơ lược về Git


Từ năm 2002, Linux sử dụng một hệ thống quản lý phiên bản phân tán (Distributed Version Control System - DVCS) có tên là BitKeeper

Năm 2005 hợp đồng với BitKeeper chấm dứt, cộng đồng Linux không tiếp tục sử dụng BitKeeper nữa mà tự xây dựng một DVCS mới, dựa trên các đặc điểm học được từ hệ thống BitKeeper.
DVCS mới cần đáp ứng được các yêu cầu sau:

– Xử lý nhanh

– Thiết kế đơn giản

– Hỗ trợ tốt cho "phát triển phi tuyến tính" (non-linear development), cho phép quản lý hàng ngàn nhánh song song

– Phân tán toàn diện

– Có khả năng xử lý các dự án phức tạp, với tốc độ cao và khối lượng dữ liệu lớn (giống như nhân Linux)


Trong năm 2005 Git đã ra đời, đáp ứng được các yêu cầu đặt ra và nhanh chóng được sử dụng rộng rãi.

1.3        Nguyên tắc làm việc của Git


Để sử dụng Git hiệu quả, cần biết và hiểu một số nguyên tắc làm việc của nó.

“Chụp ảnh”

Một cách rất tự nhiên, khi bạn cần lưu trữ các phiên bản khác nhau của mỗi tập tin bạn sẽ làm như thế nào? Như trong phần “quản lý phiên bản cục bộ” đã đề cập: khi một tập tin có thay đổi và cần lưu thành một phiên bản khác, bạn sẽ lưu nó thành một tập tin mới với tên mới. Nghĩa là tập tin mới có thay đổi delta nào đó so với tập tin ban đầu. Để tối ưu việc lưu trữ, thực tế chỉ cần lưu tập tin gốc, cộng thêm thông tin của mỗi lần thay đổi (delta). Khi đó, thông tin một phiên bản của dự án sẽ gồm các tập tin gốc, cùng với các thay đổi của từng tập tin. Đây chính là cách tiếp cận của đa số các hệ thống quản lý phiên bản, như: CVS, Subversion (SVN), Perforce, Bazaar.


Xem hình minh họa,




Với Git thì khác, để lưu lại một phiên bản của dự án, Git sẽ chụp ảnh (snapshot) toàn bộ các tập tin của dự án. Tập tin nào có thay đổi thì “chụp” (tạo ra một ảnh mới cho tập tin), tập tin nào không thay đổi thì không “chụp”, mà chỉ tạo một liên kết, trỏ về phiên bản trước của nó.

Xem hình minh họa,



Có thể thấy, dữ liệu của Git gồm một loạt các “ảnh chụp” của hệ thống tập tin đơn giản (miniature filesystem). Mỗi “ảnh chụp” là một phiên bản của dự án, tương đương với một “commit” trong hệ thống Git.

Phần lớn các thao tác với Git được thực hiện trên máy cục bộ

Khi làm việc với Git, hầu hết các thông tin và tài nguyên đều có sẵn trên máy cục bộ, do vậy bạn không phải kết nối tới server ở xa.

Ví dụ, nếu bạn muốn xem lại thông tin hoặc nội dung các phiên bản trước của dự án, thì bạn chỉ việc xem trong cơ sở dữ liệu của Git tại máy cục bộ. Hoặc nếu bạn muốn lưu lại phiên bản hiện thời của dự án (commit), bạn cũng thực hiện trên máy cục bộ. Chỉ khi nào bạn muốn chia sẻ phiên bản mới cho thành viên khác thì mới cần tới mạng để tải phiên bản mới lên server (push).

Git đảm bảo tính toàn vẹn

Mọi thứ trong Git (ví dụ tập tin) đều được tạo mã kiểm tra (checksum) trước khi lưu vào cơ sở dữ liệu Git. Git tạo ra mã kiểm tra bằng cách chạy một thuật toán (SHA-1) dựa vào nội dung của tập tin.
Kết quả của thuật toán SHA-1 sẽ tạo ra một số hexa, tạm gọi là mã SHA-1, có chiều dài 40 kí số. Ví dụ, một mã SHA-1: 24b9da6552252987aa493b52f8696cd6d3b00373

Git dùng mã SHA-1 của tập tin để đặt tên mới cho nó và thao tác với tên mới này chứ không không quan tâm đến tên thật của tập tin.

Giả sử bằng cách nào đó, nội dung của một tập tin bị thay đổi, khi Git mở tập tin, nó sẽ tính lại mã SHA-1, so với mã SHA-1 đã được lưu trước đây, nếu hai mã này không khớp, Git sẽ phát hiện ra là nội dung của tập tin đã bị thay đổi.

Như vậy không thể có tình trạng nội dung của tập tin bị thay đổi mà Git không biết, cơ chế này đảm bảo dữ liệu do Git quản lý luôn có tính toàn vẹn.

Git chỉ “thêm” dữ liệu

Trong quá trình làm việc với Git, hầu như mọi thao tác đều được Git ghi vào cơ sở dữ liệu. Bạn có thể bị mất hoặc bị xáo trộn thông tin nếu chưa lưu phiên bản (commit), nếu bạn đã lưu phiên bản thì rất khó bị mất dữ liệu, đặc biệt nếu bạn thường xuyên đẩy cơ sở dữ liệu Git lên server (push) hoặc tới kho chứa khác.

Cách làm việc theo kiểu luôn “thêm” dữ liệu (không xóa) tạo ra cảm giác yên tâm cho người sử dụng.

Ba trạng thái quan trọng của tập tin

Khi một tập tin (thư mục) đã được Git quản lý, nó có thể ở các trạng thái sau: modified, staged, committed.

– modified: tập tin đã bị thay đổi (nội dung hoặc tên), nhưng chưa lưu phiên bản (commit) vào cơ sở dữ liệu Git trên máy cục bộ (hay .git directory, repository, repo)

– staged: tập tin đã bị thay đổi, đã được đánh dấu là sẽ lưu phiên bản vào cơ sở dữ liệu Git trên máy cục bộ

– committed: là tập tin đã bị thay đổi, đã được đánh dấu và đã được lưu phiên bản trong cơ sở dữ liệu Git trên máy cục bộ

Ba trạng thái trên tạo ra ba vùng làm việc của một dự án đã được Git quản lý (thư mục đã được nhúng Git vào bên trong): gồm working tree (hay working directory), staging area và .git directory.

– working directory: thư mục làm việc hiện thời, là bản sao một phiên bản của dự án, nó được lấy ra từ cơ sở dữ liệu Git (.git directory). Đây là thư mục làm việc của lập trình viên, thao tác trên nó như một thư mục bình thường.

– staging area: khu vực tổ chức, là một tập tin (index) nằm trong thư mục .git, chứa thông tin về những gì sẽ được lưu phiên bản (commit) trong lần tới.

– .git directory: thư mục .git, là nơi Git lưu trữ “siêu dữ kiện” (metadata), và cơ sở dữ liệu của Git (không phải cơ sở dữ liệu của ứng dụng đang được phát triển). Đây là phần quan trọng nhất của Git, nó là thành phần được sao lưu (copy) về khi bạn nhân bản một kho chứa từ máy khác (clone).


Xem hình minh họa,



Về cơ bản, tiến trình công việc (workflow) khi thao tác với Git gồm:

– Bạn thao tác (tạo mới, thêm dữ liệu, sửa, xóa) với tập tin/thư mục trong working directory

– Đưa vào staging area các tập tin/thư mục mà bạn muốn lưu trữ vào .git directory (những thứ sẽ được lưu phiên bản, sẽ được commit)

– Tạo phiên bản cho các nội dung đã có trong staging area, cụ thể là thực hiện lệnh commit. Các tập tin/thư mục đã được đánh dấu trong staging area sẽ được lưu trữ an toàn vào .git directory

Một tập tin nằm trong .git directory được xem là đã được committed. Nếu tập tin đã bị thay đổi và đã được đưa vào staging area được xem là staged. Và nếu một tập tin đã bị thay đổi tính từ thời điểm được sinh ra từ .git directory (check out) và chưa đưa vào staging area thì được xem là modified.


Đọc thêm “The biggest misconception about Git”: https://medium.com/@gohberg/the-biggest-misconception-about-git-b2f87d97ed52

1.4       Dùng Git ở chế độ dòng lệnh


Tại sao nên học/dùng Git ở chế độ dòng lệnh (command line)?

Để sử dụng Git có rất nhiều cách, có thể chỉ cần dùng chương trình dòng lệnh hoặc có thể dùng các chương trình có giao diện đồ họa (GUI).

Tuy nhiên, chỉ có chương trình dòng lệnh mới có thể chạy tất cả các lệnh của Git, ngược lại các chương trình đồ họa chỉ bao gồm các lệnh phổ biến của Git.

Một người biết sử dụng Git ở chế độ dòng lệnh rất dễ dàng sử dụng Git ở chế độ đồ họa, điều ngược lại không phải khi nào cũng đúng.

Giao diện GUI thì có nhiều loại, tùy sở thích, mỗi người dùng sẽ cài những phần mềm GUI khác nhau, muốn sử dụng được phải có thời gian làm quen. Tuy nhiên, giao diện dòng lệnh chỉ có một kiểu và máy nào cũng có, rất dễ sử dụng.

Một số chương trình dòng lệnh: Terminal của macOS, Command Prompt hoặc PowerShell của Windows, hoặc Git bash của Git.

Một số chương trình GUI: Github Desktop, SourceTree, GitKraken, SmartGit, Git Cola, GitForce, Giggle, Magit, Egit, Gitg[1].

-----
[2] https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
-----------
Cập nhật [25/02/2020]
-----------
Xem thêm: Git (02): Cài đặt và cấu hình Git
-----
Bạn muốn tự học HTML bài bản? Xem thêm