Skip to content

Instantly share code, notes, and snippets.

@nguyentien98

nguyentien98/Git_Basic-Nguyen-Van-Tien.md

Last active November 9, 2022 08:45
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save nguyentien98/47e00eef3f93e6b7523b72c7c4437993 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save nguyentien98/47e00eef3f93e6b7523b72c7c4437993 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 6 additions and 6 deletions.
    12 changes: 6 additions & 6 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -137,16 +137,16 @@ Ngược lại git fetch $remote_origin sẽ tải về (fetch) dữ liệu củ
    Git diff
    --------

    git diff View difference between Stage and Working Directory
    git diff --staged View difference between HEAD and Stage
    git diff HEAD View difference between HEAD and Working Directory
    * git diff View difference between Stage and Working Directory
    * git diff --staged View difference between HEAD and Stage
    * git diff HEAD View difference between HEAD and Working Directory

    Git reset
    ---------

    reset --soft : History changed, HEAD changed, Working directory is not changed.
    reset --mixed : History changed, HEAD changed, Working directory changed with unstaged data.
    reset --hard : History changed, HEAD changed, Working directory is changed with lost data.
    * reset --soft : History changed, HEAD changed, Working directory is not changed.
    * reset --mixed : History changed, HEAD changed, Working directory changed with unstaged data.
    * reset --hard : History changed, HEAD changed, Working directory is changed with lost data.


    ### 1.1 Quy trình làm việc Git
  2. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 14 additions and 0 deletions.
    14 changes: 14 additions & 0 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -134,6 +134,20 @@ Như vậy lưu ý rằng câu lệnh git pull $remote_origin $branch_name sẽ

    Ngược lại git fetch $remote_origin sẽ tải về (fetch) dữ liệu của toàn bộ các branch trên URL quy định bởi $remote_origin nhưng không thực hiện việc merge các thay đổi này vào local.

    Git diff
    --------

    git diff View difference between Stage and Working Directory
    git diff --staged View difference between HEAD and Stage
    git diff HEAD View difference between HEAD and Working Directory

    Git reset
    ---------

    reset --soft : History changed, HEAD changed, Working directory is not changed.
    reset --mixed : History changed, HEAD changed, Working directory changed with unstaged data.
    reset --hard : History changed, HEAD changed, Working directory is changed with lost data.


    ### 1.1 Quy trình làm việc Git
    Những bước chính dưới đây:
  3. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 7 additions and 0 deletions.
    7 changes: 7 additions & 0 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -128,6 +128,13 @@ Chạy lệnh:

    Sau đó chạy `git push ** **` rồi nhập thông tin đăng nhập 1 lần. Từ sau không cần nữa.

    So Sánh "git fetch" và "git pull"
    ---------------------------------
    Như vậy lưu ý rằng câu lệnh git pull $remote_origin $branch_name sẽ tải về (hay fetch) dữ liệu từ một branch duy nhất $branch_name từ remote server và sau đó merge các thay đổi từ remote này vào repository dưới local.

    Ngược lại git fetch $remote_origin sẽ tải về (fetch) dữ liệu của toàn bộ các branch trên URL quy định bởi $remote_origin nhưng không thực hiện việc merge các thay đổi này vào local.


    ### 1.1 Quy trình làm việc Git
    Những bước chính dưới đây:

  4. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 6 additions and 0 deletions.
    6 changes: 6 additions & 0 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -120,7 +120,13 @@ Nếu bạn muốn hủy tất cả thay đổi và commit cục bộ, lấy v
    `git fetch origin`
    `git reset --hard origin/master`

    Lưu đăng nhập tài khoản Git
    ---------------------------

    Chạy lệnh:
    `git config credential.helper store`

    Sau đó chạy `git push ** **` rồi nhập thông tin đăng nhập 1 lần. Từ sau không cần nữa.

    ### 1.1 Quy trình làm việc Git
    Những bước chính dưới đây:
  5. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 5 additions and 3 deletions.
    8 changes: 5 additions & 3 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -76,11 +76,13 @@ nhánh

    Các nhánh (branches) được dùng để phát triển tính năng tách riêng ra từ những nhánh khác. Nhánh _master_ là nhánh "mặc định" khi bạn tạo một repository. Sử dụng các nhánh khác tri đang trong giai đoạn phát triển và merge trở lại nhánh master một khi đã hoàn tất.

    tạo một nhánh mới và đặt tên là "feature_x":
    `git branch -b feature_x`
    chuyển qua một nhánh
    `git checkout feature_x`
    tạo một nhánh mới và đặt tên là "feature_x" và chuyển qua nhánh đó (từ master) bằng cách
    `git checkout -b feature_x`
    trở lại nhánh master
    `git checkout master`
    và xóa nhánh feature_x đó lần nửa
    và xóa nhánh feature_x
    `git branch -d feature_x`
    một nhánh _không có giá trị với các nhánh khác_ trừ khi bạn đẩy nhánh đó đến remote repository
    `git push origin <nhánh>`
  6. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -32,6 +32,7 @@ diff: So sánh sự sai khác giữa phiên bản hiện tại với phiên bả

    ### Phân biệt merging và rebase
    ![](https://viblo.asia/uploads/5c1aeeb6-ab9c-41b2-9174-ec7b13847da4.png)

    [Link tham khảo](https://viblo.asia/p/3-phut-de-hieu-ro-git-rebase-va-merge-khac-nhau-gi-vyDZOXnQlwj)

    ## Những lệnh Git cơ bản
  7. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -32,7 +32,7 @@ diff: So sánh sự sai khác giữa phiên bản hiện tại với phiên bả

    ### Phân biệt merging và rebase
    ![](https://viblo.asia/uploads/5c1aeeb6-ab9c-41b2-9174-ec7b13847da4.png)
    [Link tham khảohttps://viblo.asia/p/3-phut-de-hieu-ro-git-rebase-va-merge-khac-nhau-gi-vyDZOXnQlwj)
    [Link tham khảo](https://viblo.asia/p/3-phut-de-hieu-ro-git-rebase-va-merge-khac-nhau-gi-vyDZOXnQlwj)

    ## Những lệnh Git cơ bản
    Tạo một repository mới
  8. nguyentien98 revised this gist Jul 16, 2018. No changes.
  9. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -32,7 +32,7 @@ diff: So sánh sự sai khác giữa phiên bản hiện tại với phiên bả

    ### Phân biệt merging và rebase
    ![](https://viblo.asia/uploads/5c1aeeb6-ab9c-41b2-9174-ec7b13847da4.png)

    [Link tham khảohttps://viblo.asia/p/3-phut-de-hieu-ro-git-rebase-va-merge-khac-nhau-gi-vyDZOXnQlwj)

    ## Những lệnh Git cơ bản
    Tạo một repository mới
  10. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 34 additions and 2 deletions.
    36 changes: 34 additions & 2 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,39 @@
    **Tổng hợp bởi - tiennguyen98**

    ## Khái niệm
    Git là tên gọi của một Hệ thống quản lý phiên bản phân tán (Distributed Version Control System – DVCS) là một trong những hệ thống quản lý phiên bản phân tán phổ biến nhất hiện nay. DVCS nghĩa là hệ thống giúp mỗi máy tính có thể lưu trữ nhiều phiên bản khác nhau của một mã nguồn được nhân bản (clone) từ một kho chứa mã nguồn (repository), mỗi thay đổi vào mã nguồn trên máy tính sẽ có thể ủy thác (commit) rồi đưa lên máy chủ nơi đặt kho chứa chính. Và một máy tính khác (nếu họ có quyền truy cập) cũng có thể clone lại mã nguồn từ kho chứa hoặc clone lại một tập hợp các thay đổi mới nhất trên máy tính kia. Trong Git, thư mục làm việc trên máy tính gọi là Working Tree. Đại loại là như vậy.

    Mô hình hoạt động của DVCSMô hình hoạt động của DVCS
    Ngoài ra, có một cách hiểu khác về Git đơn giản hơn đó là nó sẽ giúp bạn lưu lại các phiên bản của những lần thay đổi vào mã nguồn và có thể dễ dàng khôi phục lại dễ dàng mà không cần copy lại mã nguồn rồi cất vào đâu đó. Và một người khác có thể xem các thay đổi của bạn ở từng phiên bản, họ cũng có thể đối chiếu các thay đổi của bạn rồi gộp phiên bản của bạn vào phiên bản của họ. Cuối cùng là tất cả có thể đưa các thay đổi vào mã nguồn của mình lên một kho chứa mã nguồn.

    Cơ chế lưu trữ phiên bản của Git là nó sẽ tạo ra một “ảnh chụp” (snapshot) trên mỗi tập tin và thư mục sau khi commit, từ đó nó có thể cho phép bạn tái sử dụng lại một ảnh chụp nào đó mà bạn có thể hiểu đó là một phiên bản. Đây cũng chính là lợi thế của Git so với các DVCS khác khi nó không “lưu cứng” dữ liệu mà sẽ lưu với dạng snapshot.

    ## Một vài khái niệm

    git: là prefix của các lệnh được sử dụng dưới CLI

    branch: được hiểu như là nhánh, thể hiện sự phân chia các version khi 2 version đó có sự sai khác nhất định và 2 version đều có sự khác nhau.

    commit: là một điểm trên cây công việc (Work Tree ) hay gọi là cây phát triển công việc

    clone: được gọi là nhân bản, hay thực hiện nhân bản. Sử dụng để clone các project, repository trên các hệ thống chạy trên cơ sở là git, ví dụ như: bitbucket, github, gitlab, cor(1 sản phẩm mã nguồn mở cho phép người dùng tự tạo git server cho riêng mình trên vps, server),... Việc clone này sẽ sao chép repository tại commit mình mong muốn, dùng để tiếp tục phát triển. Thao tác này sẽ tải toàn bộ mã nguồn, dữ liệu về máy tính của bạn.

    folk: Folk là thao tác thực hiện sao chép repository của chủ sở hữu khác về git account của mình. sử dụng và đối xử như 1 repository do mình tạo ra.

    repository: Kho quản lý dữ liệu, là nơi lưu trữ các dữ liệu, mã nguồn của project.

    tag: sử dụng để đánh dấu một commit khi bạn có quá nhiều commit tới mức không thể kiểm soát được.

    remote: sử dụng để điều khiển các nhánh từ một repository trên git server, đối xử với các nhánh trên remote tương tự như đối xử với các nhánh trên local

    diff: So sánh sự sai khác giữa phiên bản hiện tại với phiên bản muốn so sánh, nó sẽ thể hiện các sự khác nhau

    .gitignore: file mặc định của git sử dụng để loại bỏ (ignore) các thư mục, file mà mình không muốn push lên git server

    ### Phân biệt merging và rebase
    ![](https://viblo.asia/uploads/5c1aeeb6-ab9c-41b2-9174-ec7b13847da4.png)


    ## Những lệnh Git cơ bản
    Tạo một repository mới
    ----------------------
    @@ -41,8 +75,6 @@ nhánh

    Các nhánh (branches) được dùng để phát triển tính năng tách riêng ra từ những nhánh khác. Nhánh _master_ là nhánh "mặc định" khi bạn tạo một repository. Sử dụng các nhánh khác tri đang trong giai đoạn phát triển và merge trở lại nhánh master một khi đã hoàn tất.

    ![](img/branches.png)

    tạo một nhánh mới và đặt tên là "feature_x" và chuyển qua nhánh đó (từ master) bằng cách
    `git checkout -b feature_x`
    trở lại nhánh master
  11. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    **T
    **Tổng hợp bởi - tiennguyen98**

    ## Những lệnh Git cơ bản
    Tạo một repository mới
  12. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,6 @@
    ## Những câu lệnh Git cơ bản
    **T

    ## Những lệnh Git cơ bản
    Tạo một repository mới
    ----------------------

  13. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 2 additions and 7 deletions.
    9 changes: 2 additions & 7 deletions Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -13,13 +13,6 @@ sao chép (clone) một repository
    Nếu repository đó ở máy chủ khác thì bạn hãy gõ dòng lệnh sau:
    `git clone tênusername@địachỉmáychủ:/đường-dẫn-đến/repository`

    quy trình làm việc
    ------------------

    thư mục cục bộ của bạn bao gồm ba "trees" được duy trì bởi git. đầu tiên là `Thư Mục Đang Làm Việc (Working Directory)` có chứa các tập tin hiện tại. cái thứ hai là `Chỉ Mục (Index)` đóng vai trò như staging area và cuối cùng là `HEAD` trỏ đến commit gần đây nhất của bạn.

    ![](img/trees.png)

    thêm (add) & commit
    -------------------

    @@ -90,6 +83,8 @@ Nếu bạn muốn hủy tất cả thay đổi và commit cục bộ, lấy v
    `git fetch origin`
    `git reset --hard origin/master`



    ### 1.1 Quy trình làm việc Git
    Những bước chính dưới đây:

  14. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 93 additions and 1 deletion.
    94 changes: 93 additions & 1 deletion Git_Basic-Nguyen-Van-Tien.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,97 @@
    ## Những câu lệnh Git cơ bản
    Tạo một repository mới
    ----------------------

    Để tạo 1 repository mới, bạn hãy mở cửa sổ lệnh và gõ dòng lệnh sau
    `git init`

    sao chép (clone) một repository
    -------------------------------

    để clone 1 repository có sẵn ở trên máy cục bộ, bạn hãy sử dụng dòng lệnh sau:
    `git clone /đường-dẫn-đến/repository/`
    Nếu repository đó ở máy chủ khác thì bạn hãy gõ dòng lệnh sau:
    `git clone tênusername@địachỉmáychủ:/đường-dẫn-đến/repository`

    quy trình làm việc
    ------------------

    thư mục cục bộ của bạn bao gồm ba "trees" được duy trì bởi git. đầu tiên là `Thư Mục Đang Làm Việc (Working Directory)` có chứa các tập tin hiện tại. cái thứ hai là `Chỉ Mục (Index)` đóng vai trò như staging area và cuối cùng là `HEAD` trỏ đến commit gần đây nhất của bạn.

    ![](img/trees.png)

    thêm (add) & commit
    -------------------

    Bạn có thể đề xuất thay đổi (thêm nó vào chỉ mục **Index**) bằng cách
    `git add <tên-tập-tin>`
    `git add *`
    Đây là bước đầu tiên trong quy trình git cơ bản. Để thật sự commit những thay đổi, bạn sử dụng
    `git commit -m "Ghi chú Commit"`
    Bây giờ thì tập tin đã được commit đến **HEAD**, nhưng chưa phải trên thư mục remote.

    đẩy (push) các thay đổi
    -----------------------

    Thay đổi của bạn hiện đang nằm tại **HEAD** của bản sao cục bộ đang làm việc. Để gửi những thay đổi đó đến repository remote, bạn thực thi
    `git push origin master`
    Thay đổi _master_ bằng bất cứ nhánh nào mà bạn muốn đầy những thay đổi đến.

    Nếu bạn chưa clone một repository hiện có và muốn kết nối repository của bạn đến máy chủ remote, bạn phải thêm nó với
    `git remote add origin <máy-chủ>`
    Bây giờ bạn đã có thể đẩy các thay đổi của mình vào máy chủ đã chọn

    nhánh
    -----

    Các nhánh (branches) được dùng để phát triển tính năng tách riêng ra từ những nhánh khác. Nhánh _master_ là nhánh "mặc định" khi bạn tạo một repository. Sử dụng các nhánh khác tri đang trong giai đoạn phát triển và merge trở lại nhánh master một khi đã hoàn tất.

    ![](img/branches.png)

    tạo một nhánh mới và đặt tên là "feature_x" và chuyển qua nhánh đó (từ master) bằng cách
    `git checkout -b feature_x`
    trở lại nhánh master
    `git checkout master`
    và xóa nhánh feature_x đó lần nửa
    `git branch -d feature_x`
    một nhánh _không có giá trị với các nhánh khác_ trừ khi bạn đẩy nhánh đó đến remote repository
    `git push origin <nhánh>`

    cập nhật & trộn (update & merge)
    --------------------------------

    để cập nhật repository cục bộ của bạn và commit mới nhất, thực thi
    `git pull`
    trong thự mục đang làm việc để _lấy về (fetch)_ và _trộn (merge)_ các thay đổi ở remote.
    để trộn một nhánh khác vào nhánh đang hoạt động (vd: master), sử dụng
    `git merge <nhánh>`
    trong cả hai trường hợp, git cố gắng trộn tự động (auto-merge) các thay đổi. Không may, điều này không phải lúc nào cũng làm được và thường dẫn đến _xung đột_. Trách nhiệm của bạn là trộn _các xung đột_ đó thủ công bằng cách chỉnh sửa các tập tin được hiển thị bởi git. Sau khi thay đổi, bạn phải đánh dấu chúng là đã được trộn (merged) với lệnh
    `git add <tên-tập-tin>`
    trước khi trộn các thay đổi, bạn có thể xem trước chúng bằng các
    `git diff <nhánh_nguồn> <nhánh_mục_tiêu>`

    gắn nhãn (tagging)
    ------------------

    người ta khuyên nên tạo nhãn (tags) khi phát hành phần mềm. đây là khái niệm được biết đến, đã từng có trên SVN. Bạn tạo tag mới tên là _1.0.0_ bằng cách
    `git tag 1.0.0 1b2e1d63ff`
    chuỗi _1b2e1d63ff_ là 10 ký tự đầu tiên của mã commit (commit id) mà bạn muốn tham chiếu đến bằng nhãn của bạn. Bạn có thể lấy mã commit với lệnh
    `git log`
    bạn cũng có thể sử dụng ít ký tự hơn từ mã commit, nó chỉ cần phải là duy nhất.

    thay thế các thay đổi cục bộ
    ----------------------------

    Trong trường hợp bạn làm sai điều gì đó, bạn có thể thay thế các thay đổi cục bộ bằng lệnh
    `git checkout -- <tên-tập-tin>`
    lệnh này thay thế những thay đổi trong "tree" đang làm việc với nội dung mới nhất của HEAD. Các thay đổi đã được thêm vào chỉ mục, kể cả các tập tin mới, điều này sẽ được giữ lại.

    Nếu bạn muốn hủy tất cả thay đổi và commit cục bộ, lấy về (fetch) lịch sử gần đây nhất từ máy chủ và trỏ nhánh master cục bộ vào nó như sau
    `git fetch origin`
    `git reset --hard origin/master`

    ### 1.1 Quy trình làm việc Git
    Bởi vì hầu hết những lý do ở trên, chúng ta sử dụng [Quy trình quy trình làm việc nhánh tính năng](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) với [Việc tương tác rebase](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) và một vài phần tử của [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) ( việc đặt tên và có một nhánh develop ). Những bước chính dưới đây:
    Những bước chính dưới đây:

    * Cho một dự án mới, khởi tạo một repository git trong danh mục dự án. __Đối với các tính năng / thay đổi tiếp theo, bước này sẽ bị bỏ qua__.
    ```sh
  15. nguyentien98 renamed this gist Jul 16, 2018. 1 changed file with 0 additions and 0 deletions.
    0 Nguyen_Van_Tien_git_guidelines.md → Git_Basic-Nguyen-Van-Tien.md
    View file
    File renamed without changes.
  16. nguyentien98 revised this gist Jul 16, 2018. No changes.
  17. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 16 additions and 0 deletions.
    16 changes: 16 additions & 0 deletions Nguyen_Van_Tien_git_guidelines.md
    View file
    Original file line number Diff line number Diff line change
    @@ -127,3 +127,19 @@ Việc có một dòng hướng dẫn cho việc commit và việc gắn bó v
    > Thay vì viết tin nhắn cho biết những gì người commit đã làm. Tốt nhất nên xem xét 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 repository. [đọc thêm...](https://news.ycombinator.com/item?id=2079612)

    * Dùng phần thân để giải thích **cái gì** và **tại sao** giống như phản đối **tại sao**.

    ### Gitignore:
    Gitignore là file có tên là .gitignore, nhiệm vụ của nó là liệt kê những file mà mình không mong muốn cho vào cho lên Git. Ví dụ như trong một dự án mỗi người có thể sẽ dùng một IDE khác nhau. Khi dó IDE có thể sinh ra những file rác vào trong dự án, gây rối mắt hoặc conflict cho người khác. Vì vậy phải dùng .gitignore.

    **Các cú pháp cơ bản trong .gitignore**
    * Sử dụng `#` để comment.
    * Điền tên file cần loại bỏ: `tenfile.php`
    * Loại bỏ thư mục: `example_folder/`
    * Khi ignore thư mục nên có dấu / ở sau tên thư mục để nhận biết đó là thư mục.
    * Dấu ! phía trước có ý nghĩa phủ định: `!abc/example.exe`
    * Xóa file cùng đuôi `*.xml`
    * Trường hợp khác của 1 * nếu bạn chỉ rõ đường dẫn ví dụ: `config/*.xml` thì nó chỉ có hiệu lực cho các file config/abc.xml.
    * Dùng `**/folder` nó sẽ có hiệu lực cho tất cả folder ở khắp nơi trong dự án.
    * Hay sử dụng kiểu `folder/**` để có hiệu lực cho tất cả các file bên trong thư mục.


  18. nguyentien98 revised this gist Jul 16, 2018. 1 changed file with 42 additions and 46 deletions.
    88 changes: 42 additions & 46 deletions Nguyen_Van_Tien_git_guidelines.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,47 +1,4 @@
    ### 1.1 Một vài quy tắc của Git
    Có một bộ các quy tắc cần được ghi nhơ:
    * Thực hiện công việc trong một nhánh tính năng

    _Tại sao:_
    >Bởi vì cách với tất cả công việc được hoàn thành trong sự cô lập trên một nhánh chuyên dụng hơn là nhánh chính. Nó cho phép bạn submit nhiều pull request không có nhầm lẫn. Bạn có thể lặp lại mà không gây sai xót cho nhánh chính với code không ổn định, code chưa hoàn thành. [đọc thêm tại...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    * Chia nhánh từ `develop`

    _Tại sao:_
    >Cách này, bạn có thể chắc chắn rằng code trong master sẽ gần như luôn luôn xây dựng mà không có vấn đề, và có thể sử dụng trực tiếp cho việc phát hành ( nó có thể quá mức cho một vài dự án).
    * Đừng bao giờ push lên nhánh `develop` hoặc `master`. Tạo một pull request.

    _Tại sao:_
    > Nó thông báo cho các thành viên trong nhóm rằng họ đã hoàn thành một tính năng. Nó cũng cho phép dễ dàng đánh giá ngang hàng của code và có riêng diễn đàn cho việc thảo luận về tính năng đã đề xuất.
    *Cập nhật nhánh `develop` ở trên local của bạn 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:_
    > Việc rebase sẽ merge trong nhánh được yêu cầu (`master` hoặc` develop`) và áp dụng các commit mà bạn đã thực hiện ở local trên đầu lịch sử mà không tạo ra một merge commit (giả sử rằng không có xung đột). Kết quả là một lịch sử đẹp và sạch sẽ. [read more ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)

    * Giải quyết xung đột trong khi rebase và trước khi thực hiện pull pequest.
    * Xóa local và nhánh tính năng sau khi merge.

    _Tại sao:_
    > Nó sẽ làm xáo trộng danh sách các nhánh của bạn với nhánh đã bỏ. Nó đảm bảo bạn chỉ merge khi các nhánh vào trong (`master` hoặc `develop`) một lần. Các nhánh tính năng nên chỉ tồn tại trong khi công việc vẫn trong quá trình.
    * Trước khi thực hiện pull request, hãy đảm bảo nhánh tính năng của bạn được xây dựng thành công và vượt qua tất cả các test (bao gồm kiểm tra phong cách code).

    _Tại sao:_
    > Bạn sắp thêm code của bạn vào một nhánh ổn định. Nếu nhánh tính tăng test sai, có một cơ hội cao rằng nhánh mà bạn xây dựng cũng sẽ sai. Thêm nữa, bạn cần áp dụng phong cách code trước khi tạo pull request. Nó hỗ trợ khả năng đọc và giảm khả năng sửa các định dạng được trộn lẫn với các thay đổi thực tế.
    * Dùng file [this](./.gitignore) `.gitignore`.

    _Tại sao:_
    > Nó đã có danh sách các tệp hệ thống không được gửi cùng với mã của bạn vào một repository. Ngoài ra, nó không bao gồm cài đặt thư mục và tệp cho hầu hết các editor được sử dụng, cũng như các thư mục chung thuộc phổ biến nhất
    * Bảo vệ nhánh `develop` và `master`

    _Tại sao:_
    > Nó bảo vệ các nhánh sản phẩm đã sẵn sàng của bạn khỏi những thay đổi bất ngờ và không thể đảo ngược. đọc thêm tại... [Github](https://help.github.com/articles/about-protected-branches/), [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html) and [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html)
    <a name="git-workflow"></a>
    ### 1.2 Quy trình làm việc Git
    ### 1.1 Quy trình làm việc Git
    Bởi vì hầu hết những lý do ở trên, chúng ta sử dụng [Quy trình quy trình làm việc nhánh tính năng](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) với [Việc tương tác rebase](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) và một vài phần tử của [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) ( việc đặt tên và có một nhánh develop ). Những bước chính dưới đây:

    * Cho một dự án mới, khởi tạo một repository git trong danh mục dự án. __Đối với các tính năng / thay đổi tiếp theo, bước này sẽ bị bỏ qua__.
    @@ -107,6 +64,47 @@ Bởi vì hầu hết những lý do ở trên, chúng ta sử dụng [Quy trìn
    ```

    <a name="writing-good-commit-messages"></a>
    ### 1.2 Một vài quy tắc của Git
    Có một bộ các quy tắc cần được ghi nhơ:
    * Thực hiện công việc trong một nhánh tính năng

    _Tại sao:_
    >Bởi vì cách với tất cả công việc được hoàn thành trong sự cô lập trên một nhánh chuyên dụng hơn là nhánh chính. Nó cho phép bạn submit nhiều pull request không có nhầm lẫn. Bạn có thể lặp lại mà không gây sai xót cho nhánh chính với code không ổn định, code chưa hoàn thành. [đọc thêm tại...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    * Chia nhánh từ `develop`

    _Tại sao:_
    >Cách này, bạn có thể chắc chắn rằng code trong master sẽ gần như luôn luôn xây dựng mà không có vấn đề, và có thể sử dụng trực tiếp cho việc phát hành ( nó có thể quá mức cho một vài dự án).

    * Đừng bao giờ push lên nhánh `develop` hoặc `master`. Tạo một pull request.

    _Tại sao:_
    > Nó thông báo cho các thành viên trong nhóm rằng họ đã hoàn thành một tính năng. Nó cũng cho phép dễ dàng đánh giá ngang hàng của code và có riêng diễn đàn cho việc thảo luận về tính năng đã đề xuất.

    *Cập nhật nhánh `develop` ở trên local của bạn 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:_
    > Việc rebase sẽ merge trong nhánh được yêu cầu (`master` hoặc` develop`) và áp dụng các commit mà bạn đã thực hiện ở local trên đầu lịch sử mà không tạo ra một merge commit (giả sử rằng không có xung đột). Kết quả là một lịch sử đẹp và sạch sẽ. [read more ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)

    * Giải quyết xung đột trong khi rebase và trước khi thực hiện pull pequest.
    * Xóa local và nhánh tính năng sau khi merge.

    _Tại sao:_
    > Nó sẽ làm xáo trộng danh sách các nhánh của bạn với nhánh đã bỏ. Nó đảm bảo bạn chỉ merge khi các nhánh vào trong (`master` hoặc `develop`) một lần. Các nhánh tính năng nên chỉ tồn tại trong khi công việc vẫn trong quá trình.

    * Trước khi thực hiện pull request, hãy đảm bảo nhánh tính năng của bạn được xây dựng thành công và vượt qua tất cả các test (bao gồm kiểm tra phong cách code).

    _Tại sao:_
    > Bạn sắp thêm code của bạn vào một nhánh ổn định. Nếu nhánh tính tăng test sai, có một cơ hội cao rằng nhánh mà bạn xây dựng cũng sẽ sai. Thêm nữa, bạn cần áp dụng phong cách code trước khi tạo pull request. Nó hỗ trợ khả năng đọc và giảm khả năng sửa các định dạng được trộn lẫn với các thay đổi thực tế.

    * Dùng file [this](./.gitignore) `.gitignore`.

    _Tại sao:_
    > Nó đã có danh sách các tệp hệ thống không được gửi cùng với mã của bạn vào một repository. Ngoài ra, nó không bao gồm cài đặt thư mục và tệp cho hầu hết các editor được sử dụng, cũng như các thư mục chung thuộc phổ biến nhất

    * Bảo vệ nhánh `develop` và `master`

    _Tại sao:_
    > Nó bảo vệ các nhánh sản phẩm đã sẵn sàng của bạn khỏi những thay đổi bất ngờ và không thể đảo ngược. đọc thêm tại... [Github](https://help.github.com/articles/about-protected-branches/), [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html) and [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html)
    ### 1.3 Viết lời nhắn khi commit

    Việc có một dòng hướng dẫn cho việc commit và việc gắn bó với nó làm cho việc làm việc với Git và công tác viên cùng với rất nhiều thứ khác dễ dàng hơn. Đây là một vài quy tắc. ([nguồn](https://chris.beams.io/posts/git-commit/#seven-rules)):
    @@ -129,5 +127,3 @@ Việc có một dòng hướng dẫn cho việc commit và việc gắn bó v
    > Thay vì viết tin nhắn cho biết những gì người commit đã làm. Tốt nhất nên xem xét 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 repository. [đọc thêm...](https://news.ycombinator.com/item?id=2079612)

    * Dùng phần thân để giải thích **cái gì** và **tại sao** giống như phản đối **tại sao**.

    <a name="documentation"></a>
  19. nguyentien98 revised this gist Apr 19, 2018. 1 changed file with 17 additions and 19 deletions.
    36 changes: 17 additions & 19 deletions Nguyen_Van_Tien_git_guidelines.md
    View file
    Original file line number Diff line number Diff line change
    @@ -94,42 +94,40 @@ Bởi vì hầu hết những lý do ở trên, chúng ta sử dụng [Quy trìn
    > Khi bạn rebase, bạn đang thay đổi lịch sử trong nhánh tính năng của bạn. Giống như một kết quả, Git sẽ từ chối bình thường `git push`. Tahy vào đó bạn sẽ cần sử dụng -f hoặc --force. [đọc thêm tại...](https://developer.atlassian.com/blog/2015/04/force-with-lease/)

    * Tạo một pull request
    * Pull request
    * Make a Pull Request.
    * Pull request will be accepted, merged and close by a reviewer.
    * Remove your local feature branch if you're done.
    * Pull request sẽ được chấp nhận, merge và đóng bởi người review.
    * Xóa nhánh tính năng trên local của bạn nếu bạn đã hoàn thành.

    ```sh
    git branch -d <branchname>
    ```
    to remove all branches which are no longer on remote
    Để xóa tất cả nhánh mà nó đã lâu không điều khiển
    ```sh
    git fetch -p && for branch in `git branch -vv --no-color | grep ': gone]' | awk '{print $1}'`; do git branch -D $branch; done
    ```

    <a name="writing-good-commit-messages"></a>
    ### 1.3 Writing good commit messages
    ### 1.3 Viết lời nhắn khi commit

    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](https://chris.beams.io/posts/git-commit/#seven-rules)):
    Việc có một dòng hướng dẫn cho việc commit và việc gắn bó với nó làm cho việc làm việc với Git và công tác viên cùng với rất nhiều thứ khác dễ dàng hơn. Đây là một vài quy tắc. ([nguồn](https://chris.beams.io/posts/git-commit/#seven-rules)):

    * Separate the subject from the body with a newline between the two.
    Tách riêng chủ đề khỏi phần thân với một dòng giữa chúng

    _Why:_
    > Git is smart enough to distinguish the first line of your commit message as your summary. In fact, if you try git shortlog, instead of git log, you will see a long list of commit messages, consisting of the id of the commit, and the summary only.
    * Limit the subject line to 50 characters and Wrap the body at 72 characters.
    _Tại sao:_
    > Git đủ thông minh để phân biệt dòng đầu tiên của lời nhắn commit của bạn dưới dạng tóm tắt. Trong thực tế, nếu bạn thử git shortlog, thay vì git log, bạn sẽ thấy một danh sách dài các lời nhắn commit, bao gồm id của commit, và bản tóm tắt duy nhất.

    _why_
    > Commits should be as fine-grained and focused as possible, it is not the place to be verbose. [read more...](https://medium.com/@preslavrachev/what-s-with-the-50-72-rule-8a906f61f09c)
    * Giới hạn dòng chủ đề ở 50 chữ và gói gọn phần thân trong 72 chữ.

    * Capitalize the subject line.
    * Do not end the subject line with a period.
    * Use [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) in the subject line.
    _Tại sao_
    > Các commit nên được làm tốt và tập trung nhất có thể, nó không phải là nơi để được verbose. [đọc thêm...](https://medium.com/@preslavrachev/what-s-with-the-50-72-rule-8a906f61f09c)

    _Why:_
    > Rather than writing messages that say what a committer has done. It's better to consider these messages as the instructions for what is going to be done after the commit is applied on the repository. [read more...](https://news.ycombinator.com/item?id=2079612)
    * Viết hoa dòng chủ đề.
    * Không kết thúc dòng chủ đề với một khoảng.
    * Dùng [Tình trạng gấp](https://en.wikipedia.org/wiki/Imperative_mood) trong dòng chủ đề.

    _Tại sao:_
    > Thay vì viết tin nhắn cho biết những gì người commit đã làm. Tốt nhất nên xem xét 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 repository. [đọc thêm...](https://news.ycombinator.com/item?id=2079612)

    * Use the body to explain **what** and **why** as opposed to **how**.
    * Dùng phần thân để giải thích **cái gì** và **tại sao** giống như phản đối **tại sao**.

    <a name="documentation"></a>
  20. nguyentien98 revised this gist Apr 19, 2018. 1 changed file with 22 additions and 21 deletions.
    43 changes: 22 additions & 21 deletions Nguyen_Van_Tien_git_guidelines.md
    View file
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@ Có một bộ các quy tắc cần được ghi nhơ:
    * Thực hiện công việc trong một nhánh tính năng

    _Tại sao:_
    >Bởi vì cách với tất cả công việc được hoàn thành trong sự cô lập trên một nhánh chuyên dụng hơn là nhánh chính. Nó cho phép bạn submit nhiều pull request không có nhầm lẫn. Bạn có thể lặp lại mà không gây sai xót cho nhánh chính với code không ổn định, code chưa hoàn thành. [read more...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    >Bởi vì cách với tất cả công việc được hoàn thành trong sự cô lập trên một nhánh chuyên dụng hơn là nhánh chính. Nó cho phép bạn submit nhiều pull request không có nhầm lẫn. Bạn có thể lặp lại mà không gây sai xót cho nhánh chính với code không ổn định, code chưa hoàn thành. [đọc thêm tại...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    * Chia nhánh từ `develop`

    _Tại sao:_
    @@ -41,59 +41,60 @@ Có một bộ các quy tắc cần được ghi nhơ:
    > Nó bảo vệ các nhánh sản phẩm đã sẵn sàng của bạn khỏi những thay đổi bất ngờ và không thể đảo ngược. đọc thêm tại... [Github](https://help.github.com/articles/about-protected-branches/), [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html) and [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html)
    <a name="git-workflow"></a>
    ### 1.2 Git workflow
    Because of most of the reasons above, we use [Feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) with [Interactive Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) and some elements of [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) (naming and having a develop branch). The main steps are as follows:
    ### 1.2 Quy trình làm việc Git
    Bởi vì hầu hết những lý do ở trên, chúng ta sử dụng [Quy trình quy trình làm việc nhánh tính năng](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) với [Việc tương tác rebase](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) và một vài phần tử của [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) ( việc đặt tên và có một nhánh develop ). Những bước chính dưới đây:

    * For a new project, initialize a git repository in the project directory. __For subsequent features/changes this step should be ignored__.
    * Cho một dự án mới, khởi tạo một repository git trong danh mục dự án. __Đối với các tính năng / thay đổi tiếp theo, bước này sẽ bị bỏ qua__.
    ```sh
    cd <project directory>
    git init
    ```

    * Checkout a new feature/bug-fix branch.
    * Checkout một nhánh tính năng hoặc nhánh để sửa lỗi.
    ```sh
    git checkout -b <branchname>
    ```
    * Make Changes.
    * Tạo sự thay đổi.
    ```sh
    git add
    git commit -a
    ```
    _Why:_
    > `git commit -a` will start an editor which lets you separate the subject from the body. Read more about it in *section 1.3*.
    _Tại sao:_
    > `git commit -a` sẽ bắt đầu một editor mà nó cho phép bạn tách chủ đề khỏi thân. Đọc thêm về nó tại *mục 1.3*.

    * Sync with remote to get changes you’ve missed.
    * Đồng bộ với điều khiển để có sự thay đổi mà bạn đã bỏ lỡ
    ```sh
    git checkout develop
    git pull
    ```

    _Why:_
    > This will give you a chance to deal with conflicts on your machine while rebasing (later) rather than creating a Pull Request that contains conflicts.
    * Update your feature branch with latest changes from develop by interactive rebase.
    _Tại sao:_
    > Điều này sẽ cung cấp cho bạn một cơ hội để đối phó với các xung đột trên máy của bạn trong khi rebase (sau này) hơn là tạo một pull request có chứa xung đột.

    * Cập nhật nhánh tính năng với thay đổi cuối cùng từ develop bằng việc rebase.
    ```sh
    git checkout <branchname>
    git rebase -i --autosquash develop
    ```

    _Why:_
    > You can use --autosquash to squash all your commits to a single commit. Nobody wants many commits for a single feature in develop branch. [read more...](https://robots.thoughtbot.com/autosquashing-git-commits)
    * If you don’t have conflicts, skip this step. If you have conflicts, [resolve them](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/) and continue rebase.
    _Tại sao:_
    > Bạn có thể dùng --autosquash để squash tất cả commit của bạn đến một commit riêng. Không ai muốn nhiều commit cho một tính năng trong nhánh develop. [đọc thêm...](https://robots.thoughtbot.com/autosquashing-git-commits)

    *Nếu bạn không có xung đột, bỏ qua bước này. Nếu bạn có, [giải quyết chúng](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/) và tiếp tục rebase.
    ```sh
    git add <file1> <file2> ...
    git rebase --continue
    ```
    * Push your branch. Rebase will change history, so you'll have to use `-f` to force changes into the remote branch. If someone else is working on your branch, use the less destructive `--force-with-lease`.
    * Push nhánh của bạn. Rebase sẽ thay đổi lịch sử, vật bạn sẽ phải dùng `-f` để bắt buộc những thay đổi trong nhánh điều khiển. Nếu một ái đó khác đang làm việc trên nhánh của bạn, sử dụng `--force-with-lease` để giảm lỗi.
    ```sh
    git push -f
    ```

    _Why:_
    > When you do a rebase, you are changing the history on your feature branch. As a result, Git will reject normal `git push`. Instead, you'll need to use the -f or --force flag. [read more...](https://developer.atlassian.com/blog/2015/04/force-with-lease/)

    _Tai sao:_
    > Khi bạn rebase, bạn đang thay đổi lịch sử trong nhánh tính năng của bạn. Giống như một kết quả, Git sẽ từ chối bình thường `git push`. Tahy vào đó bạn sẽ cần sử dụng -f hoặc --force. [đọc thêm tại...](https://developer.atlassian.com/blog/2015/04/force-with-lease/)

    * Tạo một pull request
    * Pull request
    * Make a Pull Request.
    * Pull request will be accepted, merged and close by a reviewer.
    * Remove your local feature branch if you're done.
  21. nguyentien98 revised this gist Apr 19, 2018. 1 changed file with 27 additions and 31 deletions.
    58 changes: 27 additions & 31 deletions Nguyen_Van_Tien_git_guidelines.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,48 +1,44 @@
    ## 1. Git
    ![Git](/images/branching.png)
    <a name="some-git-rules"></a>

    ### 1.1 Some Git rules
    There are a set of rules to keep in mind:
    * Perform work in a feature branch.
    ### 1.1 Một vài quy tắc của Git
    Có một bộ các quy tắc cần được ghi nhơ:
    * Thực hiện công việc trong một nhánh tính năng

    _Why:_
    >Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. [read more...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    * Branch out from `develop`
    _Tại sao:_
    >Bởi vì cách với tất cả công việc được hoàn thành trong sự cô lập trên một nhánh chuyên dụng hơn là nhánh chính. Nó cho phép bạn submit nhiều pull request không có nhầm lẫn. Bạn có thể lặp lại mà không gây sai xót cho nhánh chính với code không ổn định, code chưa hoàn thành. [read more...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    * Chia nhánh từ `develop`

    _Why:_
    >This way, you can make sure that code in master will almost always build without problems, and can be mostly used directly for releases (this might be overkill for some projects).
    _Tại sao:_
    >Cách này, bạn có thể chắc chắn rằng code trong master sẽ gần như luôn luôn xây dựng mà không có vấn đề, và có thể sử dụng trực tiếp cho việc phát hành ( nó có thể quá mức cho một vài dự án).
    * Never push into `develop` or `master` branch. Make a Pull Request.
    * Đừng bao giờ push lên nhánh `develop` hoặc `master`. Tạo một pull request.

    _Why:_
    > It notifies team members that they have completed a feature. It also enables easy peer-review of the code and dedicates forum for discussing the proposed feature.
    _Tại sao:_
    > Nó thông báo cho các thành viên trong nhóm rằng họ đã hoàn thành một tính năng. Nó cũng cho phép dễ dàng đánh giá ngang hàng của code và có riêng diễn đàn cho việc thảo luận về tính năng đã đề xuất.
    * Update your local `develop` branch and do an interactive rebase before pushing your feature and making a Pull Request.
    *Cập nhật nhánh `develop` ở trên local của bạn 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.

    _Why:_
    > Rebasing will merge in the requested branch (`master` or `develop`) and apply the commits that you have made locally to the top of the history without creating a merge commit (assuming there were no conflicts). Resulting in a nice and clean history. [read more ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
    _Tại sao:_
    > Việc rebase sẽ merge trong nhánh được yêu cầu (`master` hoặc` develop`) và áp dụng các commit mà bạn đã thực hiện ở local trên đầu lịch sử mà không tạo ra một merge commit (giả sử rằng không có xung đột). Kết quả là một lịch sử đẹp và sạch sẽ. [read more ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)

    * Resolve potential conflicts while rebasing and before making a Pull Request.
    * Delete local and remote feature branches after merging.
    * Giải quyết xung đột trong khi rebase và trước khi thực hiện pull pequest.
    * Xóa local và nhánh tính năng sau khi merge.

    _Why:_
    > It will clutter up your list of branches with dead branches. It ensures you only ever merge the branch back into (`master` or `develop`) once. Feature branches should only exist while the work is still in progress.
    _Tại sao:_
    > Nó sẽ làm xáo trộng danh sách các nhánh của bạn với nhánh đã bỏ. Nó đảm bảo bạn chỉ merge khi các nhánh vào trong (`master` hoặc `develop`) một lần. Các nhánh tính năng nên chỉ tồn tại trong khi công việc vẫn trong quá trình.
    * Before making a Pull Request, make sure your feature branch builds successfully and passes all tests (including code style checks).
    * Trước khi thực hiện pull request, hãy đảm bảo nhánh tính năng của bạn được xây dựng thành công và vượt qua tất cả các test (bao gồm kiểm tra phong cách code).

    _Why:_
    > You are about to add your code to a stable branch. If your feature-branch tests fail, there is a high chance that your destination branch build will fail too. 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.
    _Tại sao:_
    > Bạn sắp thêm code của bạn vào một nhánh ổn định. Nếu nhánh tính tăng test sai, có một cơ hội cao rằng nhánh mà bạn xây dựng cũng sẽ sai. Thêm nữa, bạn cần áp dụng phong cách code trước khi tạo pull request. Nó hỗ trợ khả năng đọc và giảm khả năng sửa các định dạng được trộn lẫn với các thay đổi thực tế.
    * Use [this](./.gitignore) `.gitignore` file.
    * Dùng file [this](./.gitignore) `.gitignore`.

    _Why:_
    > It already has a list of system files that should not be sent with your code into a remote repository. In addition, it excludes setting folders and files for most used editors, as well as most common dependency folders.
    _Tại sao:_
    > Nó đã có danh sách các tệp hệ thống không được gửi cùng với mã của bạn vào một repository. Ngoài ra, nó không bao gồm cài đặt thư mục và tệp cho hầu hết các editor được sử dụng, cũng như các thư mục chung thuộc phổ biến nhất
    * Protect your `develop` and `master` branch.
    * Bảo vệ nhánh `develop` và `master`

    _Why:_
    > It protects your production-ready branches from receiving unexpected and irreversible changes. read more... [Github](https://help.github.com/articles/about-protected-branches/), [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html) and [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html)
    _Tại sao:_
    > Nó bảo vệ các nhánh sản phẩm đã sẵn sàng của bạn khỏi những thay đổi bất ngờ và không thể đảo ngược. đọc thêm tại... [Github](https://help.github.com/articles/about-protected-branches/), [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html) and [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html)
    <a name="git-workflow"></a>
    ### 1.2 Git workflow
  22. nguyentien98 created this gist Apr 19, 2018.
    138 changes: 138 additions & 0 deletions Nguyen_Van_Tien_git_guidelines.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,138 @@
    ## 1. Git
    ![Git](/images/branching.png)
    <a name="some-git-rules"></a>

    ### 1.1 Some Git rules
    There are a set of rules to keep in mind:
    * Perform work in a feature branch.

    _Why:_
    >Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. [read more...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
    * Branch out from `develop`

    _Why:_
    >This way, you can make sure that code in master will almost always build without problems, and can be mostly used directly for releases (this might be overkill for some projects).
    * Never push into `develop` or `master` branch. Make a Pull Request.

    _Why:_
    > It notifies team members that they have completed a feature. It also enables easy peer-review of the code and dedicates forum for discussing the proposed feature.
    * Update your local `develop` branch and do an interactive rebase before pushing your feature and making a Pull Request.

    _Why:_
    > Rebasing will merge in the requested branch (`master` or `develop`) and apply the commits that you have made locally to the top of the history without creating a merge commit (assuming there were no conflicts). Resulting in a nice and clean history. [read more ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
    * Resolve potential conflicts while rebasing and before making a Pull Request.
    * Delete local and remote feature branches after merging.

    _Why:_
    > It will clutter up your list of branches with dead branches. It ensures you only ever merge the branch back into (`master` or `develop`) once. Feature branches should only exist while the work is still in progress.
    * Before making a Pull Request, make sure your feature branch builds successfully and passes all tests (including code style checks).

    _Why:_
    > You are about to add your code to a stable branch. If your feature-branch tests fail, there is a high chance that your destination branch build will fail too. 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.
    * Use [this](./.gitignore) `.gitignore` file.

    _Why:_
    > It already has a list of system files that should not be sent with your code into a remote repository. In addition, it excludes setting folders and files for most used editors, as well as most common dependency folders.
    * Protect your `develop` and `master` branch.

    _Why:_
    > It protects your production-ready branches from receiving unexpected and irreversible changes. read more... [Github](https://help.github.com/articles/about-protected-branches/), [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html) and [GitLab](https://docs.gitlab.com/ee/user/project/protected_branches.html)
    <a name="git-workflow"></a>
    ### 1.2 Git workflow
    Because of most of the reasons above, we use [Feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) with [Interactive Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) and some elements of [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) (naming and having a develop branch). The main steps are as follows:

    * For a new project, initialize a git repository in the project directory. __For subsequent features/changes this step should be ignored__.
    ```sh
    cd <project directory>
    git init
    ```

    * Checkout a new feature/bug-fix branch.
    ```sh
    git checkout -b <branchname>
    ```
    * Make Changes.
    ```sh
    git add
    git commit -a
    ```
    _Why:_
    > `git commit -a` will start an editor which lets you separate the subject from the body. Read more about it in *section 1.3*.

    * Sync with remote to get changes you’ve missed.
    ```sh
    git checkout develop
    git pull
    ```

    _Why:_
    > This will give you a chance to deal with conflicts on your machine while rebasing (later) rather than creating a Pull Request that contains conflicts.

    * Update your feature branch with latest changes from develop by interactive rebase.
    ```sh
    git checkout <branchname>
    git rebase -i --autosquash develop
    ```

    _Why:_
    > You can use --autosquash to squash all your commits to a single commit. Nobody wants many commits for a single feature in develop branch. [read more...](https://robots.thoughtbot.com/autosquashing-git-commits)

    * If you don’t have conflicts, skip this step. If you have conflicts, [resolve them](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/) and continue rebase.
    ```sh
    git add <file1> <file2> ...
    git rebase --continue
    ```
    * Push your branch. Rebase will change history, so you'll have to use `-f` to force changes into the remote branch. If someone else is working on your branch, use the less destructive `--force-with-lease`.
    ```sh
    git push -f
    ```
    _Why:_
    > When you do a rebase, you are changing the history on your feature branch. As a result, Git will reject normal `git push`. Instead, you'll need to use the -f or --force flag. [read more...](https://developer.atlassian.com/blog/2015/04/force-with-lease/)


    * Make a Pull Request.
    * Pull request will be accepted, merged and close by a reviewer.
    * Remove your local feature branch if you're done.
    ```sh
    git branch -d <branchname>
    ```
    to remove all branches which are no longer on remote
    ```sh
    git fetch -p && for branch in `git branch -vv --no-color | grep ': gone]' | awk '{print $1}'`; do git branch -D $branch; done
    ```
    <a name="writing-good-commit-messages"></a>
    ### 1.3 Writing good commit messages
    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](https://chris.beams.io/posts/git-commit/#seven-rules)):
    * Separate the subject from the body with a newline between the two.
    _Why:_
    > Git is smart enough to distinguish the first line of your commit message as your summary. In fact, if you try git shortlog, instead of git log, you will see a long list of commit messages, consisting of the id of the commit, and the summary only.
    * Limit the subject line to 50 characters and Wrap the body at 72 characters.
    _why_
    > Commits should be as fine-grained and focused as possible, it is not the place to be verbose. [read more...](https://medium.com/@preslavrachev/what-s-with-the-50-72-rule-8a906f61f09c)
    * Capitalize the subject line.
    * Do not end the subject line with a period.
    * Use [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) in the subject line.
    _Why:_
    > Rather than writing messages that say what a committer has done. It's better to consider these messages as the instructions for what is going to be done after the commit is applied on the repository. [read more...](https://news.ycombinator.com/item?id=2079612)


    * Use the body to explain **what** and **why** as opposed to **how**.

    <a name="documentation"></a>