다니엘이 정리한 Git 사용법은 너무나 실용적이다

Git이란 무엇입니까

공식 단어: Git은 무료 오픈 소스 분산 버전 관리 시스템으로 설계되었습니다. 소규모 프로젝트부터 대규모 프로젝트까지 빠르고 효율적으로 처리할 수 있습니다.

모든 ​​파일 변경 사항을 자동으로 기록하는 데 도움이 될 뿐만 아니라 동료들이 편집에 공동 작업을 할 수도 있으므로 유사한 파일을 직접 관리할 필요도 없고, 통과할 필요도 없습니다. 주변에 파일이 있습니다. 특정 변경 사항을 보려면 소프트웨어를 살펴보기만 하면 됩니다.

Git을 배워야 하는 이유

면접에서 물어보세요. 면접을 처리할 수 있습니다.

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

제 생각에는 Git은 오늘날 모든 프로그래머가 마스터해야 하는 것이며, 향후 동료와 함께 프로젝트를 개발할 때 반드시 사용해야 하는 것입니다. Git 명령을 능숙하게 사용하면 개발 효율성을 높일 수 있습니다.

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"->"Preferences" 메뉴를 선택한 다음 찾아보세요. 팝업 창에서 "다운로드"를 선택하고 "명령줄 도구"를 선택한 후 "설치"를 클릭하면 설치가 완료됩니다.

warehouse

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

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

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

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

제가 가장 자주 사용하는 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 창고 영역의 파일을 원격 창고로 제출합니다.

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

관련 권장사항: "php 입문 튜토리얼"

GitHub에 제출

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

git 초기화는 이 파일을 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

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

解决合并分支问题

이런 상황이 있다고 가정해 보겠습니다. 다른 브랜치는 커밋되었지만 이때 포인터는 다시 마스터를 가리키며, 마스터는 병합되지 않고 git add/commit이 제출됩니다. 이런 식으로 충돌이 발생하고, 메인 브랜치의 마스터 파일 내용이 다른 브랜치의 내용과 다르다. 병합할 수 없습니다! 따라서 파일 내용을 수정하여 일관성을 유지하세요.

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 remote 원격 라이브러리의 정보를 볼 때, 원격 창고의 기본 이름은 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 태그 태그, 기본값은 HEAD입니다. 예를 들어 git tag v1.0

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

commt ID가 du2n2d9인 경우 git tag v1.0 du2n2d9를 실행하면 이 버전이 v1.0으로 표시됩니다.

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 Origin :refs/tags/v1.0Delete 원격 태그 v1.0

Customize 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 "Your email" Let Bind 모든 Git 리포지토리를 이메일 주소로

git init로 리포지토리 초기화

git add 작업 공간의 모든 파일을 임시 저장 영역에 제출

git add .// 작업 공간에서 < 변경 ;file> 임시 저장 영역에 파일 제출

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 Reset -- hard + 버전 번호는 커밋 시 마스터를 따릅니다.

git reflog는 명령 기록을 표시합니다. -- 작업공간의 파일을 저장소의 파일로 바꿉니다. 마치 Git 세계에서 Ctrl + Z를 누르는 것 같은 느낌이 듭니다

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

git 브랜치 현재 브랜치 모두 보기

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 apply는 복원하지만 숨김 콘텐츠를 삭제하지는 않습니다.

git stash drop은 stash 내용을 삭제합니다

git stash pop은 복원 중에 stash 내용을 삭제합니다

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

git입니다. remote -v는 더 자세한 정보를 표시합니다

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

git rebase는 분기된 내용을 취합니다. 제출 기록은 직선으로 "구성"됩니다. 더 직관적이네요

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

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

git 태그 버전 번호를 태그하세요. 버전 번호는 커밋

git show information

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

위 내용은 다니엘이 정리한 Git 사용법은 너무나 실용적이다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!