Git 사용법 튜토리얼

Git이란 무엇입니까

공식: Git은 소규모 프로젝트부터 대규모 프로젝트까지 모든 것을 빠르고 효율적으로 처리하도록 설계된 무료 오픈 소스 분산 버전 제어 시스템입니다.

모든 파일 변경 사항을 자동으로 기록할 수 있고, 동료들이 공동으로 편집할 수도 있으므로, 비슷한 파일을 직접 관리할 필요도 없고, 파일을 전달할 필요도 없습니다. 특정 변경 사항을 보려면 소프트웨어를 살펴보기만 하면 됩니다.

Git을 배워야 하는 이유

인터뷰에서 질문을 받았습니다. 면접을 처리할 수 있습니다.

많은 회사에서 Git을 사용하여 개발 중에 프로젝트를 처리합니다. 지금 배우지 않는다면 나중에 반드시 배워야 할 것입니다.

내 생각에는 Git은 오늘날 모든 프로그래머가 마스터해야 하는 것입니다. 앞으로 동료와 공동으로 프로젝트를 개발할 때 반드시 사용해야 할 Git 명령이 개발 효율성을 높일 수 있습니다.

관련 추천: ​​
1.Git 사용법(사진+동영상)
2.Git과 Github의 차이점(사진+동영상)

Git 설치

Windows

공식에서 직접 다운로드 웹사이트. 다운로드가 완료된 후 파일을 마우스 오른쪽 버튼으로 클릭하고 Git Bash Here가 있으면 설치가 성공합니다. 설치 후에는 명령줄에 다음을 입력해야 합니다.

$git config --global user.name"你的名字"
$git config --global user.email"你的邮箱"

global은 전역을 의미합니다. 이 머신의 모든 Git 저장소는 이 구성을 사용합니다. 개별 저장소가 다른 이름과 이메일 주소를 사용할 수 있도록 허용합니다.

Mac

Mac도 위의 단계에 따라 Windows처럼 설치할 수 있습니다.

AppStore에서 직접 Xcode를 설치할 수도 있습니다. Xcode는 Git을 통합하지만 기본적으로 설치되지는 않습니다. Xcode를 실행하고 "Xcode"->"기본 설정" 메뉴를 선택한 다음 팝업에서 "다운로드"를 찾으세요. 창을 열고 "명령줄" 도구"를 선택한 후 "설치"를 클릭하여 설치를 완료합니다.

Warehouse

현지 창고는 원격 창고용입니다. 로컬 창고 = 작업공간 + 버전 영역.

작업공간은 디스크에 있는 파일들의 모음입니다.

버전 영역(버전 라이브러리)은 .git 파일입니다.

리포지토리 = 스테이징 영역(스테이지) + 브랜치(마스터) + 포인터 헤드.

내가 가장 자주 사용하는 git 명령인 github에 제출하는 명령을 예로 들어보겠습니다.

git init 원래 로컬 창고에는 가장 일반적인 작업 상태인 작업 공간만 포함되어 있었습니다. 이때 git init은 로컬 영역에 .git 파일을 생성하고 버전 영역을 설정한다는 의미이다.

git add .작업 공간의 모든 파일을 버전 영역의 임시 저장 영역에 제출하는 것을 의미합니다.

물론 git add ./xxx/를 통해 하나씩 Staging Area에 추가할 수도 있습니다.

git commit -m "xxx" 임시 저장 영역의 모든 파일을 창고 영역으로 제출하고 임시 저장 영역은 비어 있습니다.

git 원격 추가 원본 https://github.com/name/name_cangku.git 로컬 저장소와 원격 저장소를 연결합니다.

git push -u Origin master는 창고 영역의 파일을 원격 창고로 제출합니다.

제출한 후 작업 공간을 수정하지 않으면 작업 공간이 "깨끗"합니다. 커밋할 항목이 없습니다. 작업 트리가 깨끗하다는 메시지가 표시됩니다.

Submit to GitHub

저는 git 명령어가 익숙하지 않을 때 GitHub에 프로젝트를 제출할 때 웹페이지에 있는 파일을 직접 가져와서 제출하곤 했습니다. 조금 부끄럽습니다.

git init. 초기화는 이 파일을 Git에서 관리할 수 있는 창고로 바꾸는 것을 의미합니다. 초기화 후 숨김 파일을 열면 .git 파일이 있는 것을 확인할 수 있습니다.

git add. 뒤에 있는 점은 모든 파일이 임시 저장 영역에 제출됨을 나타냅니다.

git add ./readme.md/는 이 파일 아래의 readme.md 파일을 임시 저장 영역에 제출한다는 의미입니다.

git commit -m "댓글을 달고 싶으신가요?" git commit은 스테이징 영역의 모든 파일을 로컬 창고에 제출한다는 의미입니다. -m 뒤에 주석이 옵니다.

git 원격 원본 추가 https://github.com/name/name_cangku.git은 로컬 창고를 GitHub의 원격 창고에 연결하는 것을 의미합니다. 한 번만 연결하면 되며 나중에 제출할 때 이 명령을 사용할 필요가 없습니다. name은 github 이름이고, name_cangku는 창고 이름입니다. 마지막에 있는 .git을 놓치지 않도록 주의하세요. 왜냐하면 나는 이렇게 왔고, 많은 우회를 했기 때문이다. GitHub에서 새 창고를 만드는 방법은 인터넷에 많은 튜토리얼이 있으므로 여기에서는 자세히 설명하지 않겠습니다.

git push -u origin master 把本地仓库提交到远程仓库。(最后一步)在你的远程仓库上刷新一下就可以看到你提交的文件了。

最后提到的是，在git commit -m ""之前，可以重复git add到暂存区。但是git commit会把你之前存放在暂存区的全部文件一次性全部提交到本地仓库。

版本的回溯与前进

提交一个文件，有时候我们会提交很多次，在提交历史中，这样就产生了不同的版本。每次提交，Git会把他们串成一条时间线。如何回溯到我们提交的上一个版本，用git reset --hard + 版本号即可。版本号可以用git log来查看，每一次的版本都会产生不一样的版本号。

回溯之后，git log查看一下发现离我们最近的那个版本已经不见了。但是我还想要前进到最近的版本应该如何？只要git reset --hard + 版本号就行。退一步来讲，虽然我们可以通过git reset --hard + 版本号,靠记住版本号来可以在不同的版本之间来回穿梭。

但是,有时候把版本号弄丢了怎么办？git reflog帮你记录了每一次的命令，这样就可以找到版本号了，这样你又可以通过git reset来版本穿梭了。

撤销

场景1：在工作区时，你修改了一个东西，你想撤销修改，git checkout -- file。廖雪峰老师指出撤销修改就回到和版本库一模一样的状态，即用版本库里的版本替换工作区的版本。

场景2：你修改了一个内容，并且已经git add到暂存区了。想撤销怎么办？回溯版本，git reset --hard + 版本号,再git checkout -- file,替换工作区的版本。

场景3：你修改了一个内容，并且已经git commit到了master。跟场景2一样，版本回溯，再进行撤销。

删除

如果你git add一个文件到暂存区，然后在工作区又把文件删除了，Git会知道你删除了文件。如果你要把版本库里的文件删除，git rm 并且git commit -m "xxx".

如果你误删了工作区的文件，怎么办？使用撤销命令，git checkout --就可以。这再次证明了撤销命令其实就是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

分支

分支，就像平行宇宙，你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。用 Git 和 Github 提高效率的 10 个技巧！这篇也推荐看下。

创建与合并分支

在没有其他分支插进来时，只有一个master主分支。每次你git push -u origin master 提交就是增加一条时间轴，master也会跟着移动。

创建一个other的分支，通过other提交，虽然时间轴向前走了，但是主分支master还在原来的位置。

理论分析完，看一下命令怎么写。

创建分支other,切换到other分支。

gitbranch other
gitcheckout other

查看当前所有分支

gitbranch
* othermaster

当前的分支会有一个*

用other提交

gitadd ./xxx/
git commit -m"xxx"

other分支完成，切换回master

git checkoutmaster

此时，master分支上并没有other的文件，因为分支还没有合并。

合并分支

gitmergeother

合并完成之后，就可以在master分支上查看到文件了。

删除other分支

gitbranch -d other

我由此想到，在以后工作中，应该是一个开放小组共同开发一个项目，组长会创建很多分支，每一个分支可以交给一个人去开发某一个功能，一个小组共同开发而且不会相互干扰。谁的功能完成了，可以由组长合并一下完成了的分支。哦，完美！

解决合并分支问题

그런 상황이라면 브랜치 other가 커밋됐는데 이때 포인터는 다시 master를 가리키고, master는 merge되지 않고 git add / 커밋 커밋 . 이런 식으로 충돌이 발생하고, 메인 브랜치의 마스터 파일 내용이 다른 브랜치의 내용과 다르다. 병합할 수 없습니다! 따라서 파일 내용을 수정하여 일관성을 유지하세요.

git add git commit 커밋.

브랜치가 병합되었습니다.

git log --graph 브랜치 병합 그래프 보기

git Branch -d other 브랜치를 삭제하면 작업이 종료됩니다.

브랜치 관리 전략

git merge --no-ff other 빨리 감기 모드를 사용하므로 브랜치를 삭제한 후 빨리 감기 모드를 사용하지 않습니다. , 지점 내역 정보가 손실됩니다. 매우 상세한 Git 실용적인 튜토리얼, 심지어 바보라도 한 눈에 이해할 수 있습니다!

BUG 브랜치

작업 중 모든 버그는 새로운 임시 브랜치를 통해 수정될 수 있습니다. 복구 후 브랜치를 병합한 후 임시 브랜치를 삭제하세요. 하지만 직장에 지점이 있으면 상사가 다른 지점의 버그를 수정하라고 요청할 것입니다.

지금 작업 중인 브랜치를 저장하고, git stash를 하고, 현재 작업 사이트를 "저장"하고, 나중에 복구한 후 작업을 계속해야 합니다. 버그를 해결한 후 git checkout other를 실행하고 자신의 브랜치로 돌아갑니다. 방금 "stash"한 작업이 어디로 갔는지 확인하려면 git stash list를 사용하세요.

이제 작업을 재개해야 합니다.

git stash apply는 복원하지만 숨김 콘텐츠를 삭제하지는 않으며, git stash drop은 숨김 콘텐츠를 삭제합니다.

git stash pop이 복원되면 stash 콘텐츠도 삭제됩니다.

이때 git stash list를 이용하여 열람하시면 Stash 내용을 보실 수 없습니다.

요약: 버그를 수정할 때는 새 버그 브랜치를 생성하여 수정한 다음 병합하고 작업이 완료되지 않으면 먼저 삭제합니다. 작업 사이트를 stash하고, 버그를 수정한 후 git stash pop하고 작업 사이트로 돌아갑니다.

브랜치 삭제

git Branch -d + Branch는 Git이 병합되지 않은 브랜치를 보호하므로 삭제되지 않을 수 있습니다.

git Branch -D + Branch는 병합되지 않은 브랜치를 강제로 삭제하고 폐기합니다.

Multiple Collaboration

git 원격 원격 라이브러리의 정보를 확인하면 원본이 표시됩니다. 원격 창고의 기본 이름은 Origin

입니다. git remote -v display 자세한 정보

git push -u Origin master는 마스터 브랜치를 원본 원격 창고로 푸시합니다.

git push -u Origin other 다른 항목을 원본 원격 창고로 푸시합니다.

Catch Branch

위 그림에서 충돌이 발생하면 #🎜🎜 #

git pull은 원격 저장소에서 최신 커밋을 가져와 로컬에서 병합하고 충돌을 해결합니다. git pull을 수행할 때

git pull도 실패하면 Git이 이 단계에서 수행할 작업을 알려줍니다. 그런 다음 다시 git pull을 하세요.

다중 공동 작업의 작업 모드는 일반적으로 다음과 같습니다.

먼저 git push Origin

을 사용하여 푸시할 수 있습니다. #🎜🎜 #

푸시가 실패하면 원격 브랜치가 로컬 브랜치보다 최신이므로 먼저 git pull을 사용하여 병합을 시도해야 합니다.

해당되는 경우 병합에 충돌이 있으면 충돌을 해결하고 로컬로 제출하세요.# 🎜🎜#

충돌이 없거나 충돌이 해결된 경우 git push Origin

을 사용하여 성공적으로 푸시하세요. !

git pull에서 추적 정보가 표시되지 않으면 로컬 브랜치와 원격 브랜치 간의 링크 관계가 생성되지 않았음을 의미합니다. git Branch --set-upstream-to Origin/ 명령을 사용하세요.

Rebase

git rebase는 포크된 커밋 기록을 직선으로 "구성"하는데, 이는 더 직관적으로 보인다는 것입니다. 분기 포크 커밋이 수정되었습니다.

마지막으로, git push -u Origin master

리베이스의 목적은 이전 제출의 변경 사항을 더 쉽게 볼 수 있도록 하는 것입니다. 포크된 제출에는 3방향 비교가 필요하기 때문입니다. .

태그 관리

예를 들어 앱이 온라인에 접속하려는 경우 일반적으로 이러한 방식으로 버전 라이브러리에 태그를 넣습니다. , 라벨의 버전이 결정됩니다. 미래에 태그가 붙은 버전을 검색한다는 것은 태그가 붙은 순간에 과거 버전을 꺼내는 것을 의미합니다. 따라서 태그는 저장소의 스냅샷이기도 합니다.

Git 태그는 저장소의 스냅샷이지만 실제로는 커밋에 대한 포인터입니다.

tag는 실제로 기억하기 쉽고 의미 있는 이름이며 특정 커밋과 연결되어 있습니다. 예를 들어 v2.1 태그는 v2.1이라는 이전 버전을 나타냅니다.

태그 만들기

Steps:

git 분기를 사용하여 현재 버전을 확인합니다. 브랜치, git checkout master는 마스터 브랜치로 전환됩니다.

git tag 태그, 기본값은 HEAD입니다. 예를 들어 git tag v1.0

기본 태그는 최신 커밋에 배치됩니다. 이전 커밋에 태그를 지정하려면 git log를 사용하여 기록 커밋 .0 태그의 커밋 ID를 찾으세요.

git 태그 모든 태그를 보면 태그의 과거 버전을 알 수 있습니다

태그는 시간순이 아닌 알파벳순으로 나열되어 있습니다.

git show 태그 정보를 봅니다.

git tag -a -m "", 설명이 포함된 태그를 생성합니다. -a는 레이블 이름을 지정하고 -m은 설명 텍스트를 지정합니다. 지침을 보려면 show를 사용하세요.

작업 태그

git tag -d v1.0 태그를 삭제합니다. 생성된 태그는 로컬에만 저장되고 자동으로 원격으로 푸시되지 않기 때문입니다. 따라서 잘못 입력한 태그는 로컬에서 안전하게 삭제할 수 있습니다.

git push Origin 태그를 원격으로 푸시

git push Origin --tags 원격으로 푸시되지 않은 모든 로컬 태그를 한 번에 푸시# 🎜🎜#

라벨이 원격으로 푸시된 경우. git tag -d v1.0은 먼저 로컬 태그 v1.0을 삭제합니다. git push 원본 :refs/tags/v1.0원격 태그 삭제 v1.0

Git 사용자 정의

git config --global color .ui true를 사용하면 Git이 색상을 표시하여 명령 출력이 더욱 눈길을 끌게 됩니다.

특수 파일 무시 .gitignore 파일을 만들고 무시해야 하는 파일 이름을 입력합니다. Git은 자동으로 이러한 파일을 무시합니다. 내 연구에서도 이러한 문제가 발생했습니다. 예를 들어 node_modules 파일은 무시할 수 있습니다.

파일 무시 원칙: 썸네일 등 운영 체제에서 자동으로 생성된 파일을 무시합니다. 컴파일로 생성된 중간 파일, 실행 파일 등, 즉 파일이 자동으로 생성된 경우 무시합니다. 다른 파일을 사용하면 Java 컴파일로 생성된 .class 파일과 같이 자동으로 생성된 파일을 저장소에 넣을 필요가 없습니다. 비밀번호를 저장하는 구성 파일과 같은 민감한 정보가 포함된 자체 구성 파일을 무시하세요.

무시된 파일을 강제로 제출합니다. git add -f

git check-ignore -v Git이 파일을 무시하는 이유를 확인하세요.

Git 명령에 별칭을 할당하는 것은 다소 어색합니다. 나중에 git rebase를 입력하려면 "닉네임"을 지정하고 git nb라고 부릅니다. 앞으로는 git rebase 대신 git nb를 사용할 수 있습니다.

일반적으로 사용되는 Git 명령 요약

git config --global user.name "Your name" 모든 Git 저장소를 바인딩합니다. 이름

git config --global user.email "귀하의 이메일" 모든 Git 웨어하우스가 귀하의 이메일을 바인딩하도록 합니다

git init 웨어하우스 초기화#🎜 🎜##🎜🎜 #git add . 작업공간에 있는 모든 파일을 임시저장공간에 제출

git add .// 작업공간에 있는 파일을 임시저장공간에 제출# 🎜🎜#

git commit -m "xxx" 임시 저장 영역에 있는 모든 파일을 창고 영역으로 제출하고, 임시 저장 영역은 비어 있습니다

git 원격 원본 추가 https:/ /github .com/name/name_cangku.git 로컬 창고를 원격 창고에 연결

git push -u Origin master 창고 영역의 마스터 브랜치를 원격 창고에 제출

#🎜 🎜# git push -u Origin 다른 브랜치를 원격 창고에 제출

git status를 사용하여 현재 웨어하우스의 상태 보기

git diff 파일 수정의 특정 내용# 🎜🎜#

git log는 가장 최근부터 가장 먼 것까지 커밋 기록을 표시합니다.

git clone + 복제 파일을 다운로드할 창고 주소

#🎜 🎜#git 재설정 --hard + 버전 번호 버전을 역추적하면 버전 번호는 커밋할 때 마스터를 따릅니다.

git reflog는 명령 기록을 표시합니다.

git checkout -- 명령을 실행 취소하려면 버전 라이브러리를 사용하세요. 파일이 작업 공간의 파일을 대체합니다. Git 세계에서 ctrl + z를 누른 느낌입니다

git rm이 저장소의 파일을 삭제합니다

git Branch 현재 브랜치 모두 보기

git 브랜치 브랜치 만들기

git checkout 브랜치로 전환

git merge git Branch -d 브랜치를 삭제하면 Git이 병합되지 않은 브랜치를 보호하므로 삭제에 실패할 수 있습니다.

git Branch -D + 브랜치

git log --graph 브랜치 병합 그래프 보기

git merge --no-ff 브랜치 병합 이 모드에서는 브랜치가 손실되므로 빨리 감기 모드를 비활성화합니다. 히스토리 정보

git stash 다른 작업을 삽입하면 현재 작업 사이트를 '저장'했다가 나중에 다시 시작하여 작업을 계속할 수 있습니다#🎜🎜 #

git stash list 방금 작업한 위치를 확인하세요. 저장됨"이 사라졌습니다

git stash 복원을 적용하지만 stash 콘텐츠를 삭제하지는 않습니다.

git stash drop stash 콘텐츠 삭제

git stash pop 복원할 때, stash 내용도 삭제됩니다

git 원격 원격 라이브러리의 정보를 보면 원본이 표시되며 원격 창고의 기본 이름은 Origin입니다#🎜🎜 #

git 원격 - v 더 자세한 정보 표시

git pull은 원격 웨어하우스에서 최신 커밋을 가져와 로컬로 병합합니다. 이는 git push

#🎜 🎜#git rebase가 분기된 내용을 "구성"합니다. 더 직관적으로 보이는 직선으로 히스토리를 커밋합니다

git tag 모든 태그를 보면 태그의 이전 버전을 알 수 있습니다

git tag 태그, 기본값은 HEAD입니다. 예를 들어 git 태그 v1.0

git 태그 버전 번호는 커밋

뒤에 오는 문자와 숫자의 문자열입니다.

git show 태그 정보 보기

git tag -a -m "" -a는 태그 이름을 지정하고, -m은 설명 텍스트를 지정합니다.

git tag -d 태그를 삭제합니다.

git push Origin 원격으로

git push Origin --tags 원격으로 푸시되지 않은 모든 로컬 태그를 한 번에 푸시

git push Origin :refs/tags/

git config --global color.ui true 명령 출력이 더욱 눈길을 끌게 만드는 색상을 표시합니다.

git add -f 무시된 파일 강제 커밋

git check-ignore -v Git이 파일을 무시한 이유 확인

gitbranch other

#🎜 🎜#More Git 사용 튜토리얼을 보려면

gittutorial 열을 방문하세요. https://www.php.cn/tool/git/#🎜🎜 #

위 내용은 Git 사용법 튜토리얼의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!