Đây là một bộ quy tắc để ghi nhớ:
-
Thực hiện công việc trong một nhánh đặc trưng.
Tại sao:
Bởi vì theo cách này tất cả công việc được thực hiện trên một nhánh đặc trưng thay vì nhánh chính. NÓ cho phép bạn gửi nhiều pull request mà không bị nhầm lẫn. Bạn có thể lặp lại với những code chưa hoàn thành có nguy cơ không ổn định mà không làm rối nhánh chính. đọc thêm...
-
Phát triển nhánh từ
developTại sao:
Bằng cách này, bạn có thể chắc chắn rằng code trong nhánh master sẽ hầu như được build mà không có lỗi, và có thể được sử dụng trực tiếp cho bản phát hành (Điều này có thể quá sức đối với một vài dự án).
-
Không bao giờ push vào nhánh
develophoặcmaster. Hãy tạo một Pull request.Tại sao:
Nó thông báo cho thành viên của nhóm rằng chúng ta vừa hoàn thành một tính năng. Nó cho phép dẽ dàng bình duyệt lại mã và đưa ra diễn đàn thảo luận về tính năng được đề xuất.
-
Cập nhật nhánh
developtrên local và thực hiện rebase trước khi push tính năng của bạn và tạo một Pull Request.Tại sao:
Rebase sẽ gộp vào nhánh được yêu cầu (
masterhoặcdevelop) và áp dụng các commit cái mà bạn đã tạo tại local lên đầu của lịch sử mà không tạo ra một merge commit (giả sử không có xung đột). Kết quả là một lịch sử tốt và rõ ràng. đọc thêm ... -
Xử lí xung đột tiềm năng trong khi rebase và trước khi tạo một Pull request.
-
Xoá tính năng trên local và remote sau khi nhánh được merge.
Tại sao:
Nó sẽ làm lẫn lộn danh sách nhánh của bạn với các nhánh chết. Nó đảm bảo bạn không bao giờ merge nhánh (
masterordevelop) trở lại. Các nhánh đặc trưng chỉ nên tồn tại trong khi công việc vẫn đang trong tiến trình. -
Trước khi tạo một Pull Request, đẩm bảo rằng nhánh đặc trưng của bạn build thành công và qua tất cả các bài kiểm tra (bao gồm cả cách trình bày code).
Tại sao:
Bạn chuẩn bị thêm code vào một nhánh ổn định.Nếu nhánh tính năng của bạn fail,Thì tỉ lệ cao nhánh đích của bạn cũng fail. Additionally, you need to apply code style check before making a Pull Request. It aids readability and reduces the chance of formatting fixes being mingled in with actual changes. Ngoài ra, bạn cần áp dụng kiểm tra kiểu mã trước khi thực hiện một Pull Rrequest. Nó giúp dễ đọc và giảm tỉ lệ định dạng các bản sửa lỗi được trộn lẫn với những thay đổi thực tế.
-
Sử dụng cái này
.gitignorefile.Why:
Nó là một danh sách các file hệ thống không nên được gửi với code của bạn vào remote repo. Ngoài ra nó loại trừ các thư mục cài đặt và các file hầu như chỉ dùng cho các editor,cũng như các thư mục phổ biến nhất.
-
Bảo vệ nhánh
developvàmastercủa bạn.Tại sao:
Nó bảo vệ các nhánh sẵn sàng từ các thay đổi không mong muốn và không thể đảo ngược. đọc thêm ... Github, Bitbucket và GitLab
Vì hầu hết các lí do trên, chúng ta sử dụng Quy trình làm việc với các nhánh tính năng với Tương tác Rebasing và một vài phần tử của Gitflow (đặt tên và có một nhánh phát triển). Các bước chính như sau:
-
Đối với dự án mới, khởi tạo một repo git trong thư mục của dự án. Đối với các tính năng / thay đổi tiếp theo, bước này nên được bỏ qua.
cd <project directory> git init
-
Kiểm tra một nhánh tính năng/sửa lỗi mới.
git checkout -b <branchname>
-
Thay đổi.
git add git commit -a
Why:
git commit -asẽ bắt đầu một trình soạn thảo cho phép bạn tách đối tượng ra khỏi body. Đọc thêm về nó trong section 1.3. -
Đồng bộ với remote để lấy những thay đổi bạn đã bỏ lỡ.
git checkout develop git pull
Tại sao:
TĐiều này sẽ cho bạn cơ hội để đối phó với các xung đột trên máy tính của bạn trong khi rebasing (sau đó) thay vì tạo một Pull Request có chứa xung đột.
-
Cập nhật nhánh tính năng của bạn với những thay đổi mới nhất từ phát triển bằng cách rebase.
git checkout <branchname> git rebase -i --autosquash develop
Tại sao:
Bạn có thể sử dụng --autosquash để làm lại tất cả các cmmit của bạn thành một commit duy nhất.Không ai muốn có quá nhiều commit cho một tính năng trogn nhánh phát triển. đọc thêm...
-
Nếu bạn không có xung đột, bỏ qua bước này. Nếu ban có xung đột, giải quyết chúng và tiếp tục rebase.
git add <file1> <file2> ... git rebase --continue
-
Push nhánh của bạn. Rebase sẽ thay đổi lịch sử, nên bạn phải sử dụng
-fđể buộc các thay đổi vào nhánh remote. Nếu ai đó đang làm việc trên nhánh của bạn, hãy sử dụng phương pháp ít gây tổn hại hơn--force-with-lease.git push -f
Why:
WKhi bạn thực hiện một rebase, bạn đang thay đổi lịch sử trên nhánh chức năng của bạn.Kết quả là, Git sẽ từ chối push một cách bình thường
git push. Thay vì vậy, bạn sẽ cần sử dụng -f hoặc --force cờ. đọc thêm... -
Tạo một Pull Request.
-
Pull request sẽ được chấp nhận, được merge hoặc đóng bới người đánh giá.
-
Gỡ nhánh tính năng trên local của bạn nếu bạn đã hoàn thành.
git branch -d <branchname>
để gỡ tất cả các nhánh không còn trên remote
git fetch -p && for branch in `git branch -vv --no-color | grep ': gone]' | awk '{print $1}'`; do git branch -D $branch; done
Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. Here are some rules of thumb (source): Để có một hướng dẫn tốt cho việc tạo các commit và stichking để làm cho việc làm việc với Git và cộng tác với người khác dễ dàng hơn rất nhiều. Sau đây là một vài luật chính (nguồn):
-
Tách đối tượng từ thân với một dòng mới ở giữa 2 phần.
Tại sao:
Git đủ thông minh để phân biệt dòng đầu tiên commit dưới dạng tóm tắt của bạn. Thực tế, nếu bạn thử git shortlog, thay vì git log, bạn sẽ thấy một danh sách commit dài. bao gồm cả id của commit, và chỉ bản tổng hợp.
-
Giới hạn là 50 với chủ đề vào 75 với nội dung.
why
Các commit snên được mịn và tập trung nhất có thể, nó không phải là nơi được rườm rà. đọc thêm...
-
Tận dụng chủ đề.
-
Không kết thúc chủ đề với một khoảng thòi gian.
-
Sử dụng câu mệnh lệnh trong chủ đề.
Tại sao:
Thay vì viết một tin nhắn nói rằng một commiter đã hoàn thành. Tốt hơn nên xem các thông báo này như là hướng dẫn cho những gì sẽ được thực hiện sau khi commit được áp dụng trên repo. đọc thêm...
-
Sử dụng nội dung để giải thích cái gì và tại sao trái ngược với làm thế nào.