logo

Thông báo

Icon
Error

Chia sẻ
Tùy chọn
Xem
Xem bài viết cuối
Offline admin  
#1 Đã gửi : 09/03/2015 lúc 10:38:18(UTC)
admin

Danh hiệu: Administration

Chức danh:

Nhóm: Administrators
Gia nhập: 23-07-2013(UTC)
Bài viết: 6,102
Man
Viet Nam
Đến từ: Vietnam

Cảm ơn: 10 lần
Được cảm ơn: 2 lần trong 2 bài viết

Làm sao để sử dụng git hiệu quả trong một dự án phần mềm

Awesome Git Branching Model

Awesome Git Branching Model

Why Git?

Mình đã từng sử dụng qua một vài hệ thống quản lý source như SVN hay Hg. Thì mình vẫn thích dùng Git hơn. Nó có rất nhiều điểm hay như phân tán, không cần kết nối với Central Repository khi commit…

Git đã thay đổi cách nghĩ của lập trình viên về merging và branching. Nó làm cho những công việc đó nhẹ nhàng, dễ chịu và đơn giản hơn rất nhiều. Trong các sách về SVN/CVS, thường thì merging và branching sẽ được giới thiệu vào các chương cuối. Tức là dành cho cho những người dùng nâng cao. Riêng với Git thì nó được giới thiệu vào khá sớm, vì đó chính là điểm mạnh của Git. Các bạn sẽ không sợ những công việc dễ gây conflict này nữa. Nó được giới thiệu ở Chương 3 của cuốn Pro Git

Các bạn có thể tham khảo thêm những điểm mạnh và yếu của Git tại hai địa chỉ dưới:

http://git-scm.com/about

https://git.wiki.kernel.org/index.php/GitSvnComparsion

Bây giờ chúng ta sẽ đi qua phần tiếp theo của câu chuyện, giới thiệu về Git Developing Modelmình thường hay sử dụng. Mình nghĩ nó là cách thú vị và hay để mọi team có thể áp dụng để quản lý quá trình phát triển phần mềm của team mình.

Decentralized but centralized

Khi các bạn làm việc với git, thường thì các bạn sẽ làm việc với một Git Server như GitHub, Bitbucket, Google Code hay tự setup một Git server (Công ty mình sử dụng Gitlab). Về bản chất của Git. Đây không được xem là một server, vì nó ngang cấp với local repository trên máy tính của bạn. Mình thì thích dùng cụm từCentral Truth Repository hơn. từ central ở đây là một ý niệm ngầm định vì Git là hệ thống quảnphân tán. Và đây cũng là Git Repo chứa branch origin. Một cái tên quen thuộc mọi người dùng Git.

Mô hình Central Truth Repository

hình Central Truth Repository

Mọi lập trình viên đều pullpush lên origin. Nhưng bên cạnh việc những lập trình viên trong cùng 1 team có thể pull những thay đổi với nhau trong cùng một subteam. Điều này khá hữu ích cho những team làm việc với nhau để cùng phát triển một vài tính năng lớn, và trước khi push bản code hoàn chỉnh lên server, họ có thể làm việc chung với nhaukhông cần đến central repository. Việc này rất đơn giản là bạn chỉ cần add remote trỏ đến những repository của đồng nghiệp.

The main branches

Mình đã từng làm trong một project mà chỉ sử dụng một branch duy nhất là master. Điều này là không sai nhưng nó gây ra khá nhiều phiền toái. Và hệ thống CI rất hay báo build failed.

Central Repo chỉ cần chứa 2 branch duy nhất trong suốt quá trình phát triển dự án là

  • master

  • develop

Master branch thì dĩ nhiên quen thuộc với những Git user rồi. Nó là branch chứa code stable. Source code ở HEAD commit luôn ở trạng thái production-ready.

Develop branch là branch chứa code ở trạng thái sẳn sàng cho bản phát hành tiếp theo. Nó thường hay được gọi là “integration branch”. Các Nightly Build (Daily Build) thường được build từ branch này.

Một khi source code ở develop branch đạt đến trạng thái stable (Ít nhất là vượt qua được các Unit test case) thì mọi thay đổi trên develop branch sẽ được merge vào master branch và tagged với một release number.

Bằng cách kết hợp với các hệ thống CI hoặc git hook. Bạn hoàn toàn có thể tự động hóa mọi công việc build và release. Ví dụ sau (Mình viết bằng mã giả)

Tương tự với Develop branch. Mỗi bản build thành công sẽ được đẩy lên server chứa Nightly Build

Supporting branches

bm002Bên cạnh sử dụng hai branch chính là master và develop thì nên có thêm những supporting branch chạy song song với 2 branch chính trong quá trình phát triển phần mềm. Mục đích của việc này nhằm giúp các developer team dễ dàng quản lý các tính năng, dễ dàng chuẩn bị cho các bản phát hành hoặc có thể nhanh chóng fix hệ thống nếu có những lỗi trong quá trình phát triển.

Không giống như 2 branch master và develop. Các branch này không chạy xuyên suốt dự án. Mà nó sẽ được mở và đóng khi cần thiết.

Có ba nhóm branchs mà các bạn nên sử dụng bao gồm

  • Feature branches
  • Release branches
  • Hotfix branches

Mỗi nhóm, theo như tên gọi của nó sẽ có những chức năng khác nhau tùy theo quy định của team mà sẽ được mở, đóng và merage vào những thời điểm thích hợp.

Về bản chất thì các branch này cũng là các branch Git đơn thuần, nhưng tùy vào mục đích sử dụng mà nó được đặt tên như vậy.

Feature branches

Thường được tách branch từ branch chính là developVà khi hoàn thành thì nên merge nó vào develop

Cách đặt tên: mọi cái tên ngoại trừ master, develop, release-*, or hotfix-*

Nên đặt là: feature-*

Feature branch thường được dùng cho quá trình phát triển một tính năng, chức năng của phần mềm. Nó thường được mở cho một hoặc một nhóm lập trình viên cùng nhau phát triển một tính năng mới.

Mục tiêu của branch này là sống trong quá trình phát triển feature đó để rồi cuối cùng sẽ được merge vào develop branch nếu tình năng đó hoàn thành hoặc sẽ bị hủy bỏ nếu tính năng đó quá tệ.

Một feature branch sẽ được đóng và merge vào develop branch. Không được merge vào master branch

Tạo ra một feature branch

Khi tạo ra một branch. Nó sẽ được tách brach từ develop branch

Hoàn thành một feature branch trong quá trình development

Khi một feature hoàn thành, nó sẽ được merge vào develop branch để sẳn sàng cho quá trình phát hành ở phiên bản tiếp theo.

Khi sử dụng cờ —no-ff thì git sẽ tạo ra một Merge commit point. Còn nếu không thì nó sẽ tạo ra một fast-forward. Sử dụng merge commit sẽ tốt hơn là fast-foward vì nó sẽ giúp bạn không bị mất dấu các commit của một feature branch, và theo dõi được quá trình phát triển của một feature branch hoặc nhầm lẫn các commit có trên develop branch. Giúp các thành viên trong team dễ dàng làm việc với nhau hơn.

merge-without-ffSau này, khi bạn cần review lại quá trình commit của dự án, bạn sẽ thấy được lịch sử các commit rất dễ dàng, thấy được nhữngmình đã làm hơn là việc phải đi lần lại các commit, xem lại các commit mesgage. Giúp cho nhóm trưởng và các lập trình viên không bị đau đầu khi cần rollback hay reset code. Rất đơn giản, chỉ cần sử dụng cờ —no-ff. Dù nó có thể tạo ra một vài empty commit. Nhưng bạn sẽ nhận lại được nhiều lợi ích hơn là fast-foward commit.

Release branches

May branch off from: develop

Must merge back into: develop and master

Branch naming convention: release-*

Release branches giúp cho quá trình chuẩn bị để phát hành một phiên bản mới dễ dàng hơn. Nó cho phép bạn sửa các lỗi nhỏ của phần mềm, thay đổi các version number, build date hay các config nhỏ của ứng dụng cho lần phát triển tới. Việc này làm cho develop branch trông sạch sẽ, gọn gàng và bạn sẽ dễ dàng hiểu những gì mà team mình đã làm.

Tại sao release branch được tách ra từ develop branch và merge vào master hay develop.

Mục tiêu của việc này giúp cho hai công việc và phát triển chức năng và chuẩn bị release có thể được thực hiện bởi hai lập trình viên khác nhau và song song với nhau. Bạn có thể chuẩn bị để release và chờ cho các features khác hoàn thiện. Hoặc là team của bạn đã chuẩn bị xong cho quá trình release rồi nhưng vẫn chưa đến thời gian phát hành thì có thể merge vào develop branch và chờ đến thời điểm thích hợp thì có thể merge vào master branch.

Creating a release branch

Tương tự như việc mở ra một feature branch. Khi mà một phiên bản ở develop branch đã đạt đến trạng thái sẵn sàng phát hành bạn có thể tách ra một release branch để chuẩn bị cho quá trình phát hành.

Theo ví dụ trên, bằng cách tạo ra một release branch và chạy script cho quá trình chuẩn bị.

Sự tồn tại của một releash branch thường rất ngắn. và nó sẽ được đóng khi phiên bản đó được phát hành ra. Trong quá trình nó tồn tại. Bạn có thể fix bug ở trên branch này, nhưng không được thêm các chức năng lớn trên branch này.

Finishing a release branch

Khi một release branch sẵn sàng. Nó cần được merge vào master để phát hành. Và bạn cần nhớ là mọi commit trên master branch nên là những bản phát hành. Nó sẽ làm bạn dễ dàng theo dõi quá trình phát triển hơn. Cuối cùng mọi thay đổi trên release branch và master branch cần được merage vào develop branch để đồng bộ code cho pharse kế tiếp.

Nên tagging cho code để dễ tracking quá trình phát triển.

Sau đó thì các bạn merge vào develop

Nếu có conflic thì các bạn có thể fix rồi commit.

Và cuối cùng là xóa releash branch đi.

Hotfix branches

hotfix-branches1May branch off from: master

Must merge back into: develop and master

Branch naming convention: hotfix-*

Hotfix rất giống với release branches. vì nó đều nằm trong quá trình chuẩn bị phát hành nhưng để sửa những lỗi không nằm trong kế hoạch. Khi một lỗi của ứng dụng được phát hiện và cần phải sửa ngay, Hotfix sẽ giúp điểu này dễ dàng hơn. Một hotfix branch sẽ được tách ra từ một commit mang version tag trên master branch. Hotfix củng giúp cho việc tương tác công việc giữa các thành viên trong team dễ dàng hơn vì lúc đó một developer sẽ thực hiện công việc fix bug trên hotfix branch trong khi mọi thành viên khác trong team thì phát triển các tính năng cho bản kế tiếp ở develop branch.

Creating the hotfix branch

Hotfix branch được tạo ra từ master branch, ví dụ như bản 1.2 đang là phiên bản hiện tại, và phát hiện ra có một vào bug. Trong lúc đó bản trên develop branch vẫn chưa hoàn thành. Thì chúng ta có thể tách một hotfix branch và bắt đầu quá trình sửa lỗi.

Đừng quên thay đổi version number

Sau đó commit các thay đổi.

Finishing a hotfix branch

Khi hoàn thành những sửa lỗi cần thiết. Hotfix branch cần được merge vào master, và cũng cần được merge vào develop branch để đảm bảo rằng những bugfix này cũng sẽ có trong bản phát hành kế tiếp.

Sau đó

Có một trường hợp ngoại lệ cho quá trình này là nếu như khi hoàn thành một bugfix release và đang tồn tại một release branch thì hotfix release cần được merge vào release branch. Vì release branch cũng sẽ được merge vào master và develop.

Cuối dùng là xóa hotfix branch đó đi:

Tổng kết

Có lẽ qua bài viết này các bạn sẽ nhận thấy rằng việc sử dụng một công cụ hiệu quả như Git theo một cách hiệu quả hơn sẽ mang lại năng suất cho công việc. Mình biết một tool hổ trợ rất tốt developing model này là SmartGit. Sẽ giới thiệu nó kỹ hơn ở một bài viết khác.

Bài viết được tham khảo từ: http://nvie.com/posts/a-...ful-git-branching-model/

Bài viết giới thiệu Git-Flow trên SmartGit: http://www.syntevo.com/smartgithg/whatsnew

Offline admin  
#2 Đã gửi : 23/01/2018 lúc 11:00:15(UTC)
admin

Danh hiệu: Administration

Chức danh:

Nhóm: Administrators
Gia nhập: 23-07-2013(UTC)
Bài viết: 6,102
Man
Viet Nam
Đến từ: Vietnam

Cảm ơn: 10 lần
Được cảm ơn: 2 lần trong 2 bài viết

Lỗi mất code

Vấn đề gặp phải (TT)

Nhiều bạn có thể gặp trường hợp khi dùng một số thao tác với git như 

git reset,.... git gì gì đó

làm cho mất commit ở nhánh hiện tại.

Ví dụ như trong trường hợp này :

Mình mới commit xong, git log --oneline sẽ ra như thế này:

Commit đã đủ, chuẩn bị nộp bài thôi

Nhưng sau khi đi vệ sinh một chút thì có thằng bạn nghịch dại và khi git log --oneline lại thì nó như thế này:

Bị troll rồi

Việc đầu tiên mình làm cho thằng bạn đó một trận rồi mở các bí kíp về git ra xem có khôi phục lại được code không?? (TT)

Sau khi tìm hiểu thì mình đã biết được, một khi đã commit rồi thì sẽ không bị mất code nữa

Khi commit thì github sẽ lưu lại commit, kể cả khi xóa nhánh chứa commit đó thì cũng không bị mất (Đây là một câu hỏi trong phỏng vẫn đó, bạn nào chưa biết thì lưu lại nhé, ắt sẽ có lúc dùng =)))

Bạn có thể tưởng tượng là commit giống như những gói tin, còn branch có nhiệm vụ xâu chuỗi các gói tin đó theo một trật tự nhất định

Xử lý thôi !!

Đầu tiên, hãy xem lịch sử thay đổi github local của bạn bằng git reflog hoặc git reflog | grep some_thing, phần some_thing sẽ là những gì liên quan đến commit mà bạn muốn xem ví dụ như mã ticket.

Đây là lịch sử thay đổi commit

Copy phần commit_hash(mã commit) bạn muốn quay trở lại; trong trường hợp này là mã abe794a có commit Fixed #013.

Trong trường hợp này là mã abe794a của commit fix bug #013

Cuối cùng kết liễu bằng lệnh git reset --hard commit_hash, sử dụng git log --oneline để kiểm tra kết quả nhé.git reset --hard abe794a

Tèn tén ten, vừa được đấm thằng bạn, vừa bá git =))

Tèn tén ten, kết quả cuối cùng là vừa được đấm thằng bạn, vừa bá git =))

Chuyển nhánh base

Vấn đề gặp phải (TT)

Bạn đã bao giờ gặp trường hợp ticket của mình đang trong phiên bản ví dụ như tháng 12, nhưng do spec của khách hàng thay đổi nên đấy sang version tháng 1,....

Và khi base với nhánh tháng 1 thì có chuyện xảy ra (TT).

Khi base với nhánh branch_122017

Khi base với nhánh branch_012018

Do có quá nhiều commit không trùng nhau nên (TT)

Sơ đồ mô tả:

Xử lý thôi !!

Tư tưởng của việc này là chuyển commit của bạn sang base với một nhánh mới.

Thật ra số commit bị conflict kia phần lớn là của 2 nhánh base bị conflict với nhau; việc cần làm bây giờ là chuyển commit của bạn lên trên cùng của nhánh base mới

Trong trường hợp này, mình có 2 cách giải quyết.

Nhưng trước hết, bạn phải lưu lại commit_hash cần chèn vào đã đã, nó là 9e05cab

Cách 1: Sử dụng branch hiện tại

  • Tại branch hiện tại, mình reset --hard về commit cũ cũ từ ngày trước, commit này là commit chung của cả 2 nhánh mà bạn muốn thay đổi. Nhìn trên hình đó là commit c1664c2 hoặc có thể cũ hơn . git reset --hard c1664c2

  • Sử dụng rebase như bình thường, lúc này nhánh của bạn đã chuyển base từ branch tháng 12 sang tháng 1 rồi. Vì checkout về commit chung nên sẽ không bị conflict về code giữa hai 2 nhánh. git rebase branch_0118

  • Tiếp theo bạn sử dụng lệnh cherry-pick commit_hash để lấy commit đó. git cherry-pick 9e05cab

  • git log --oneline xem

  • Cuối cùng, bạn push -f lại lên github là OK

Cách 2: Sử dụng nhánh mới trùng tên

  • Xóa nhánh có commit hiện tại đi. git branch -D branch_namegit branch -D fix_021

  • Bạn checkout về nhánh muốn base (branch_012018), tạo một nhánh mới trùng tên với branch vừa xóa. git checkout -b branch_namegit checkout -b fix_021

  • Sử dụng cherry-pick như cách 1 cherry-pick commit_hash. git cherry-pick 9e05cab

  • Kiểm tra bằng git log --oneline

  • Cuối cùng, bạn push -f lên là lại OK ngay

Tổng hợp commit

Vấn đề gặp phải (TT)

Bạn lại có khi nào gặp trường hợp khi pull của mình có nhiều hơn 1 commit, mà đại ca leader yêu cầu chỉ được 1 pull 1 commit (TT), vào lúc đó "người nông dân" biết phải làm sao ???

git log --oneline

Xử lý thôi !!

Sau khi ôn luyện vài khóa mastering GIT (len) thì có 2 cách để giải quyết

Cách 1: Sử dụng rebase -i

Đầu tiên, sử dụng git rebase -i HEAD~n cũng với n là số commit bạn muốn tổng hợp, trong trương hợp này n = 3.

Sau đó đổi pick thành s với s là squash:

Sau khi save lại sẽ hiển thị cửa sổ tên commit

Tiếp theo bạn chỉ việc thêm dấu # vào trước commit bạn không muốn giữ tên, save lại

Kiểm tra lại bằng git log --oneline

push -f rồi kiểm tra lại trên github

Very ez =))

Cách 2: Sử dụng reset

Sử dụng git reset --soft HEAD~n với n là số commit bạn muốn tổng hợp (n = 3), kiểm tra lại bằng git log --oneline

Kiểm tra trạng thái git status, file thay đổi đã nằm trong staging

Sau đó bạn chỉ việc git commit -m "commit name" lại là được. Commit này là commit mới của branch, không liên quan gì đến các commit trước

Kiểm tra bằng git log --oneline tiếp nào

Dùng push -f rồi kiểm tra trên github thi sao ??

BÁ RỒI (y)

Nhìn 2 cách trên thì bạn có thể thấy là cách nào nhanh hơn rồi đấy, mình thì minh chọn cách 1 =))

Một số câu lệnh thông dụng khác

  • commit --amend: nạp chồng commit sau lên commit trước (Dùng để đổi tên commit)
  • git stash: lưu việc đang làm vào 1 stash, khi cần lấy ra dùng lệnh git stash pop
  • git diff: kiểm tra sự thay đổi so với commit trước (kiểm tra khi chưa commit)
  • git show: kiểm tra sư thay đổi so với commit trước (kiểm tra sau khi commit mới)
  • git checkout -f: loại bỏ các file đã thay đổi, giống như git stash nhưng sẽ không lưu vào đâu
  • git blame file_name: kiểm tra người cuối cùng đã thay đổi trong file theo từng dòng
  • git config --list: kiểm tra thông tin local của người dùng

    có thể tham khảo thêm ở Đến cả con khỉ cũng biết GIT

Một số lưu ý khi sử dụng GIT

  • Nên bắt đầu làm việc bằng việc pull code mới ở nhánh tổng, và rebase ở nhánh checkout để không bị conflict code
  • Nên làm một pull với một commit: Ý mình là trước khi được merge pull. Vì có project sẽ yêu cầu bạn mỗi lần đẩy lại pull phải một commit mới để theo dõi được sự thay đổi của commit trước và commit sau của bạn. Khi pull đã được appprove thì bạn có hãy sử dụng 2 cách tổng hợp commit trên của mình để trở thành 1 pull nhé
  • Gợi ý cách đặt tên commit: Nên bắt đầu với các tiền tố chỉ chức năng của pull đó, giống như là pull fix bug thì nên đặt tên bắt đầu là Bug...Fixed ... hoặc làm tính năng mới thì Task ...Feature...; còn tiếp theo là mã ticket, cuối cùng là nội dung chỉnh sửa -> Giúp quản lý pull về sau dễ dàng hơn khi sử dụng git log --oneline sẽ theo dõi được sự thay đổi cũng như nội dung thay đổi

Lời kết

Bên trên là một số thao tác cơ bản về GIT mà mình đã luyện được, nếu các bạn thấy có sai sót hay có đóng góp thì cứ comment ở dưới giúp mình sửa nha. Thanks for reading (bâu)

Tham khảo

https://backlog.com/git-tutorial/vn/reference/

https://viblo.asia/p/git-khong-co-gi-dang-so-yMnKMgMQl7P

Ai đang xem chủ đề này?
OceanSpiders 2.0
Chủ đề tương tự
Kiến trúc và cách làm việc với docker (Docker)
Bởi admin 28-10-2019 lúc 11:32:25(UTC)
Những vật dụng hút tài lộc trên bàn làm việc (Phong thủy)
Bởi Ellry 11-09-2019 lúc 07:35:11(UTC)
Làm việc thiện cần đúng cách (Kỹ năng giao tiếp)
Bởi Ellry 27-04-2019 lúc 09:46:28(UTC)
Tác hại khi làm việc nhiều trước máy tính và cách phòng tránh (Sức khỏe, y tế và đời sống)
Bởi Ellry 19-02-2019 lúc 08:36:19(UTC)
Bị sa thải vì làm việc quá hiệu quả (Truyện cười công sở)
Bởi admin 20-12-2018 lúc 01:40:50(UTC)
Lí do nên có 1 chậu cây cảnh trên bàn làm việc (Hoa lá - Cây Cảnh)
Bởi Ellry 17-12-2018 lúc 11:08:58(UTC)
100 nơi làm việc tốt nhất Việt Nam năm 2017 (Thị trường tài chính)
Bởi admin 23-11-2018 lúc 12:23:55(UTC)
Bảo vệ mắt khi làm việc nhiều trước máy tính (Các mẹo vặt hay)
Bởi Ellry 29-10-2018 lúc 10:33:55(UTC)
Để luôn tỉnh táo làm việc cả ngày (Các mẹo vặt hay)
Bởi Ellry 27-09-2018 lúc 09:02:15(UTC)
Lấy lại tinh thần làm việc sau kỳ nghỉ lễ (Cảm nhận & trải nghiệm)
Bởi Ellry 03-09-2018 lúc 06:27:18(UTC)
Làm sao vừa chuẩn bị đám cưới vừa làm việc hiệu quả? (Kế hoạch chuẩn bị cho đám cưới)
Bởi Ellry 20-08-2018 lúc 10:15:16(UTC)
Những thực phẩm giàu năng lượng cho ngày làm việc hiệu quả (Thực phẩm)
Bởi Ellry 17-07-2018 lúc 09:54:30(UTC)
Bận đến mấy, cô dâu cũng nên làm việc này trước khi thay áo cưới (Dịch vụ cưới)
Bởi Ellry 02-07-2018 lúc 10:23:29(UTC)
Những loại trà giúp cơ thể tỉnh táo, làm việc hiệu quả (Thực phẩm dinh dưỡng)
Bởi Ellry 08-06-2018 lúc 11:09:27(UTC)
Dạy trẻ tự giác làm việc (Giáo dục trẻ nhỏ)
Bởi Ellry 04-06-2018 lúc 03:04:18(UTC)
Di chuyển  
Bạn không thể tạo chủ đề mới trong diễn đàn này.
Bạn không thể trả lời chủ đề trong diễn đàn này.
Bạn không thể xóa bài của bạn trong diễn đàn này.
Bạn không thể sửa bài của bạn trong diễn đàn này.
Bạn không thể tạo bình chọn trong diễn đàn này.
Bạn không thể bỏ phiếu bình chọn trong diễn đàn này.

| Cung cấp bởi YAF.NET 2.2.4.14 | YAF.NET © 2003-2019, Yet Another Forum.NET
Thời gian xử lý trang này hết 6.637 giây.