Huong dan su dung svn server (SVN subversion - SVN Hosting)Văn Nguyễn Trung
SVN SUBVERSION GIẢI QUYẾT ĐƯỢC VẤN ĐỀ GÌ?
Subversion là gì ?
Subversion (viết tắt SVN) là một hệ thống quản lý version (version control system - VCS) được giới thiệu vào năm 2000 bởi công ty CollabNet (http://subversion.tigris.org). Đây là hệ thống hỗ trợ làm việc theo nhóm rất hiệu quả.
Phần mềm:
Cho client: TortoiseSVN, Download:http://tortoisesvn.net/
Cho server: VisualSVN – Server Download: http://tortoisesvn.net/downloads.html
Các site cung cấp dịch vụ:
http://hostingviet.vn
http://code.google.com
http://sourceforge.net
SVN Subversion giải quyết được vấn đề gì?
Khi một nhóm làm việc trên cùng một project, việc nhiều người cùng chỉnh sửa nội dung của một file là điều không thể tránh khỏi. SVN Subversion cung cấp các chức năng để có thể thực hiện việc này một cách đơn giản và an toàn.
SVN Subversion được thiết kế với mục đích thay thế hệ thống quản lý phiên bản Concurrent Versioning System (CVS) đã cũ và có nhiều nhược điểm. Subversion có thể được sử dụng để quản lý bất cứ hệ thống phiên bản nào.
SVN Subversion là hệ thống quản lý source code tập trung (Centralized).
SVN Subversion là hệ thống quản lý phiên bản mạnh mẽ, hữu dụng, và linh hoạt.
SVN Subversion quản lý tập tin và thư mục theo thời gian.
SVN Subversion giống như một hệ thống file server mà các client có thể download và upload file một cách bình thường.
Điểm đặt biệt của SVN Subversion là nó lưu lại tất cả những gì thay đổi trên hệ thống file: file nào đã bị thay đổi lúc nào, thay đổi như thế nào, và ai đã thay đổi nó.
SVN Subversion cũng cho phép recover lại những version cũ một cách chính xác. Các chức năng này giúp cho việc làm việc nhóm trở nên hiệu quả và an toàn hơn rất nhiều.
Thông thường, client và server kết nối thông qua mạng LAN hoặc Internet. Client và server có thể cùng chạy trên một máy nếu SVN Subversion có nhiệm vụ theo vết lịch sử của dự án do các nhà phát triển phần mềm phát triển trong nội bộ.
SVN Subversion hỗ trợ khá nhiều giao thức để kết nối giữa client và server.
Ví dụ bạn có thể dùng các giao thức của ứng dụng web như http:// hoặc https://, hay các giao thức của svn như svn:// hoặc svn+ssh://, hoặc nếu phần mềm client và server cài chung trên 1 máy thì có thể dùng file://.
Việc cho phép server hỗ trợ giao thức nào phụ thuộc vào lúc cấu hình.
Cài đặt SVN Subversion (Client): tool dùng trên Client
Cài đặt VisualSVN(Server): tool dùng cho Server
Chi tiết cài đ
Git có rất nhiều cách sử dụng nên việc ghi nhớ các lệnh khác nhau của nó có thể khá là khó khăn, đó là lý do tại sao mình đã tạo ra "Bảng Cửu Chương Git" này.
https://niithanoi.edu.vn/git-la-gi.html
Huong dan su dung svn server (SVN subversion - SVN Hosting)Văn Nguyễn Trung
SVN SUBVERSION GIẢI QUYẾT ĐƯỢC VẤN ĐỀ GÌ?
Subversion là gì ?
Subversion (viết tắt SVN) là một hệ thống quản lý version (version control system - VCS) được giới thiệu vào năm 2000 bởi công ty CollabNet (http://subversion.tigris.org). Đây là hệ thống hỗ trợ làm việc theo nhóm rất hiệu quả.
Phần mềm:
Cho client: TortoiseSVN, Download:http://tortoisesvn.net/
Cho server: VisualSVN – Server Download: http://tortoisesvn.net/downloads.html
Các site cung cấp dịch vụ:
http://hostingviet.vn
http://code.google.com
http://sourceforge.net
SVN Subversion giải quyết được vấn đề gì?
Khi một nhóm làm việc trên cùng một project, việc nhiều người cùng chỉnh sửa nội dung của một file là điều không thể tránh khỏi. SVN Subversion cung cấp các chức năng để có thể thực hiện việc này một cách đơn giản và an toàn.
SVN Subversion được thiết kế với mục đích thay thế hệ thống quản lý phiên bản Concurrent Versioning System (CVS) đã cũ và có nhiều nhược điểm. Subversion có thể được sử dụng để quản lý bất cứ hệ thống phiên bản nào.
SVN Subversion là hệ thống quản lý source code tập trung (Centralized).
SVN Subversion là hệ thống quản lý phiên bản mạnh mẽ, hữu dụng, và linh hoạt.
SVN Subversion quản lý tập tin và thư mục theo thời gian.
SVN Subversion giống như một hệ thống file server mà các client có thể download và upload file một cách bình thường.
Điểm đặt biệt của SVN Subversion là nó lưu lại tất cả những gì thay đổi trên hệ thống file: file nào đã bị thay đổi lúc nào, thay đổi như thế nào, và ai đã thay đổi nó.
SVN Subversion cũng cho phép recover lại những version cũ một cách chính xác. Các chức năng này giúp cho việc làm việc nhóm trở nên hiệu quả và an toàn hơn rất nhiều.
Thông thường, client và server kết nối thông qua mạng LAN hoặc Internet. Client và server có thể cùng chạy trên một máy nếu SVN Subversion có nhiệm vụ theo vết lịch sử của dự án do các nhà phát triển phần mềm phát triển trong nội bộ.
SVN Subversion hỗ trợ khá nhiều giao thức để kết nối giữa client và server.
Ví dụ bạn có thể dùng các giao thức của ứng dụng web như http:// hoặc https://, hay các giao thức của svn như svn:// hoặc svn+ssh://, hoặc nếu phần mềm client và server cài chung trên 1 máy thì có thể dùng file://.
Việc cho phép server hỗ trợ giao thức nào phụ thuộc vào lúc cấu hình.
Cài đặt SVN Subversion (Client): tool dùng trên Client
Cài đặt VisualSVN(Server): tool dùng cho Server
Chi tiết cài đ
Git có rất nhiều cách sử dụng nên việc ghi nhớ các lệnh khác nhau của nó có thể khá là khó khăn, đó là lý do tại sao mình đã tạo ra "Bảng Cửu Chương Git" này.
https://niithanoi.edu.vn/git-la-gi.html
Khóa học Quản lý mã nguồn với GIT là khóa học được xây dựng bởi chính những kinh nghiệm làm việc và quản lý mã nguồn của ZendVN với các project thực tế.
Khóa học: https://zendvn.com/quan-ly-ma-nguon-voi-git/
Vietnamese version translated from this famous slide
http://www.slideshare.net/nbykmatsui/ss-55961899?utm_content=buffer50ae1&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
Ứng dụng phần mềm Quản lý tài liệu GXD ứng dụng vào công việc quản lý tài liệu dự án xây dựng, thực hiện quản lý dự án xây dựng. Version 1.0 tháng 05/2020.
Chỉ trên 1 file Excel, quản lý hàng nghìn đến hàng trăm nghìn file tài liệu của dự án nhẹ nhàng và đơn giản.
Phần mềm Quản lý tài liệu GXD - công cụ số 1 của Document Controller tại Việt Nam. Hãy ứng dụng ngay, bạn sẽ tiết kiệm được rất nhiều thời gian trong cuộc đời để làm nhiều việc lớn khác.
Bạn sẽ kế thừa hệ thống tư liệu khổng lồ trong kho tri thức của phần mềm Quản lý tài liệu GXD
Link thông tin về phần mềm Quản lý tài liệu GXD: https://giaxaydung.vn/forums/phan-mem-quan-ly-tai-lieu-xay-dung-gxd-qltl.401/
Khóa học Quản lý mã nguồn với GIT là khóa học được xây dựng bởi chính những kinh nghiệm làm việc và quản lý mã nguồn của ZendVN với các project thực tế.
Khóa học: https://zendvn.com/quan-ly-ma-nguon-voi-git/
Vietnamese version translated from this famous slide
http://www.slideshare.net/nbykmatsui/ss-55961899?utm_content=buffer50ae1&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
Ứng dụng phần mềm Quản lý tài liệu GXD ứng dụng vào công việc quản lý tài liệu dự án xây dựng, thực hiện quản lý dự án xây dựng. Version 1.0 tháng 05/2020.
Chỉ trên 1 file Excel, quản lý hàng nghìn đến hàng trăm nghìn file tài liệu của dự án nhẹ nhàng và đơn giản.
Phần mềm Quản lý tài liệu GXD - công cụ số 1 của Document Controller tại Việt Nam. Hãy ứng dụng ngay, bạn sẽ tiết kiệm được rất nhiều thời gian trong cuộc đời để làm nhiều việc lớn khác.
Bạn sẽ kế thừa hệ thống tư liệu khổng lồ trong kho tri thức của phần mềm Quản lý tài liệu GXD
Link thông tin về phần mềm Quản lý tài liệu GXD: https://giaxaydung.vn/forums/phan-mem-quan-ly-tai-lieu-xay-dung-gxd-qltl.401/
2. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning
3. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning
4. Khái niệm
- Là hệ thống quản lý phân tán phiên bản source code (distributed version-control
system) phát triển bởi Linus Torvalds vào năm 2005.
- Được thiết kế như một công cụ để các Lập trình viên có thể cộng tác cùng nhau
trên một source code.
- Hầu hết các công ty công nghệ đều đang sử dụng git.
5. Version Control System (VCS)
- Thay đổi là liên tục
- Đôi khi thay đổi hiện tại là không thoả
mãn, cần bỏ đi
- Đôi khi phiên bản trong quá khứ quan
trọng hơn
- Đôi khi có nhiều người cùng làm việc
trên 2 phiên bản khác nhau
→ Cần có một hệ thống quản lý phiên bản
để thống nhất về
8. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning
9. Cách chia vùng
- Git chia ra 2 môi trường: Môi trường
Phát triển (là môi trường phát triển
của lập trình viên), và môi trường
Server (GitHub, GitLab, …)
- Môi trường phát triển được chia thành
3 vùng: Working Directory, Staging
Area, Local Repository.
10. Clone
- Fork repo: https://gitlab.com/tienhm/git-
training
- Clone repo vừa fork về, trong đó sẽ có 2
file ví dụ pet.php và docs.md
11. Changes
- Đơn vị nhỏ nhất Git quản lý là đối tượng
Changes.
- Changes có 3 loại:
- added: Khi thêm 1 file mới
- deleted: Khi xoá 1 file
- modified: Khi thay đổi nội dung file
(changes dạng này có thể tính đến
đơn vị dòng)
- Working Area là nơi xuất phát của
Changes
- Các file trong Working Area sẽ được
đánh dấu là Tracked hoặc Untracked
(Untracked là file mới - trong repository
chưa có, git chưa biết về file này)
12. Add Changes
- Commit được cấu thành bởi một hoặc
nhiều Changes
- Commit cần đủ nhỏ để có thể mô tả
- Chỉ chọn các Changes phù hợp với
Commit
- Lưu ý: với Changes dạng modified, có
thể lựa chọn tới từng dòng, nên hãy cố
gắng tỉ mỉ khi lựa chọn.
13. Commit
- Không được viết Commit message quá
chung chung (Kiểu như “Update code")
- Nếu nhiều Commit cùng làm 1 việc và
phát sinh sau trong quá trình phát triển
thì cần dọn dẹp (Clean History)
- Nếu bạn có quá nhiều Commit cho 1 tính
năng thì: hoặc là task đó quá lớn, hoặc
là commit chưa đúng
- Có thể coi mỗi Commit là 1 bước để
hoàn thành task.
- Nếu dự án của bạn chia thành các
components, Commit nên chia thêm
theo chiều scope của components.
14. Push
- Push là bước để Remote Repository cập
nhật thay đổi từ Clients
→ Việc này có thể sinh ra Conflicts khi 2
người cùng sửa 1 dòng ở cùng 1 file (race
condition)
15. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning
17. Luồng làm việc cơ bản
1. Bạn cần làm tính năng mới → Tạo branch tương ứng
2. Sau khi làm xong cần tự hoàn thiện code của mình (tự test nhiều case nhất có thể, xoá các đoạn
code debug, clean git history..)
3. Tạo yêu cầu merge
4. Sửa các góp ý phát sinh trong quá trình review
5. Merge code sau khi review
18. Branch (1)
- Cần chia ra 2 loại branch: private
branch và public branch
- Public Branch:
- Dùng chung bởi nhiều người
- Tương ứng với môi trường (ví dụ:
master tương ứng với production,
dev tương ứng với dev,...)
- Có bao nhiêu môi trường thì tạo
ngần ấy Public Branch
- History trên public branch là fact,
không ai được phá huỷ. Các hành
động merge trên Public Branch do
đó cần làm cẩn thận và theo quy
trình.
19. Branch (2)
- Cần chia ra 2 loại branch: private
branch và public branch
- Private Branch:
- Là branch để làm 1 tính năng - nên
chỉ do 1 người làm.
- Cần tuân thủ commit message
- Trước khi merge, có thể rebase để
dọn dẹp history (nếu cần)
20. Rebase (1)
- Rebase trước khi merge để tránh
conflict
- Rebase xong thì phải `git push -f` để
forced rewrite.
21. Rebase (2)
- Rebase sinh ra để Rewriting History. Mục đích là để có một History sạch sẽ. Giữ lại tri thức của dự
án về sau.
- Rebase rule:
- Public Branch: Không được rebase trên đây - do là branch dùng chung. Làm như vậy sẽ ảnh
hưởng tới nhiều người. Nếu bạn làm sai ở Private Branch mà vẫn merge vào Public Branch thì
quá trình Review code không hiệu quả.
- Private Branch: Luôn chủ động rebase trước khi merge. Nếu cần thiết, hãy thêm việc rebase
vào review checklist để chắc chắn nó được thực hiện trước khi merge. Hãy đảm bảo bạn
không đóng góp một đoạn code vào dự án mà không ai hiểu bạn muốn làm gì.
- Rebase quá nhiều không làm mọi việc tốt hơn vì nó làm cho tất cả những test trước đó của bạn là
vô nghĩa → Cần làm lại test
→ Tham khảo: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
24. Merge Request Template
- Template cần các phần sau đây:
- Mô tả về feature: Để người review
không mất thời gian tìm hiểu lại vấn
đề
- Test plan: Để người review có thể
test nhanh nhất
- Review checklist: Để người review
không quên các mục quan trọng cần
làm
→ Lưu ý: Người tạo Merge Request (MR)
nên tự review cho mình trước khi assign cho
người khác. Vừa tăng tính hoàn thiện của
MR, vừa dễ dàng nhìn thấy khuyết điểm của
mình để sửa.
25. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning
26. Release
- Thống nhất điểm “sẵn sàng để release" trong cả team
- Ví dụ: merge vào master, build xong, ...
- Dịch vụ cần được đánh version khi release
- Nên tuân theo chuẩn Semantic Versioning
- Hãy viết change logs một cách tận tâm
- Cần nhất là các thay đổi sẽ release trong phiên bản này
- Nếu được, cần có thêm các bằng chứng như build status, test result...
29. Tóm lại
- Tạo commit hợp lý
- Dọn dẹp git history trước khi yêu cầu merge (rebase)
- Review cần thận trước khi merge
- Đánh version khi đóng gói sản phẩm để release
- Viết changelogs cho các bản release