git.doc

Feature branches(topic branches)
    Tách từ: develop
    Merge vào: develop
    Naming convention: tự do, ngoại trừ master, develop, release-*, hotfix-*
Feature branches (hay còn gọi là topic branches) được sử dụng để phát triển các feature mới phục vụ cho release sau này. Khi bắt đầu phát triển một chức năng, có thể chưa rõ được thời điểm chức năng đó được tích hợp vào hệ thống và release. Feature branch sẽ tồn tại trong quá trình chức năng được phát triển, cuối cùng sẽ được merge lại vào develop (khi quyết định lần release tới bao gồm chức năng đó) hoặc bị bỏ đi (khi thấy chức năng không còn cần thiết).
Về cơ bản thì feature branches chỉ tồn tại ở repos của developers, chứ ko phải ở origin.
Tạo feature branch
$ git checkout -b myfeature develop
Merge vào develop
$ git checkout develop
$ git merge --no--ff myfeature
$ git branch -d myfeature
$ git push origin develop
--no-ff giúp thao tác merge luôn tạo ra một commit mới, ngay cả khi có thể merge theo fast-forward. Flag này giúp chúng ta không bị mất thông tin liên quan đến lịch sử các commits của feature branch.

Release branches
    Tách từ: develop
    Merge vào: develop và master
    Naming convention: release-*
Release branches được sử dụng để chuẩn bị cho release bản production mới. Tất cả các công việc cuối cùng trước khi release sẽ được thực hiện ở đây, ngoài ra còn để fix nốt các bugs lẻ tẻ, chuẩn bị meta-data (version number, build dates, etc..). Nhờ việc tách nhánh ra khỏi develop, chúng ta có thể tiếp tục phát triển các features cho đợt release khác một cách bình thường.
Thời điểm được lựa chọn để tách nhánh từ develop là khi develop phản ánh được trạng thái mong muốn cho việc release mới. Ít nhất lúc đó tất cả các features dành cho đợt release phải được merge vào develop rồi. Những features nhắm đến các lần release sau thì chưa được merge vào, phải đợi sau khi tách nhánh.
Chúng ta sẽ tiến hành đánh version theo rule của dự án ngay sau khi tạo release branch.
Tạo release branch
$ git checkout -b release-1.2 develop
$ ./bump-version.sh 1.2
$ git commit -a -m "Bumped version number to 1.2"
Ở ví dụ trên, bump-version.sh tượng trưng cho một script thay đổi một vài files trong source code để phản ánh version mới. Sau khi tạo branch mới và chuyển sang branch đó, chúng ta sẽ thực hiện nâng version, rồi commit thao tác đó.
Branch mới này sẽ tồn tại cho đến khi việc release được thực hiện gọn ghẽ. Trong khoảng thời gian đó, có thể thực hiện fix bugs ở branch này, tuy nhiên nghiêm cấm việc bổ sung feature mới lên đó. Tốt nhất nếu có features mới thì hãy merge vào develop, và đợi đợt release sau.
Kết thúc release branch
Khi source code trên release branch sẵn sàng để release, đầu tiên, phải merge vào master, sau đó phải đc merge lại vào develop để những lần release sau cũng chứa những thay đổi ở lần này.
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
Vậy là source code đã được release lên master, và đã được tag để tiện sau này tham chiếu.
$ git checkout develop
$ git merge --no-ff release-1.2
Ở bước này, rất có thể sẽ có confict, nên hãy fix nó rồi commit nhé.
Bây giờ thì việc release đã hoàn thành, và chúng ta ko cần đến branch này nữa.
$ git branch -d release-1.2

Hotfix branches
    Tách từ: master
    Merge vào: develop và master
    Naming convention: hotfix-*
Hotfix branches cũng giống release branches ở chỗ được sử dụng để chuẩn bị cho việc release production mới, chỉ khác ở chỗ là ko có plan từ trước. Khi có một bug nghiêm trọng trên bản production cần được giải quyết ngay lập tức, một hotfix branch sẽ được tách ra từ master và được đánh version để nhận biết.
Ưu điểm của việc tách nhánh này ở chỗ các team members khác có thể tiếp tục công việc ở develop trong khi những người khác có thể tập trung vào fix bug của production.
Tạo hotfix branch
Hotfix branch được tạo ra từ master. Ví dụ hiện tại version 1.2 là phiên bản production đang chạy và xuất hiện lỗi nghiêm trọng. Tuy nhiên source code trên develop vẫn chưa ổn định, vì thế chúng ta phải tách nhánh hotfix và tiến hành sửa lỗi.
$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh 1.2.1
$ git commit -a -m "Bumped version number to 1.2.1"
Sau khi tách nhánh phải tiến hành up version luôn nhé!
Sau khi sửa lỗi, hãy thực hiện commit.
$ git commit -m "Fixed severe production problem"
Kết thúc hotfix branch
Sau khi kết thúc sửa lỗi, những thay đổi phải được merge lại master, đồng thời cũng phải merge vào develop để ngăn lỗi xảy ra ở những lần release sau. Nghe rất giống với xử lý trên release branch phải không.
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
Tuy nhiên, có một điểm cần lưu ý rằng: khi đang tồn tại một release branch thì cần phải merge hotfix vào release branch đó, thay cho develop. Khi release branch được merge vào develop thì cuối cùng những thay đổi trong hotfix cũng được merge vào develop, nên không có vấn đề gì cả. Trừ khi thực sự công việc ở develop cần phần hotfix ngay lập tức và ko thể đợi release branch được merge, thì cần cẩn thận merge hotfix vào develop.
Cuối cùng, chúng ta cũng ko cần đến branch này nữa:
$ git branch -d hotfix-1.2.1


#################################
# Delete remote branch
git push origin :<branchName>

merge 2 commit into one : 
git reset --soft "HEAD^"
git commit --amend
You can merge as many commits as you want, 
as long as they are the last X commits, and not somewhere in the middle. 
Just run git reset --soft HEAD~10, 
where 10 is the number of commits you want to merge.

Stop tracking and ignore changes to a file in Git
git update-index --assume-unchanged [path]

This is a two step process:

Remove tracking of file/folder - but keep them on disk - using
git rm --cached 
Now they do not show up as "changed" but still show as
    untracked files in  git status -u  
Add them to .gitignore


### Sử dụng git cherry-pick
Hôm nay mình gặp phải một trường hợp cần apply cùng một thay đổi cho cả 2 branches khác nhau trong project.
Giả sử bạn có 2 branches khác nhau cho 2 khách hàng khác nhau, tạm gọi là branch A và branch B. Và bạn đang fix một bug nghiêm trọng cùng tồn tại trên hệ thống của cả 2 khách hàng, bạn muốn chỉ commit một lần nhưng có thể apply vào luôn cả 2 branches.
Bạn có thể dùng lệnh cherry-pick của Git để giải quyết, như sau:
// Đang ở branch A, commit những thay đổi đó
git add -A
git commit -m "Awesome Bug Fixed :("
// Chuyển qua branch B và thực hiện lệnh cherry-pick 
git checkout B
git cherry-pick A
cherry-pick sẽ lấy commit cuối cùng ở branch A merge vào branch B.
Ngoài ra, bạn còn có thể chỉ định danh sách các commit cần "bốc" từ A để "bỏ" vào B nếu cần thiết.
Xem thêm thông tin về cherry-pick tại đây



Checking out pull requests locally
https://help.github.com/articles/checking-out-pull-requests-locally/
Fetch the reference to the pull request based on its ID number, creating a new branch in the process.

git fetch origin pull/ID/head:BRANCHNAME
Switch to the new branch that's based on this pull request:

[master] $ git checkout BRANCHNAME
Switched to a new branch 'BRANCHNAME'
At this point, you can do anything you want with this branch. You can run some local tests, or merge other branches into it, including master. Make modifications as you see fit!

When you're ready, you can push the new branch up:

[pull-inactive-pull-request] $ git push origin BRANCHNAME
Counting objects: 32, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (29/29), 74.94 KiB | 0 bytes/s, done.
Total 29 (delta 8), reused 0 (delta 0)
To https://github.com/username/repository.git
 * [new branch]      BRANCHNAME -> BRANCHNAME
Create a new pull request with your new branch.