Cập nhật thông tin chi tiết về “Git Remote Add …” Và “Git Push Origin Master” Là Gì? mới nhất trên website Tvzoneplus.com. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất.
Rất thường xuyên, Git và Rails trông giống như ma thuật … chẳng hạn như trong chương đầu tiên của cuốn sách Hướng dẫn Rails 3 , nó nói về Git:
git remote add Origin [email protected]:peter/first_app.git git Push Origin mastervà khá nhiều người nói rằng “nó chỉ hoạt động” mà không nói quá nhiều về những gì họ đang có và bắt đầu nói về việc phân nhánh. Tìm kiếm trên mạng cho thấy git remote add là để thêm một “tên ngắn”, chẳng hạn như Origin, và nó cũng có thể là bất kỳ tên nào, giống như một bí danh cho một URL. Và Origin là đường dẫn thông thường nơi repo từ xa trỏ đến. (trong http://git-scm.com/book/en/Git-Basics-Working-with-Remotes dưới “Thêm kho lưu trữ từ xa”)
Vậy tại sao URL không phải là git://[email protected]/peter/first_app.git mà trong cú pháp khác – đó là cú pháp gì? Tại sao nó phải kết thúc bằng .git? Tôi đã cố gắng không sử dụng .git ở cuối và nó cũng hoạt động. Nếu không phải là .git, thì nó có thể là gì khác? git trong [email protected] dường như là tài khoản người dùng trên máy chủ git?
Ngoài ra, tại sao cần phải quá dài dòng để sử dụng git Push Origin master? Không thể mặc định là Origin và master? Tôi thấy rằng lần đầu tiên, Origin master là cần thiết, nhưng sau một chỉnh sửa nhỏ và cam kết, thì git Push là tất cả những gì nó cần (không cần Origin master). Ai đó có thể biết những gì đang xảy ra cho một số chi tiết?
Đôi khi, nó cảm thấy giống như rất nhiều phép thuật mà không có lời giải thích … và đôi khi người sử dụng nó rất tự tin và khi được hỏi tại sao, không thể giải thích nó, và trả lời với một cái gì đó như “đó là như vậy”. Đôi khi rất thực tế và thực dụng. Nó không phải là xấu để thực tế, nhưng có lẽ không thực tế đến mức không biết những gì đang xảy ra.
git giống như UNIX. Người dùng thân thiện nhưng kén chọn về bạn bè của nó. Nó mạnh mẽ và thân thiện với người dùng như một đường ống Shell.
Điều đó đang được nói, một khi bạn hiểu các mô hình và khái niệm của nó, nó có cùng độ rõ ràng giống như mà tôi mong đợi từ các công cụ dòng lệnh UNIX. Bạn nên cân nhắc dành thời gian nghỉ ngơi để đọc một trong nhiều hướng dẫn git tốt có sẵn trực tuyến. Cuốn sách Pro Git là một nơi tốt để bắt đầu.
Để trả lời câu hỏi đầu tiên của bạn.
git remote add ... là gì
Như bạn có thể biết, git là một hệ thống kiểm soát phiên bản phân tán. Hầu hết các hoạt động được thực hiện tại địa phương. Để giao tiếp với thế giới bên ngoài, git sử dụng cái được gọi là remotes. Đây là các kho lưu trữ khác với kho lưu trữ trên đĩa cục bộ của bạn mà bạn có thể Push thay đổi của bạn thành (để người khác có thể thấy chúng) hoặc pull từ (để bạn có thể nhận được các thay đổi khác). Lệnh git remote add Origin [email protected]:peter/first_app.git tạo một điều khiển từ xa mới gọi là Origin đặt tại [email protected]:peter/first_app.git. Khi bạn thực hiện việc này, trong các lệnh Đẩy của bạn, bạn có thể Đẩy tới Origin thay vì nhập toàn bộ URL.
git Push Origin master là gì
Đây là một lệnh có nội dung “Đẩy các xác nhận trong nhánh cục bộ có tên master vào điều khiển từ xa có tên Origin“. Khi điều này được thực thi, tất cả nội dung mà bạn đã đồng bộ hóa lần cuối với Origin sẽ được gửi đến kho lưu trữ từ xa và những người khác sẽ có thể thấy chúng ở đó.
Bây giờ về vận tải (nghĩa là git://) nghĩa là gì. URL kho lưu trữ từ xa có thể có nhiều loại ( file://, https://, v.v.). Git chỉ đơn giản dựa vào cơ chế xác thực được cung cấp bởi vận chuyển để chăm sóc các quyền và công cụ. Điều này có nghĩa là đối với các URL file://, đó sẽ là quyền của tệp UNIX, v.v. Lược đồ git:// đang yêu cầu git sử dụng giao thức truyền tải nội bộ của chính nó, được tối ưu hóa để gửi các thay đổi git xung quanh. Đối với URL chính xác, đó là vì nó là do github đã thiết lập máy chủ git của nó.
Bây giờ tính dài dòng. Lệnh bạn đã gõ là lệnh chung. Có thể nói với git một cái gì đó như “nhánh được gọi là master ở đây là gương địa phương của nhánh được gọi là foo trên điều khiển từ xa được gọi là bar“. Trong git speak, điều này có nghĩa là master track bar/foo. Khi bạn nhân bản lần đầu tiên, bạn sẽ nhận được một nhánh có tên là master và một điều khiển từ xa được gọi là Origin (nơi bạn đã nhân bản từ) với chủ địa phương được đặt để theo dõi chủ trên Origin. Khi điều này được thiết lập, bạn chỉ cần nói git Push và nó sẽ thực hiện. Lệnh dài hơn khả dụng trong trường hợp bạn cần (ví dụ: git Push có thể Đẩy đến repo công khai chính thức và git Push review master có thể được sử dụng để Đẩy đến một điều khiển từ xa riêng biệt mà nhóm của bạn sử dụng để xem lại mã). Bạn có thể đặt chi nhánh của mình thành một nhánh theo dõi bằng tùy chọn --set-upstream của lệnh git branch.
Tôi đã cảm thấy rằng git (không giống như hầu hết các ứng dụng khác mà tôi đã sử dụng) được hiểu rõ hơn từ trong ra ngoài. Khi bạn hiểu cách dữ liệu được lưu trữ và duy trì bên trong kho lưu trữ, các lệnh và những gì chúng làm sẽ trở nên rõ ràng. Tôi đồng ý với bạn rằng có một số người ưu tú trong số nhiều người dùng git nhưng tôi cũng thấy rằng với người dùng UNIX một lần, và đáng để họ vượt qua để tìm hiểu hệ thống. Chúc may mắn!
Vậy tại sao URL không phải là git:
Hai URL mà bạn đã đề cập chỉ ra rằng nên sử dụng hai giao thức truyền tải khác nhau. Bắt đầu với git:// là dành cho giao thức git, thường chỉ được sử dụng để truy cập chỉ đọc vào kho lưu trữ. Một cách khác, [email protected]:peter/first_app.git, là một trong những cách khác nhau để chỉ định quyền truy cập vào kho lưu trữ qua SSH – đây là “cú pháp kiểu scp” được mô tả trong tài liệu . Tên người dùng trong cú pháp kiểu scp là git là do cách GitHub xử lý việc xác định người dùng – về cơ bản tên người dùng đó bị bỏ qua và người dùng được xác định dựa trên cặp khóa SSH mà họ đã sử dụng để xác thực.
Đối với mức độ dài của git Push Origin master, bạn đã nhận thấy rằng sau lần đẩy đầu tiên, bạn có thể thực hiện git Push. Điều này là do một loạt các mặc định khó nhớ nhưng thường rất hữu ích 🙂
Nếu không có điều khiển từ xa được chỉ định, từ xa được cấu hình cho nhánh hiện tại (trong remote.master.url trong trường hợp của bạn) sẽ được sử dụng. Nếu điều đó không được thiết lập, thì Origin được sử dụng.
Nếu không có “refspec” (ví dụ: master, master:my-experiment, v.v.), thì git mặc định sẽ đẩy mọi nhánh cục bộ có cùng tên với một nhánh trên điều khiển từ xa. Nếu bạn chỉ có một nhánh gọi là master chung giữa kho lưu trữ của bạn và kho lưu trữ từ xa, thì điều đó sẽ giống như đẩy master của bạn sang điều khiển master từ xa.
git Push Origin master… Để tránh vô tình đẩy các nhánh khác.
Trả lời nhận xét của bạn về một trong những câu trả lời khác, tôi nghe có vẻ như là đang học về git theo cách từ trên xuống rất hiệu quả – bạn đã phát hiện ra rằng mặc định hoạt động và câu hỏi của bạn đang hỏi về tại sao;) Để nghiêm trọng hơn, git can được sử dụng đơn giản như SVN, nhưng biết một chút về điều khiển từ xa và các nhánh có nghĩa là bạn có thể sử dụng nó linh hoạt hơn nhiều và điều này thực sự có thể thay đổi cách bạn làm việc tốt hơn . Nhận xét của bạn về một khóa học trong học kỳ khiến tôi nghĩ về điều mà Scott Chacon đã nói trong một cuộc phỏng vấn podcast – sinh viên được dạy về tất cả các loại công cụ cơ bản trong khoa học máy tính và kỹ thuật phần mềm, nhưng rất hiếm khi kiểm soát phiên bản. Các hệ thống kiểm soát phiên bản phân tán như git và Mercurial hiện rất quan trọng và linh hoạt đến mức đáng để dạy các khóa học về chúng để cung cấp cho mọi người một nền tảng tốt.
Các tài liệu chính cho git là rất khó để phân tích cho người mới. (Mặc dù tôi cho rằng nếu bạn Google cho hầu hết mọi câu hỏi git, tài liệu hướng dẫn hữu ích (hoặc câu trả lời Stack Overflow :)) hiện nay sẽ xuất hiện.)
Hiện tại có một vài hành vi kỳ quặc trong git rất khó thay đổi vì nhiều kịch bản có thể dựa vào chúng, nhưng gây nhầm lẫn cho mọi người.
.git ở cuối tên kho lưu trữ chỉ là quy ước. Thông thường, kho lưu trữ trên máy chủ git được giữ trong các thư mục có tên project.git. Máy khách và giao thức git tôn vinh quy ước này bằng cách kiểm tra project.git khi chỉ project được chỉ định.
git là linh hoạt. Nó cho phép bạn theo dõi chi nhánh địa phương của bạn chống lại hầu hết các chi nhánh của bất kỳ kho lưu trữ nào. Trong khi master (nhánh mặc định cục bộ của bạn) theo dõi Origin/master (nhánh mặc định từ xa) là một tình huống phổ biến, nó không phổ biến. Nhiều lần bạn có thể không muốn làm điều đó. Đây là lý do tại sao git Push đầu tiên rất dài dòng. Nó cho git biết phải làm gì với nhánh master cục bộ khi bạn thực hiện git pull hoặc git Push.
Mặc định cho git Push và git pull là hoạt động với điều khiển từ xa của chi nhánh hiện tại. Đây là một mặc định tốt hơn so với Origin master. Cách git Push xác định điều này được giải thích ở đây .
git khá thanh lịch và dễ hiểu nhưng có một đường cong học tập để đi qua.
Bạn sử dụng git có thể bạn là lập trình viên. Nếu bạn là một lập trình viên hơn bạn có thể hiểu các biến là gì!
Hãy xem cú pháp để thêm một repo từ xa.
Thí dụ:
git remote add Origin [email protected]:peter/first_app.gitHãy để chúng tôi mổ xẻ lệnh:
git remote cái này được sử dụng để quản lý các máy chủ trung tâm của bạn để lưu trữ kho git của bạn.
Có thể bạn đang sử dụng Github cho công cụ lưu trữ trung tâm của mình. Tôi sẽ cho bạn một ví dụ và giải thích lệnh git từ xa thêm Origin
Giả sử tôi đang làm việc với GitHub và BitBucket cho các máy chủ trung tâm cho kho git và đã tạo kho lưu trữ trên cả hai trang web cho dự án First-app của tôi.
Bây giờ nếu tôi muốn Đẩy các thay đổi của mình lên cả hai máy chủ git này thì tôi sẽ cần nói với git cách tiếp cận các kho lưu trữ trung tâm này. Vì vậy, tôi sẽ phải thêm những thứ này,
Dành cho GitHub
git remote add gh_Origin https://github.com/user/first-app-git.gitVà đối với BitBucket
git remote add bb_Origin https://[email protected]/user/first-app-git.gitTôi đã sử dụng hai biến (rất dễ để tôi gọi chúng là biến) gh_Origin (gh FOR GITHUB) và bb_Origin (bb cho BITBucksET) chỉ để giải thích cho bạn .
Bây giờ sau khi thực hiện một số thay đổi, tôi sẽ phải gửi (Đẩy) tất cả những thay đổi này đến kho lưu trữ trung tâm để những người dùng khác có thể thấy những thay đổi này. Vì vậy, tôi gọi
Đẩy vào GitHub
git Push gh_Origin masterĐẩy sang BitBucket
git Push bb_Origin mastergh_Origin đang giữ giá trị của https://github.com/user/first-app-git.git và bb_Origin đang giữ giá trị của https:
Hai biến này đang làm cho cuộc sống của tôi dễ dàng hơn
vì bất cứ khi nào tôi cần gửi thay đổi mã của mình, tôi cần sử dụng các từ này thay vì ghi nhớ hoặc gõ URL cho cùng.
Hầu hết các lần bạn sẽ không thấy bất cứ điều gì ngoại trừ Origin vì hầu hết các lần bạn sẽ chỉ xử lý một kho lưu trữ trung tâm như Github hoặc BitBucket.
Git từ xa thêm Xuất xứ:
Nó tập trung mã nguồn của bạn vào các dự án khác. Nó được phát triển dựa trên Linux ,.
Đẩy mã của bạn vào kho git bằng cách sử dụng url từ xa của trung tâm git.
Làm Việc Với Remote Branch Trong Git
Thiết lập ví dụ để tìm hiểu Remote Branch
Ở phần này sẽ sử dụng lại kết quả ví dụ thực hành của phần trước Nhánh trong Git (Tức Local Repo lưu tại thư mục C:localmyproject).
Nếu đã có một Server Git thì làm theo hướng dẫn tại Remote Repo Git để tạo ra một Remote Repo, sau đó thêm vào Local Repo bằng lệnh git remote add name_remote addr_remote
Nếu muốn có thể thực hiện ngay ở máy local, để có được mô hình làm việc Client/Server với Git mà ý nghĩa giống như triển khai từ một Remote từ Server Git thật. Ta thực hiện theo các bước như sau:
1) Tạo Remote Repo tại máy Local
Chạy Git Bash, gõ các lệnh sau để tạo ra một Remote Repo (thực chất là trên máy của bạn) chứa tại thư mục C:remotemyproject
$ mkdir /c/remote/#Tạo thư mục c:remote $ mkdir /c/remote/myproject#Tạo thư mục c:remotemyproject $ cd /c/remote/myproject/#Tạo thư mục c:remotemyproject $ git init --bare#Tạo bare Repo (remote Repo) Initialized empty Git repository in C:/remote/myproject/Bạn đã có một Remote Repo có địa chỉ là C:/remote/myproject/ hoặc /c/remote/myproject/, tất nhiên Remote Repo này mới khới tạo chưa có dữ liệu gì. Bạn có thể cứ để cửa số Git Bash ở đây, để thuận tiện ta gọi cửa sổ này là Git Bash (Remote) để sau này có thể quay lại của sổ lệnh này nhanh chóng
2) Thiết lập Remote cho Local Repo(C1)
Mở một cửa sổ lệnh Git Bash khác, gọi cửa sổ này là Git Bash (C1), từ cửa sổ này chuyển đến thư mục lưu trữ Local Repo(C1) ( C:localmyproject – Repo này là kết quả của phần trước, đang có ba nhánh master, alpha, beta với hình ảnh snapshot như hình dưới)
Ta tiến hành thiết lập Remote cho nó: đặt tên remote là origin và địa chỉ remote chính là /c/remote/myproject/
$ cd /c/local/myproject/ $ git remote add origin /c/remote/myproject/#Thiết lập remote với tên origin $ cd /c/remote/myproject/Sau đó kiểm tra lại Remote của Local Repo này
$ git remote -v origin C:/remote/myproject (fetch) origin C:/remote/myproject (push)Các Video: Sử dụng Git, GitHub
Đã cấu hình chính xác, tiến hành push tất cả thông tin (tất cả các nhánh dữ liệu Repo) từ Repo(C1) lên Remote.
$ git push --all origin To C:/remote/myprojectRemote đã có dữ liệu khởi đầu, do Repo(C1) push tất cả các nhánh của nó nên.
3) Clone từ Remote để có Local Repo(C2)Mở một cửa sổ Git Bash đặt tên cửa sổ này là Git Bash(C2), chạy lệnh để nó clone Remote thành một bản Local, gọi là Local Repo(C2) đặt ở thư mục c:localprojectonc2
$ git clone /c/remote/myproject/ /c/local/projectonc2 Cloning into 'C:/local/projectonc2'... $ cd /c/local/projectonc2/ $ git remote -v origin C:/remote/myproject (fetch) origin C:/remote/myproject (push)Do Repo(C2) clone từ Remote, nên mặc định nó đã thiết lập Remote với tên origin
Tóm lại đến đây ta có các thứ sau:
Một Remote Repository tại địa chỉ /c/remote/myproject/ từ sau sẽ gọi tắt nó là Remote, Remote này đã được khởi tạo dữ liệu từ một Local Repository tên là Repo(C1) - Cửa sổ lệnh Git Bash làm việc với Remote gọi tên là Git Bash (Remote)
Một Local Repository tại thư mục /c/local/myproject (là kết quả của bài viết trược), đặt tên Local Repository này Repo(C1) (hàm ý là Local Repository trên máy tính của lập trình viên thứ nhất). Cửa sổ để Git Bash làm việc với nó gọi tên là Git Bash(C1). Repo(C1) đã được thiết lập Remote và đã push tất cả các nhánh lên Remote
Một Local Repository tại thư mục /c/local/projectonc2, có được do clone từ Remote, đặt tên Local Repository này Repo(C2) (hàm ý là Local Repository trên máy tính của lập trình viên thứ hai). Cửa sổ để Git Bash làm việc với nó gọi tên là Git Bash(C2)
Ở phần này chủ yếu làm việc với Repo(C2) (tại cửa sổ Git Bash(C2))
Làm việc với Remote Branch
Trong một Local Repo, nếu Remote đặt tên là remotename, và một nhánh tên là branchname thì để biểu thị nhánh này trên Remote sẽ ký hiệu là remotename/branchename. Ví dụ trong Repo(2) Remote đặt tên là origin (mặc định do clone), thì nhánh master trên Remote đó là origin/master
Tạm thời ta sẽ tìm hiểu trên một nhánh, nhánh master
1) Trạng thái nhánh Remote và Local sau khi clone
Tại Repo(C2) cũng kiểm tra trạng thái
$ git log --oneline be103d9 C9 1a90428 C8 89b19cb C7 eda207b C6 2c3fa4d C5 bbc3757 (origin/alpha) C4 c7d81e3 C3 0d7ae45 C2 927163b C1 efab635 C0 xt@xtMINGW64 /c/local/projectonc2 (master)2) Sự phân nhánh tại Local khi Remote cập nhật
Đầu tiên, giả sử Repo(C1) có thêm 2 commit mới với snapshot là C11, C12. Sau đó Repo(C1) cập nhật master lên Remote. Có nghĩa là nhánh master của Remote thay đổi và HEAD sẽ trỏ đến snapshot C12 (commit cuối). Thực hiện việc đó như sau:
Vào Repo(C1) tạo 1 file mới tên là chúng tôi sau đó commit, tiếp tục tạo file mới chúng tôi và commit tiếp, cuối cùng là push nhánh master lên Remote
$ touch 6.txt $ git add . $ git commit -m"C11" $ touch 7.txt $ git add . $ git commit -m"C12" $ git push origin master#đẩy commit mới lên RemoteGiờ quay trở lại Repo(C2), cũng tạo ra 2 sự thay đổi (thêm file mới) và mỗi sự thay đổi thực hiện một commit (C13, C14) - nhớ là ở Repo(C2) sau commit không push
$ touch 8.txt $ git add . $ git commit -m"C13" $ touch 9.txt $ git add . $ git commit -m"C14"Tại Remote gõ xem trạng thái, thấy HEAD ở C12
$ git log --oneline -4 c187f7c C11 544511a (beta) C10 be103d9 C9Tại Repo(2) xem trạng thái, thấy HEAD trỏ tới C14, còn origin/master vẫn đứng ở C10
$ git log --oneline -4 a607f5c C13 544511a (origin/master, origin/beta, origin/HEAD) C10 be103d9 C9Bây giờ tại Repo(C2) gõ lệnh git fetch origin hoặc git fetch --all lệnh này sẽ tìm trong origin những dữ liệu mới sau đó cập nhật vào dữ liệu của Repo(C2). Sau đó kiểm tra trạng thái
$ git status On branch master Your branch and 'remotes/origin/master' have divergedNó cho biết nhánh master và origin/master tại Repo(C2) bị phân nhánh. Có thể chuyển xem log của origin/master
$ git checkout origin/master $ git log --oneline -4 a607f5c C13 544511a (origin/beta) C10 be103d9 C9 $ git checkout masterQua đó dựng được tình trạng master và origin/master bị phân ly như sau:
3) Pull - Hợp nhánh bị phân ly
Để hợp nhánh phân ly trên dùng lệnh merge đã biết để hợp nhánh origin/master vào master sau khi fetch dữ liệu về.
Quá trình trên có thể tự động luôn cả 2 (tức là fetch xong, merge luôn) bằng lệnh git pull
$ git pull origin masterNếu có yêu cập nhập message khi hợp nhánh thì nhập C15 - Merge remote/origin/master, nếu có xung đột thì xử lý như phần xung đột khi merge
Sau khi pull kiểm tra log
$ git log --oneline -8 e172085 (origin/master) C14 a607f5c C13 31b00bb (origin/master, origin/HEAD) C12 c187f7c C11 544511a (origin/beta) C10 be103d9 C9 1a90428 C84) Push - cập nhật lên Remote
Hiện giờ tại Remote do Repo(C1) cập nhật làm cho Remote có master với snapshot cuối C12. Khi Repo(C2) cần cập nhật cũng gọi lệnh push như đã biết
$ git push origin masterTương tự lúc này Repo(C1) có thể pull về cập nhật các commit mà Repo(C2) cập nhật
5) Xóa nhánh tại Remote
$ git push remotename --delete branchnameĐổi tên nhánh Local và Remote
Để đổi tên một Branch ở Local sau đó thay đổi trên Remote làm như sau:
git branch -m old_branch new_branch # Đổi tên ở Local git push origin :old_branch # Xóa nhánh ở Remote git push --set-upstream origin new_branch # Cập nhật nhánh có tên mới lên RemoteCập nhật nhánh mới từ Remote vào Local
git pull origin # Cập nhật thông tin từ Remote git branch -r # Liệt kê các nhánh ở Remote git checkout -b branchname origin/branchname # Tao nhánh mới ở Local theo RemoteGit Là Gì, Hướng Dẫn Git Căn Bản
Lưu ý: Đây là một bài viết vô cùng hữu ích giành cho những bạn chưa biết gì về GIT, nhưng lại ít giá trị với những bạn đang đi tìm một seri học GIT đầy đủ.
I. Từ vấn đề cho tới Git là gì
1.1 Vấn đề
Chúng ta cùng tìm hiểu vấn đề thông qua một ví dụ do mình bịa ra như sau:
Bình và Sơn làm chung một dự án website thương mại điện tử, sau khi nhận yêu cầu, Bình và Sơn chia nhau công việc. Cách làm việc là mỗi khi có ai code xong một phần tính năng, thì sẽ copy code của mình gửi cho người kia thông qua USB để ghép vào dự án chung.
Thời gian đầu, code chưa có gì phức tạp, Bình và Sơn vẫn trao đổi code của mình qua USB bình thường. Nhưng sau một thời gian, code trở nên phức tạp, Bình và Sơn liên tục gặp sai sót trong quá trình copy code qua lại cho nhau, và tốn thời gian để giải quyết các sai sót đó. Vì không nghĩ đến điều này, nên dự án của Bình và Sơn bị thất bại do quá hạn deadline.
Tuy là ví dụ hư cấu, nhưng trong thực tế vẫn có các tình huống tương tự như vậy xảy ra, và trong cuộc đời của mỗi developer, thì hầu hết mọi người đều từng có một lần trao đổi và ghép code qua USB như vậy.
Quay trở lại với ví dụ về Bình và Sơn, dự án thất bại là do quá hạn deadline, mà nguyên nhân sâu xa là do cách làm việc không tốt. Khi copy code qua lại với nhau như vậy, việc xảy ra sai sót cũng là điều dễ hiểu vì:
Sẽ rất khó để ghép code, khi cả 2 người cùng sửa trên một file, và còn khó hơn khi hai người cùng sửa trên một dòng.
Code có thể bị “rơi rụng” (copy thiếu) trong lúc ghép code.
Với những tính năng nhiều code, thì thời gian ghép code có thể mất cả ngày.
Thực tế, khi làm việc theo cách của Bình và Sơn (hay cách nào tương tự vậy) thì còn có nhiều hạn chế khác bên cạnh các hạn chế kể trên:
Khó khăn khi bổ sung thêm người mới vào code cùng, càng nhiều người làm thì tỉ lệ sai sót càng cao.
Tốn thời gian để giải quyết các sai sót không đáng có.
Khó làm việc độc lập.
Vậy giải pháp cho các vấn đề trên là gì? Chính là GIT
1.2 Git là gì?
Để tìm hiểu GIT là gì, trước tiên mình muốn bạn biết về VCS là gì trước.
VCS – Version Control System (Hệ thống quản lý phiên bản). Cái tên VCS đã phần nào nói lên tính năng của hệ thống này, VCS sẽ lưu lại toàn bộ mã nguồn và ghi chép đầy đủ trạng thái thay đổi của các file, với từng trạng thái thay đổi mỗi file, đều được log lại thành một phiên bản.
Ví dụ dự án A có 10 thay đổi, thì VCS sẽ log lại thành 10 phiên bản khác nhau, và bạn có thể xem lại các phiên bản này.
Lưu ý: VCS ám chỉ một dạng hệ thống, chứ không phải tên một hệ thống cụ thể.
GIT đơn giản là một hệ thống thuộc dạng VCS. Tức là ngoài GIT ra vẫn còn nhiều hệ thống khác tương tự như GIT. Nhưng ngày nay (2020), khi nói tới VCS, người ta chỉ hình dung tới GIT, vì GIT có một số đặc điểm nổi bật hơn các VCS khác. Tuy nhiên dưới góc độ của một người mới bắt đầu tìm hiểu về VCS nói chung và GIT nói riêng, mình cho rằng bạn sẽ không quan tâm tới việc so sánh GIT với các VCS khác, nên mình xin phép không đề cập tới phần này. Chúng ta tạm thời khẳng định với nhau rằng ” GIT là lựa chọn thích hợp nhất cho một VCS trong thời điểm hiện tại “.
1.3 Vai trò của GIT trong phát triển phần mềm
Ngày nay, bất kỳ dự án phần mềm nào cũng nên áp dụng GIT, vì GIT giúp giải quyết một số vấn đề quan trọng sau:
Là nơi lưu trữ source codeHãy tưởng tượng GIT là một “đám mây” lưu trữ như Google Drive, Dropbox, tuy nhiên GIT được thiết kế riêng để lưu trữ source code.
Quản lý phiên bản source codeHãy tưởng tượng bạn đang phát triển một sản phẩm có rất nhiều người sử dụng. Vì sản phẩm có nhiều người dùng, nên yêu cầu tính ổn định phải cực kỳ cao. Vì yêu cầu tính ổn định cao, nên bạn không được phép code trực tiếp vào phiên bản source code đang chạy ổn định, mà phải code vào một phiên bản khác – gọi là phiên bản dev. Trong lúc bạn đang code ở phiên bản dev, thì phiên bản chạy ổn định vẫn có các cập nhật hằng ngày. Vậy vấn đề gặp phải là làm sao để có thể phát triển được nhiều phiên bản source cùng lúc. Thì với GIT, việc phát triển nhiều phiên bản cùng lúc vô cùng dễ dàng, việc code thêm ở phiên bản này sẽ không ảnh hưởng tới code ở phiên bản khác.
Có thể merge code (ghép code) từ nhiều ngườiĐây chính là một trong những lý do quan trọng nhất khiến người ta sử dụng VCS nói chung và GIT nói riêng. Với GIT, việc merge code từ nhiều người có thể diễn ra tự động, nếu trong quá trình merge code mà có xảy ra xung đột (mà GIT gọi là conflict) thì GIT sẽ cảnh báo để chúng ta biết.
1.4 Làm việc với GIT như thế nào
Một số khái niệm
Để biết cách làm việc với GIT, mình sẽ chỉ bạn mấy khái niệm cơ bản trong GIT trước:
Repository (hay nhiều người gọi tắt là repo): Là nơi lưu trữ source code, mỗi repository sẽ đại diện cho một dự án. Repository sẽ chia làm 2 loại, là Local repository và Remote repository.
Local repository: Là repository được đặt trên máy tính của bạn.
Remote repository: Là repository được đặt trên GIT server.
Init repository: Là thao tác khởi tạo một Local repository.
Clone: Là thao tác nhân bản một Remote repository thành Local repository trên máy của bạn.
Branch (Nhánh): GIT quản lý các phiên bản source dưới dạng cây có nhiều nhánh, mỗi nhánh là một phiên bản. Các nhánh có thể được tách ra, hoặc ghép vào nhau. Branch trong GIT được chia làm 2 loại, là branch master (nhánh chính) và các branch khác do bạn tạo ra trong quá trình làm việc.
Branch master: Là nhánh đầu tiên khi khởi tạo một GIT repository, branch master thường là nơi chứa source code đang chạy ổn định.
Checkout: Là thao tác chuyển qua chuyển lại giữa các branch. Khi nói “checkout master branch”, nghĩa là chuyển sang nhánh master.
Pull (kéo): Là thao tác đồng bộ code từ Remote repository xuống Local repository.
Commit: Là thao tác “xác nhận” một sự thay đổi của code. Thường thì mỗi tính năng sau khi được hoàn thiện sẽ thực hiện một commit.
Push (đẩy): Là thao tác đồng bộ code từ Local repository lên Remote repository.
Merge: Là thao tác ghép code lại với nhau.
Conflict: Là sự xung đột khi merge code.
Cách làm việc với GIT
Phần này mình sẽ trình bày một số thao tác và đặc điểm cơ bản khi áp dụng GIT trong dự án:
Git được cài đặt sẵn trên Linux và hỗ trợ các hệ điều hành phổ biến, bạn có thể download GIT miễn phí ở đây.
GIT nên được sử dụng trên Command Line thay vì các phần mềm hỗ trợ GIT trên GUI.
GIT có thể có nhiều Remote repository và Local repository. Remote repository sẽ đặt ở trên GIT server, còn Local repository đặt trên máy của bạn. Remote repository và Local repository sẽ được liên kết với nhau.
GIT quản lý tất cả các sự thay đổi như: thêm file mới, sửa file, xóa file, chmod thư mục,… bất kỳ điều gì làm thay đổi source code đều được GIT quản lý.
Khi bạn code, bạn sẽ code trên trên Local repository. Sau khi code xong tính năng, bạn thực hiện thao tác commit để xác nhận sự thay đổi của code.
Để đẩy các commit từ Local repository lên Remote repository, bạn sử dụng thao tác push. Các thành viên khác trong team muốn cập nhật các code mới do bạn bổ sung, thì thực hiện thao tác pull để đồng bộ code từ Remote repo về Local repo của họ.
Khi pull code từ Remote repo về Local repo sẽ xảy ra thao tác merge code. Nếu không bị conflict code giữa Local repo và Remote repo, việc merge code sẽ diễn ra tự động, nếu xảy ra conflict, GIT sẽ thông báo cho bạn biết.
Nếu bạn muốn khởi tạo một Local repo từ Remote repo thì sử dụng thao tác clone.
Branch master đang hoạt động ổn định, bạn không muốn code trực tiếp trên branch master, thì từ nhánh master bạn có thể tạo ra một nhánh khác – tạm gọi là nhánh xxx. Nhánh xxx lúc này chứa toàn bộ code của nhánh master, bạn có thể thoải mái thực hiện các thao tác commit, push, pull trên nhánh này mà không làm ảnh hưởng tới nhánh master. Khi tính năng trên nhánh xxx hoạt động ổn định, bạn có thể yên tâm merge code ở nhánh xxx vào nhánh master.
II. GIT vs Github
Chắc sẽ có nhiều bạn bị nhầm lần giữa GIT và Github. Thực ra GIT và Github vốn không thể so sánh với nhau, vì GIT là tên một hệ thống, còn Github là tên một đơn vị cung cấp dịch vụ GIT. Có thể hiểu nhanh rằng GIT và Github cũng tương tự như Porn và Pornhub vậy.
III. Cách sử dụng GIT cơ bản
Phần này mình sẽ hướng dẫn các bạn cách sử dụng GIT, cụ thể chúng ta sẽ sử dụng dịch vụ GIT miễn phí của Github – Một trong những nền tảng cung cấp dịch vụ GIT phổ biến nhất hệ mặt trời.
Trước tiên hãy đảm bảo máy tính của bạn đã cài đặt GIT, bạn có thể kiểm tra bằng cách thực hiện lệnh git --version trong terminal.
git --versionNếu thấy xuất hiện thông tin phiên bản của GIT, thì có nghĩa là máy tính của bạn đã cài đặt. Ngược lại, bạn phải download và cài đặt GIT vào máy trước khi thực hiện các bước sau đây.
3.1 Đăng ký tài khoản Github.com
Bạn truy cập vào https://github.com/join, điền thông tin vào form để đăng ký tài khoản.
Sau khi đăng ký xong, hãy đăng nhập vào Github để chuẩn bị cho bước tiếp theo.
3.1 Tạo repository đầu tiên
Sau khi đăng nhập, bạn tìm nút “New repository” như hình.
Repository name: Tên repository của bạn, bạn nên nhập dạng “ten-repository”
Description: Nhập mô tả về repository của bạn, thông tin này để trống cũng được.
Public hay Private: Public thì bất kỳ ai cũng có thể xem và clone repo của bạn, Private thì chỉ có bạn hoặc những người bạn cho phép mới có thể thực hiện các thao tác đó. Ở đây bạn hãy chọn Public dễ thao tác hơn, chúng ta sẽ tìm hiểu về Private repo sau.
Sau đó, bạn sẽ được chuyển tới trang chi tiết repository như hình.
Cụ thể là bạn vừa tạo xong một Remote repository mới tinh chưa có code, và Github đang gợi ý cho bạn một số cách để đẩy những file đầu tiên lên Remote repository này. Theo như Github gợi ý, thì bạn có 3 cách:
Cách 1: Tạo một Local repository trên máy tính của bạn, liên kết nó với Remote repository này, tạo commit đầu tiên rồi đẩy commit đó lên nhánh master.
Cách 2: Nếu bạn có sẵn một Local repository, thì chỉ cần liên kết nó với Remote repository này, và đẩy các commit lên master.
Cách 3: Import từ một repository khác.
mkdir my-local-repository # Tạo một thư mục có tên là "my-local-repository" cd my-local-repository # Di chuyển vào thư mục vừa tạo git init # Khởi tạo một GIT Local repository git add chúng tôi # Thêm file chúng tôi vào commit git commit -m "first commit" # Xác nhận sự thay đổi git remote add origin https://github.com/phambinhnet/first-repository.git # Link tới remote repository git push -u origin master # Đẩy code lên nhánh masterKhi chạy lệnh git push ..., git sẽ yêu cầu bạn nhập username và password.
Sau khi chạy xong, tại trang chi tiết Repository trên Github, bạn tải lại trang sẽ thấy kết quả như hình:
Nếu Local repository của bạn tiếp tục có sự thay đổi và bạn muốn đồng bộ (push) nó lên Remote repository, thì bạn cũng chỉ cần thực hiện lại các bước:
git commit -m “ghi chú về sự thay đổi” git push origin master
Chi tiết hơn về các lệnh git add, git commit, git push thì mình sẽ trình bày ở phần tiếp theo.
3.2 Add, status, pull, commit, push
git add
Một commit có thể bao gồm nhiều sự thay đổi, để thêm sự thay đổi vào commit, bạn sử dụng lệnh git add pattern. Trong đó, pattern có thể là:
Đường dẫn tới một file hoặc thư mục
Sử dụng pattern là * nếu bạn muốn add tất cả sự thay đổi trong thư mục hiện tại (bao gồm cả các thư mục con).
Sử dụng pattern là . nếu bạn muốn thêm tất cả sự thay đổi
git status
Lệnh git status cho phép bạn xem trạng thái của Local repository hiện tại, như có những file nào mới, có file nào bị chỉnh sửa, có file nào bị xóa,…
Thường thì trước khi sử dụng lệnh git add, mình sẽ chạy một lần lệnh git status để xem Local repo có những sự thay đổi nào, từ đấy mới biết đường mà add.
git commit
Lệnh git commit cho phép bạn xác nhận các sự thay đổi sau khi chúng đã được add. Cấu trúc của một lệnh git commit thường là như sau:
git commit -m "Mô tả về sự thay đổi"Sau khi chạy xong lệnh git commit, mình cũng thường chạy lại lệnh git status thêm một lần nữa để xem có commit thiếu sự thay đổi nào không, cũng như để đảm bảo là đã commit thành công.
git push
Lệnh git push được sử dụng để đẩy các commit từ Local repo lên Remote repo.
Sau khi commit, thì các code thay đổi vẫn nằm tại Local repo, để đẩy chúng lên Remote repo thì bạn phải sử dụng lệnh git push. Đầy đủ câu lệnh này lên là:
Trong đó origin là tên remote repository (tên các remote repo cũng thường là origin luôn), còn branch là nhánh muốn đẩy lên. Giả sử mình muốn đẩy các commit lên nhánh master thì mình sẽ chạy lệnh như sau:
git push origin mastergit pull
Lệnh git pull được sử dụng để đồng bộ Remote repository về Local repository. Đầy đủ câu lệnh nên là:
Với origin và branch được mô tả giống như lệnh git push. Giả sử mình muốn đồng bộ Remote repo từ nhánh master về Local repo thì mình sẽ sử dụng lệnh sau:
git pull origin master3.3 Branch, checkout
Phần này khá ngắn gọn thôi.
GIT quản lý các phiên bản source qua khái niệm branch, mặc định mỗi GIT repo sẽ có sẵn một branch là branch master.
Để tạo một branch mới, trước tiên bạn cần xác định là branch mới này sẽ được tách ra từ branch nào. Ví dụ mình tạo một branch mới được tách ra từ branch master thì mình sẽ thực hiện các lệnh như sau:
git checkout master # Chuyển qua nhánh master git checkout -bten_branch # Tạo branch mới đồng thời chuyển qua branch vừa tạoViệc tách nhánh để làm việc sẽ khiến bạn quản lý sự thay đổi tốt hơn, cũng như giảm thiểu sai sót. Vì sau khi tách nhánh, bạn có thể thoải mái chỉnh sửa code trên nhánh vừa tách mà không lo ảnh hưởng tới các nhánh khác. Bạn có thể xem hình sau để hiểu rõ hơn (mỗi một chấm xanh là đại diện cho một commit).
Ở hình trên, bạn thấy nhánh new_feature được tách ra từ nhánh master, trên nhánh new_feature có 2 commit. Trước khi nhánh new_feature được merge vào master, nếu 2 commit kia có lỗi thì cũng sẽ không ảnh hưởng tới nhánh master.
IV. Lời kết
Đây là một bài viết dài và có nhiều kiến thức, nếu bạn có đọc một lần mà vẫn chưa hiểu thì cũng là chuyện bình thường. Cá nhân mình biết GIT từ thời năm 2 sinh viên, nhưng mãi cho tới khi ra trường và đi làm mới hiểu thật sự về cách làm việc với GIT. Nếu bạn cảm thấy khó hiểu, thì mình có một vài gợi ý sau:
Là một lập trình viên; Thích tìm hiểu và chia sẻ kiến thức công nghệ; Thích chiêm nghiệm cuộc sống
Git Là Gì? Các Lệnh Git Cơ Bản Mà Mọi Lập Trình Viên Nên Biết
Git là gì?
Git là một hệ thống quản lý phiên bản phân tán (Distributed Version Control System – DVCS), nó 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. Git cung cấp cho mỗi lập trình viên kho lưu trữ ( repository) riêng chứa toàn bộ lịch sử thay đổi.
Version Control System – VCS là gì?
VCS là viết tắt của Version Control System là hệ thống kiểm soát các phiên bản phân tán mã nguồn mở. Các VCS sẽ lưu trữ tất cả các file trong toàn bộ dự án và ghi lại toàn bộ lịch sử thay đổi của file. Mỗi sự thay đổi được lưu lại sẽ được vàthành một version (phiên bản).
VCS nghĩa là hệ thống giúp lập trình viên 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 local sẽ có thể ủy thác ( commit) rồi đưa lên server 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.
Lập trình viên có thể xem lại danh sách các sự thay đổi của file như xem một dòng thời gian của các phiên bản. Mỗi phiên bản bao gồm: nội dung file bị thay đổi, ngày giờ sửa đổi, người thay đổi là ai, lý do thay đổi hay tên phiên bản…
VCS có tác dụng như thế nào?
Lưu lại lịch sử các version của bất kỳ thay đổi nào của dự án. Giúp xem lại các sự thay đổi hoặc khôi phục (revert) lại sau này.
Việc chia sẻ code trở nên dễ dàng hơn, lập trình viên có thể để public cho bất kỳ ai, hoặc private chỉ cho một số người có thẩm quyền có thể truy cập và lấy code về.
Vốn là một VCS nên Git cũng ghi nhớ lại toàn bộ lịch sử thay đổi của source code trong dự án. Lập trình sửa file, thêm dòng code tại đâu, xóa dòng code ở hàng nào…đều được Git ghi nhận và lưu trữ lại.
Git hoạt động như thế nào?
Sự khác biệt chính giữa Git và bất kỳ VCS nào khác (bao gồm Subversion…) là cách Git nghĩ về dữ liệu của nó.
Về mặt khái niệm, hầu hết các hệ thống khác đều lưu trữ thông tin dưới dạng danh sách các thay đổi dựa trên file. Các hệ thống này (CVS, Subversion, Perforce, Bazaar, v.v.) coi thông tin chúng lưu giữ dưới dạng một tập hợp các file và những thay đổi được thực hiện đối với mỗi file theo thời gian.
Git không nghĩ đến hoặc lưu trữ dữ liệu của mình theo cách này. Thay vào đó, Git coi thông tin được lưu trữ là một tập hợp các snapshot – ảnh chụp toàn bộ nội dung tất cả các file tại thời điểm.
Đây là điểm khác biệt quan trọng giữa Git và gần như tất cả các VCS khác. Nó khiến Git phải xem xét lại hầu hết mọi khía cạnh của kiểm soát phiên bản mà hầu hết các hệ thống khác đã sao chép từ thế hệ trước. Điều này làm cho Git giống như một hệ thống tệp nhỏ với một số công cụ cực kỳ mạnh mẽ được xây dựng trên nó, thay vì chỉ đơn giản là một VCS.
Git có lợi ích gì?
Các dự án thực tế thường có nhiều lập trình viên làm việc song song. Vì vậy, một hệ thống kiểm soát phiên bản như Git là cần thiết để đảm bảo không có xung đột code giữa các lập trình viên.
Ngoài ra, các yêu cầu trong các dự án như vậy thay đổi thường xuyên. Vì vậy, một hệ thống kiểm soát phiên bản cho phép các nhà phát triển revert và quay lại phiên bản cũ hơn của code.
Dễ sử dụng, thao tác nhanh, gọn, lẹ và rất an toàn.
Sễ dàng kết hợp các phân nhánh (branch), có thể giúp quy trình làm việc code theo nhóm đơn giản hơn rất nhiều.
Chỉ cần clone mã nguồn từ kho chứa hoặc clone một phiên bản thay đổi nào đó từ kho chứa, hoặc một nhánh nào đó từ kho chứa là bạn có thể làm việc ở mọi lúc mọi nơi.
Deployment sản phẩm của bạn một cách không thể nào dễ dàng hơn.
Các thuật ngữ Git quan trọng
1. Branch
Các Branch (nhánh) đại diện cho các phiên bản cụ thể của một kho lưu trữ tách ra từ project chính của bạn.
Branch cho phép bạn theo dõi các thay đổi thử nghiệm bạn thực hiện đối với kho lưu trữ và có thể hoàn nguyên về các phiên bản cũ hơn.
2. Commit
Một commit đại diện cho một thời điểm cụ thể trong lịch sử dự án của bạn. Sử dụng lệnh commit kết hợp với lệnh git add để cho git biết những thay đổi bạn muốn lưu vào local repository.
3. Checkout
Sử dụng lệnh git checkout để chuyển giữa các branch. Chỉ cần nhập git checkout theo sau là tên của branch bạn muốn chuyển đến hoặc nhập git checkout master để trở về branch chính (master branch).
4. Fetch
Lệnh git fetch tìm nạp các bản sao và tải xuống tất cả các tệp branch vào máy tính của bạn. Sử dụng nó để lưu các thay đổi mới nhất vào kho lưu trữ của bạn. Nó có thể tìm nạp nhiều branch cùng một lúc.
5. Fork
Một fork là một bản sao của một kho lưu trữ (repository). Các lập trình viên thường tận dụng lợi ích của fork để thử nghiệm các thay đổi mà không ảnh hưởng đến dự án chính.
6. Head
Các commit ở đầu của một branch được gọi là head. Nó đại diện cho commit mới nhất của repository mà bạn hiện đang làm việc.
7. Index
Bất cứ khi nào bạn thêm, xóa hoặc thay đổi một file, nó vẫn nằm trong chỉ mục cho đến khi bạn sẵn sàng commit các thay đổi. Nó như là khu vực tổ chức (stagging area) cho Git. Sử dụng lệnh git status để xem nội dung của index của bạn.
Stagging là một bước trước khi commit trong git.
Một commit trong git được thực hiện theo hai bước: Stagging và commit thực tế. Miễn là những thay đổi nằm trong khu vực tổ chức (stagging area), git cho phép bạn chỉnh sửa nó theo ý muốn (thay thế các tệp được phân đoạn bằng các phiên bản khác của các tệp được phân loại, loại bỏ các thay đổi khỏi phân đoạn, v.v.)
Những thay đổi được tô sáng bằng màu xanh lá cây đã sẵn sàng để được commit trong khi những thay đổi màu đỏ thì chưa.
8. Master
Master là nhánh chính của tất cả các repository của bạn. Nó nên bao gồm những thay đổi và commit gần đây nhất.
9. Merge
Lệnh git merge kết hợp với các yêu cầu kéo (pull requests) để thêm các thay đổi từ nhánh này sang nhánh khác.
10. Origin
Lệnh git push origin master để đẩy các thay đổi cục bộ đến nhánh chính.
11. Pull
Pull requests thể hiện các đề xuất thay đổi cho nhánh chính. Nếu bạn làm việc với một nhóm, bạn có thể tạo các pull request để yêu cầu người bảo trì kho lưu trữ xem xét các thay đổi và hợp nhất chúng.
Lệnh git pull được sử dụng để thêm các thay đổi vào nhánh chính.
12. Push
Lệnh git push được sử dụng để cập nhật các nhánh từ xa với những thay đổi mới nhất mà bạn đã commit.
13. Rebase
Lệnh git rebase cho phép bạn phân tách, di chuyển hoặc thoát khỏi các commit. Nó cũng có thể được sử dụng để kết hợp hai nhánh khác nhau.
14. Remote
Một Remote (kho lưu trữ từ xa) là một bản sao của một chi nhánh. Remote giao tiếp ngược dòng với nhánh gốc (origin branch) của chúng và các Remote khác trong kho lưu trữ.
15. Repository
Kho lưu trữ Git chứa tất cả các tệp dự án của bạn bao gồm các branch, tags và commit.
16. Stash
Lệnh git stash sẽ loại bỏ các thay đổi khỏi chỉ mục của bạn và xóa stashes chúng đi sau.
Nó có ích nếu bạn muốn tạm dừng những gì bạn đang làm và làm việc khác trong một khoảng thời gian. Bạn không thể đặt stash nhiều hơn một bộ thay đổi ở cùng một thời điểm.
17. Tags
Tags cung cấp cho bạn một cách để theo dõi các commit quan trọng. Các tags nhẹ chỉ đơn giản đóng vai trò là con trỏ trong khi các tags chú thích được lưu trữ dưới dạng các đối tượng đầy đủ.
19. Upstream
Trong ngữ cảnh của Git, upstream đề cập đến nơi bạn push các thay đổi của mình, thường là nhánh chính (master branch).
Các lệnh git cơ bản
1) git config
Tác dụng : Để set user name và email của bạn trong main configuration file. Cách xài : Để kiểm tra tên và kiểu email trong cấu hình dùnggit config -- global user.name và git config -- global user.email. Để set email hoặc tên mới git config -- global chúng tôi = "Hải Nguyễn" và git config -- global user.email = "hainguyen@gmail.com"
2) git init
Tác dụng : Khởi tạo 1 git repository 1 project mới hoặc đã có.
Cách xài: git init trong thư mục gốc của dự án.
3) git clone
Tác dụng: Copy 1 git repository từ remote source.
4) git status
Tác dụng: Để check trạng thái của những file bạn đã thay đổi trong thư mục làm việc. VD: Tất cả các thay đổi cuối cùng từ lần commit cuối cùng.
Cách xài: git status trong thư mục làm việc.
5) git add
Tác dụng: Thêm thay đổi đến stage/index trong thư mục làm việc.
6) git commit
Tác dụng: commit nghĩa là một action để Git lưu lại một snapshot của các sự thay đổi trong thư mục làm việc. Và các tập tin, thư mục được thay đổi đã phải nằm trong Staging Area. Mỗi lần commit nó sẽ được lưu lại lịch sử chỉnh sửa của code kèm theo tên và địa chỉ email của người commit. Ngoài ra trong Git bạn cũng có thể khôi phục lại tập tin trong lịch sử commit của nó để chia cho một branch khác, vì vậy bạn sẽ dễ dàng khôi phục lại các thay đổi trước đó.
Cách dùng: git commit -m "Đây là message, bạn dùng để note những thay đổi để sau này dễ dò lại"
7) git push/git pull
Tác dụng: Push hoặc Pull các thay đổi đến remote. Nếu bạn đã added và committed các thay đổi và bạn muốn đẩy nó lên hoặc remote của bạn đã update và bạn apply tất cả thay đổi đó trên code của mình.
8) git branch
Tác dụng: liệt kê tất cả các branch (nhánh).
9) git checkout
Tác dụng: Chuyển sang branch khác
Cách dùng: hoặc nếu bạn muốn tạo và chuyển sang một chi nhánh mới.
10) git stash
Tác dụng: Lưu thay đổi mà bạn không muốn commit ngay lập tức.
Cách dùng: trong thư mục làm việc của bạn.
11) git merge
Tác dụng: Merge 2 branch lại với nahu.
Cách dùng: Chuyển tới branch bạn muốn merge rồi dùng
12) git reset
Tác dụng: Bạn đã đưa một tập tin nào đó vào Staging Area nhưng bây giờ bạn muốn loại bỏ nó ra khỏi đây để không phải bị commit theo.
13) git remote
Tác dụng: Để check remote/source bạn có hoặc add thêm remote
14) git add
Tác dụng: Để đưa một tập tin vào Staging Area
Cách dùng: hoặc muốn thêm hết file của thư mục thì
Lời khuyên khi thao tác thường xuyên với Git trong công việc
Bạn không thể nào nhớ được hết các lệnh, lúc này bạn nên sử dụng các Git Cheet Sheets để dễ dàng tìm được lệnh Git bạn cần:
2. Nên commit thương xuyên
Tách nhỏ commit của bạn và commit thường xuyên nhất có thể. Điều này giúp các thành viên trong nhóm dễ dàng tích hợp công việc của họ hơn mà không gặp phải xung đột hợp nhất.
3. Test rồi mới commit
Không bao giờ commit nếu chưa hoàn tất process. Cần phải test các thay đổi của bạn trước khi chia sẻ chúng với người khác.
4. Viết ghi chú khi commit
Viết ghi chú khi commit để cho các thành viên khác trong nhóm biết loại thay đổi bạn đã thực hiện. Hãy mô tả càng nhiều càng tốt.
5. Thử nghiệm Branch khác
Tận dụng lợi thế của các branch để giúp bạn theo dõi các dòng phát triển khác nhau.
6. Theo một Git Workflow
Bạn nên chọn theo một Git Workflow để đảm bảo cả nhóm của bạn đều cùng thực hiện như nhau.
Bạn đang xem bài viết “Git Remote Add …” Và “Git Push Origin Master” Là Gì? trên website Tvzoneplus.com. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!