Tweet
Hình mô tả một Git Workflow khá phổ biến khi nhiều kỹ sư cùng phát triển code, automation script hoặc Infrastructure as Code. Ý tưởng chính là: không chỉnh sửa trực tiếp trên nhánh chính, mà làm việc trên branch riêng, kiểm tra rồi mới merge.
Giả sử repository đã được git clone về máy.
1. Đồng bộ Branch từ Remote Repository
Trước khi bắt đầu, engineer lấy phiên bản mới nhất:
git pull origin <branch>
Mục đích là tránh phát triển trên source code đã cũ.
2. Thực hiện thay đổi trên Local Repository
Engineer chỉnh sửa code, chẳng hạn:
Ví dụ sửa:
router_config.txt
3. Đưa thay đổi vào Staging Area
Sau khi chỉnh sửa:
git add router_config.txt
git add chưa tạo commit. Nó chỉ đưa thay đổi vào Staging Area, tức chuẩn bị những nội dung sẽ được commit.
Có thể hình dung:
Tiếp theo:
git commit -m "Update OSPF configuration"
Commit tạo một snapshot/version mới trong Local Repository:
Một commit message tốt nên mô tả rõ thay đổi thay vì dùng những nội dung chung chung như "update" hoặc "fix".
5. Đồng bộ lại trước khi Push
Trước khi đẩy code lên remote, engineer có thể cập nhật branch:
git pull origin <branch>
Nếu đồng đội đã sửa cùng khu vực code, có thể xảy ra Merge Conflict.
Khi đó cần:
Đây là bước quan trọng khi nhiều người cùng làm việc trên một repository.
6. Push lên Remote Branch
Khi code đã sẵn sàng:
git push origin <branch>
Lúc này thay đổi từ Local Repository được đưa lên Remote Repository, nhưng vẫn nằm trên branch làm việc chứ chưa nhất thiết thuộc nhánh chính.
7. Pull Request và Merge
Engineer tạo Pull Request (PR) để đề nghị đưa thay đổi:
Team có thể thực hiện code review, security review, automated testing và CI/CD checks trước khi merge.
Slide sử dụng tên master; nhiều repository hiện nay sử dụng main làm tên nhánh mặc định.
8. Đưa phiên bản đã duyệt vào Production
Hình minh họa production server thực hiện:
git pull origin master
để lấy phiên bản mới.
Tuy nhiên, trong môi trường DevOps hiện đại, production thường không nên phụ thuộc vào thao tác git pull thủ công. Quy trình tốt hơn là:
Đối với Network Engineer, Git không chỉ dùng để quản lý source code. Nó còn rất hữu ích để quản lý Ansible Playbook, Terraform, YAML, Python script và network configuration.
Giả sử repository đã được git clone về máy.
1. Đồng bộ Branch từ Remote Repository
Trước khi bắt đầu, engineer lấy phiên bản mới nhất:
git pull origin <branch>
Mục đích là tránh phát triển trên source code đã cũ.
2. Thực hiện thay đổi trên Local Repository
Engineer chỉnh sửa code, chẳng hạn:
- Python automation script
- Ansible Playbook
- Terraform configuration
- Network configuration template
Ví dụ sửa:
router_config.txt
3. Đưa thay đổi vào Staging Area
Sau khi chỉnh sửa:
git add router_config.txt
git add chưa tạo commit. Nó chỉ đưa thay đổi vào Staging Area, tức chuẩn bị những nội dung sẽ được commit.
Có thể hình dung:
Working Directory → git add → Staging Area
4. Commit thay đổiTiếp theo:
git commit -m "Update OSPF configuration"
Commit tạo một snapshot/version mới trong Local Repository:
Staging Area → git commit → Local Repository
Một commit message tốt nên mô tả rõ thay đổi thay vì dùng những nội dung chung chung như "update" hoặc "fix".
5. Đồng bộ lại trước khi Push
Trước khi đẩy code lên remote, engineer có thể cập nhật branch:
git pull origin <branch>
Nếu đồng đội đã sửa cùng khu vực code, có thể xảy ra Merge Conflict.
Khi đó cần:
phát hiện conflict → kiểm tra code → chọn/chỉnh nội dung đúng → test lại → commit.
Đây là bước quan trọng khi nhiều người cùng làm việc trên một repository.
6. Push lên Remote Branch
Khi code đã sẵn sàng:
git push origin <branch>
Lúc này thay đổi từ Local Repository được đưa lên Remote Repository, nhưng vẫn nằm trên branch làm việc chứ chưa nhất thiết thuộc nhánh chính.
7. Pull Request và Merge
Engineer tạo Pull Request (PR) để đề nghị đưa thay đổi:
Feature/Working Branch → Main Branch
Team có thể thực hiện code review, security review, automated testing và CI/CD checks trước khi merge.
Slide sử dụng tên master; nhiều repository hiện nay sử dụng main làm tên nhánh mặc định.
8. Đưa phiên bản đã duyệt vào Production
Hình minh họa production server thực hiện:
git pull origin master
để lấy phiên bản mới.
Tuy nhiên, trong môi trường DevOps hiện đại, production thường không nên phụ thuộc vào thao tác git pull thủ công. Quy trình tốt hơn là:
Developer → Branch → Commit → Push → Pull Request → Review/Test → Merge → CI/CD → Production
Đối với Network Engineer, Git không chỉ dùng để quản lý source code. Nó còn rất hữu ích để quản lý Ansible Playbook, Terraform, YAML, Python script và network configuration.
Attached Files