Git không có gì đáng sợ cả!

Trong bài viết này mình muốn chia sẻ một ít kinh nghiệm về những vấn đề gặp phải khi thao tác với GIT Bắt đầu thôi nào (go) !!

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:

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:

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.

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.

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, kết quả cuối cùng là vừa được đấm thằng bạn, vừa bá git.

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 c1664c2hoặ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_name. git 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_name. git 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

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 -frồ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 =))

• 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

• 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

Techtalk via Viblo