역사상 가장 자세한 Git 사용법 튜토리얼을 살펴 보겠습니다.

Git은 세계에서 가장 발전된 분산 버전 관리 시스템입니다. 프로젝트 복제가 매우 빠릅니다.

각 개발자는 네트워크가 없더라도 로컬 저장소에 코드를 제출할 수 있습니다. 로그 보기, 프로젝트 브랜치 생성 등

각 저장소는 무제한 브랜치를 생성할 수 있습니다. 브랜치는 완전한 디렉토리이며 이 디렉토리에는 완전한 실제 파일이 있습니다.

권장(무료): git

1.

여기에 소개되지 않은 설치 튜토리얼을 인터넷에서 검색하세요.

설치가 완료된 후 시작 메뉴에서 "Git" -> "Git Bash"를 찾아 명령줄 창과 유사한 팝업을 표시합니다. Git이 성공적으로 설치되었습니다

그런 다음 머신 정보를 설정해야 합니다. 이 머신의 모든 Git 리포지토리는 이 구성을 사용합니다

$ git config --global user.name "username"
$ git config --global user.email "email@example.com"

두 번째, 리포지토리를 만듭니다

1. 빈 디렉터리를 만듭니다(가급적 중국어를 포함하지 않음)

$ mkdir mymenu
$ cd mymenu
$ pwd
/Users/hxk/mymenu

pwd 명령은 현재 디렉터리를 표시합니다

2. 웨어하우스 초기화

git init 명령은 이 디렉터리를 git

$ git init
Initialized empty Git repository in /Users/hxk/mymenu/.git/

가 관리할 수 있는 웨어하우스로 바꿉니다.

빈 웨어하우스를 초기화하고, 웨어하우스에 더 많은 .git 디렉터리가 있습니다. 디렉토리

시스템이 자동으로 생성합니다. 유일한 마스터 브랜치

버전 관리 시스템은 텍스트 파일의 변경 사항만 추적할 수 있으며 인코딩 방법은 utf-8

3입니다. 기본 파일 작업

test.txt 파일을 만듭니다. 다음 내용:

Hello World

1. 창고에 파일 추가

$ git add readme.txt

2. 파일을 창고에 제출

$ git commit -m "a new file"

-m 이후의 입력은 제출이 성공적으로 완료되면 표시됩니다. >1개의 파일이 변경되었습니다.: 1개의 파일이 변경되었습니다(새로 추가된 readme.txt 파일).

2개의 삽입: 두 줄의 내용이 삽입됩니다(readme.txt에는 두 줄의 내용이 있습니다). 콘텐츠).

1 file changed：1个文件被改动（我们新添加的readme.txt文件）；

2 insertions：插入了两行内容（readme.txt有两行内容）。

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

如果提交的备注写错了，可以用以下命令修改刚刚提交的备注

$ git commit --amend

3、修改文件

将test.txt文件修改如下：

Hello World ABC

提交

$ git add test.txt
$ git commit -m "append ABC"

每次commit都会生成一个“快照”

4、查看历史记录

$ git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: hxk <hxk@gmail.com>
Date:   Fri July 20 21:06:15 2018 +0800

    append ABC

commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: hxk <hxk@gmail.com>
Date:   Fri July 20 20:59:18 2018 +0800

    a new file

git log显示最近到最远的提交日志，我们可以看到两次提交，最后一次是append ABC

git的版本号是用SHA1计算出来的一个16进制数

如果嫌输出信息太多，可以加上--pretty=oneline

$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append ABC
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 a new file

5、回退历史版本

$ git reset

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交1094adb...，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

回退上一版本

$ git reset --hard HEAD^
HEAD is now at eaadf4e a new file

这时再次查看历史版本

$ git log
commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: hxk <hxk@gmail.com>
Date:   Fri July 20 20:59:18 2018 +0800

    a new file

之前那个版本已经看不到了，这时如果想回到之前那个版本，需要知道版本号，git内部有个指向当前版本的head指针，将指针从当前版本指回去，所以git回退版本特别快

$ git reset --hard 1094adb7

6、查看历史命令

要是不记得刚才的版本号了，可以使用以下命令：

$ git reflog

7、查看状态

$ git status

四、工作区和暂存区

Git和SVN的一个不同之处就是有暂存区的概念

名词解释：

工作区（Working Directory）：指的是在电脑里能看到的目录，比如mymenu文件夹就是一个工作区

版本库（Repository）：.git目录，Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

git add是把需要提交的文件添加到暂存区

git commit是把暂存区的所有内容提交到当前分支

-------------------------测试一下--------------------------

在工作区新增一个testfile文本文件

先用git status查看一下状态：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   test.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    testfile

no changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，test.txt被修改了，而testfile还从来没有被添加过，所以它的状态是UntrackedGit에서 파일을 추가하려면 왜 추가 및 커밋의 두 단계가 필요합니까? commit은 한 번에 많은 파일을 제출할 수 있기 때문에 여러 파일을 여러 번 추가할 수 있습니다

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   testfile
    modified:   test.txt

제출된 설명이 잘못된 경우 다음 명령을 사용하여 수정할 수 있습니다 방금 제출한 것 Remarks

$ git status
On branch master
nothing to commit, working tree clean

3. 파일을 수정합니다

test.txt 파일을 다음과 같이 수정합니다.

$ cat test.txt
Hello World ABC
This is the second line

Submit

$ git add test.txt

모든 커밋은 "스냅샷"을 생성합니다

🎜4. log는 최신부터 최신까지 표시 커밋 로그를 보면 두 개의 커밋을 볼 수 있으며 마지막 커밋은 ABC를 추가합니다🎜🎜git의 버전 번호는 SHA1을 사용하여 계산된 16진수입니다🎜🎜출력 정보가 ​​너무 많다고 생각되면 , --pretty =oneline🎜

$ cat test.txt
Hello World ABC
This is the second line
This is the third line

🎜5를 추가할 수 있습니다. 이전 버전 롤백🎜

$ git commit -m "test add lines"

🎜우선 Git에서는 현재 버전이 어떤 버전인지 알아야 합니다. Git에서는 HEAD를 사용하여 나타냅니다. 최신 버전인 1094adb..., 이전 버전은 HEAD^, 이전 버전은 HEAD^^입니다. 물론 <이전 100개 버전의 코드>^를 100으로 쓰는 것이 계산하기 쉽기 때문에 HEAD~100으로 씁니다. 🎜🎜이전 버전으로 되돌리기🎜

$ git diff HEAD -- test.txt

🎜 이때, 과거 버전을 다시 확인하세요🎜

$ git checkout -- test.txt

🎜이전 버전은 더 이상 보이지 않습니다. 이전 버전으로 돌아가고 싶다면 버전 번호를 알아야 합니다. 은 git 내부의 현재 버전을 가리키는 포인터입니다. 헤드 포인터는 현재 버전을 가리키므로 git 롤백이 매우 빠릅니다🎜

$ git reset HEAD test.txt
Unstaged changes after reset:
M    test.txt

🎜 6. 기록 명령 보기🎜🎜지금 버전 번호가 기억나지 않으면 다음을 사용할 수 있습니다. 다음 명령: 🎜

$ rm test.txt

🎜7. 상태 보기🎜

$ git rm test.txt
$ git commit -m "remove test.txt"

🎜4. 작업 공간 및 스테이징 영역🎜🎜Git과 SVN의 한 가지 차이점은 스테이징 영역의 개념입니다🎜🎜용어 설명:🎜🎜작업 디렉터리: 예를 들어 컴퓨터 디렉터리에서 볼 수 있는 mymenu 폴더는 작업 공간입니다. 🎜🎜 저장소(Repository): .git 디렉터리 Git 저장소에는 많은 것들이 저장되어 있는데, 그 중 가장 중요한 것은 stage(또는 stage)라는 임시 저장 영역입니다. index), Git이 자동으로 생성한 첫 번째 브랜치 master, 그리고 HEAD라는 master에 대한 포인터입니다. 🎜🎜 🎜🎜git add는 제출해야 할 파일들을 임시저장공간🎜

🎜🎜git 커밋은 스테이징 영역의 모든 내용을 현재 브랜치에 제출하는 것입니다🎜🎜--------- ------ ----------테스트해 보세요--------- ------🎜🎜작업 공간에 테스트 파일 텍스트 파일을 추가하세요 🎜🎜먼저 git status를 사용하여 상태를 확인하세요. 🎜

$ git checkout -- test.txt

🎜Git에서는 test.txt< /code>는 수정되었으며 <code>testfile은 추가된 적이 없으므로 상태는 추적되지 않음입니다. 🎜🎜테스트 파일 제출 후 상태 확인하기🎜

$ git checkout -b dev
Switched to a new branch 'dev'

🎜제출 후 작업공간을 수정하지 않았다면 상태를 확인하면 작업공간이 깨끗해집니다🎜

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

🎜---------------- - ---------------테스트 종료------ -- --🎜🎜5.수정🎜🎜1.관리 수정🎜

那么，为什么说git比svn优秀呢？因为git跟踪并管理的是修改，而不是文件

修改test.txt文件内容，添加一行

$ cat test.txt
Hello World ABC
This is the second line

然后添加文件

$ git add test.txt

再次修改test.txt

$ cat test.txt
Hello World ABC
This is the second line
This is the third line

提交

$ git commit -m "test add lines"

这时我们发现，第二次的修改未提交，这是为什么呢？

第一次修改-->git add-->第二次修改-->git commit

add将工作区的修改存入暂存区，但是第二次修改并未存入暂存区，git commit只负责把暂存区的修改提交，所以正确的顺序应该是：

第一次修改 --> git add --> 第二次修改 --> git add --> git commit

提交后，查看工作区和版本库里面最新版本的区别：

$ git diff HEAD -- test.txt

2、撤销修改

1）丢弃工作区的修改 git checkout -- file（--很重要，没有--，就变成了“切换到另一个分支”的命令）：

$ git checkout -- test.txt

命令git checkout -- test.txt意思就是，把test.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是test.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是test.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

2）把暂存区的修改撤销掉（unstage），重新放回工作区 git reset HEAD <file>：

$ git reset HEAD test.txt
Unstaged changes after reset:
M    test.txt

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

3、删除文件

工作区中删除文件

$ rm test.txt

一是要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

$ git rm test.txt
$ git commit -m "remove test.txt"

二是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

$ git checkout -- test.txt

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

PS: 手动删除文件，然后使用git rm 和git add效果是一样的。

六、分支管理

1、创建与合并分支

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

------------------------------------测试开始---------------------------------------------------

1）创建分支 git branch

切换分支 git checkout

首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

2）查看分支 git branch

然后，用git branch命令查看当前分支：

$ git branch
* dev
  master

git branch命令会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，比如对test.txt做个修改，再提交，dev分支的工作完成后，我们就可以切换回master分支：

$ git checkout master
Switched to branch 'master'

切换回master分支后，再查看一个test.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

3）合并某个分支到当前分支 git merge

现在，我们把dev分支的工作成果合并到master分支上：

$ git merge dev

git merge命令用于合并指定分支到当前分支。合并后，再查看test.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

4）删除分支 git branch -d

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was b17d20e).

删除后，查看branch，就只剩下master分支了：

$ git branch
* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

2、解决冲突

创建一个新的分支feature1

$ git checkout -b feature1
Switched to a new branch 'feature1'

将test.txt修改了一下，加上“AND Simple”，在feature1分支上提交

Hello World ABC
This is the second line AND Simple

切换到master分支

$ git checkout master

在master分支上，将test.txt的最后一行加上“& Simple”，提交：

Hello World ABC
This is the second line & Simple

当两个分支都分别有了新的提交，如下图所示：

这种情况下无法进行快速合并，只能试图把各自的修改合并起来，这样有可能会造成冲突：

$ git merge feature1
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

这时我们必须手动解决冲突后再提交，git status可以查看冲突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

查看test.txt文件的内容：

Hello World ABC
<<<<<<< HEAD
This is the second line & Simple
=======
This is the second line AND Simple
>>>>>>> feature1

Git用<<<<<<<，=======，标记出不同分支的内容，我们修改如下后保存：

This is the second line and Simple

再提交

$ git add test.txt 
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

现在，master分支和feature1分支变成了下图所示：

用git log --graph --pretty=oneline --abbrev-commit可以看到分支的合并情况，包括分支合并图(--graph)、一行显示(--pretty=oneline)、提交校验码缩略(--abbrev-commit)显示：

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append ABC
* eaadf4e a new file

最后，删除feature1分支：

$ git branch -d feature1
Deleted branch feature1 (was 14096d0).

3、分支管理策略

通常，合并分支时，Git会用快速合并模式（Fast forward），但这种模式下，删除分支后，会丢掉分支信息。

如果用普通合并模式，从分支历史上就可以看出分支信息。

那么，如何使用普通合并模式呢？我们可以用--no-ff参数

$ git merge --no-ff -m "merge with no-ff" dev

不使用Fast forward模式，merge后就像这样：如下图所示：

分支策略

master分支是最稳定的，只能用于发布新版本，平时不能在上面进行开发，要在新建的分支上进行开发，比如dev，这时dev是不稳定的，到产品1.0发布时，将dev分支和master分支合并，在master分支上发布1.0版本。

所以团队合作的分支看起来就像这张图一样：

4、bug分支

修复bug时，我们会创建一个bug分支进行修复，修复完合并，删除分支。

如果手头上有未完成的工作，先把工作现场git stash一下：

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

查看下工作区是否干净

$ git status

等bug修复完分支删除后，我们先查看下stash

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge

恢复工作现场

1）用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除

可以多次stash，恢复指定的stash；

$ git stash apply stash@{0}

2）用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop

5、Feature分支

开发一个新功能，需要新建一个分支。

如果这个功能还未合并就要取消，要使用-D强行删除

$ git branch -D 分支名

6、多人协作

当你从远程克隆时，git自动把本地master分支和远程master分支对应起来，远程仓库默认名为origin

1）查看远程库的信息

$ git remote

查看远程库的详细信息

$ git remote -v

2）推送分支

将本地master分支推送到远程库

如果不推送到远程，本地分支对于其它人就是不可见的

$ git push origin master

3）抓取分支

如果本地分支推送到远程库的文件有冲突，推送失败，我们就得先从远程库中抓取最新的提交合并到本地，解决冲突再提交。

$ git pull

如果git pull报错：没有指定本地分支与远程分支的链接，我们就要手动设置一下

git branch --set-upstream-to=origin/<远程分支名> 本地分支名

4）Rebase

rebase操作可以把本地未push的分叉提交历史整理成直线；

目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

$ git rebase

和merge的对比示意图如下：

merge-->

rebase-->

七、标签管理

切换到需要打标签的分支上

1）新建一个标签（默认为HEAD，也可以指定一个commit id）

创建带有说明的标签，用-a指定标签名，-m指定说明文字

$ git tag <标签名>
$ git tag <标签名> <commit id>
$ git tag -a <标签名> -m "备注"

2）查看标签

标签不是按时间顺序列出，而是按字母排序的。

git tag查看所有标签，用git show 标签名查看指定的某个标签信息

$ git tag
$ git show <标签名>

PS：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

3）删除标签

创建的标签都只存储在本地，不会自动推送到远程，所以打错的标签可以在本地安全删除；

$ git tag -d <标签名>

如果标签已经推送到远程，要先从本地删除，再从远程删除

$ git tag -d <标签名>
$ git push origin :refs/tags/<标签名>

4）推送标签到远程

推送某个标签到远程 git push origin <tagname>

推送全部尚未推送到远程的本地标签 git push origin --tags

$ git push origin <标签名>
$ git push origin --tags

以上。

To be continued...

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