Jetons un coup d'œil au didacticiel d'utilisation de Git le plus détaillé de l'histoire

Git est le système de contrôle de version distribué le plus avancé au monde. Le clonage d'un projet est très rapide

Chaque développement peut être cloné à partir d'un référentiel local principal. , même s'il n'y a pas de réseau, vous pouvez soumettre du code à l'entrepôt local, afficher les journaux, créer des branches de projet, etc.

Chaque référentiel peut créer un nombre illimité de branches, et une branche est un répertoire complet, et ce Le le répertoire contient des fichiers réels complets

Recommandé (gratuit) : git

1. Installation

Recherchez en ligne des didacticiels d'installation, Je ne le présenterai pas ici

Une fois l'installation terminée, recherchez "Git" -> "Git Bash" dans le menu Démarrer et faites apparaître quelque chose de similaire à une fenêtre de ligne de commande, ce qui signifie que Git est installé avec succès

Ensuite, vous devez définir les informations de la machine. Tous les référentiels Git sur cette machine utiliseront cette configuration

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

2 Créer un référentiel

1. répertoire (il est préférable de ne pas contenir de chinois)

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

la commande pwd affiche le répertoire courant

2. Initialiser l'entrepôt

La commande git init transforme ce répertoire en entrepôt qui peut être géré par git

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

Un entrepôt vide est initialisé, et il y a plus de répertoires .git dans le répertoire

Le système crée automatiquement la seule branche principale

La Le système de contrôle de version ne peut suivre que les modifications apportées aux fichiers texte et la méthode d'encodage est utf -8

3 Opérations de base sur les fichiers

Créez un fichier test.txt avec le contenu suivant :

.

Hello World

1. Ajouter des fichiers à l'entrepôt

$ git add readme.txt

2. Soumettez le fichier à l'entrepôt

$ git commit -m "a new file"

-m est entré après la description de cette soumission. , il s'affichera :

1 file changed : 1 fichier a été modifié (nous avons nouvellement ajouté le fichier readme.txt

2 insertions : Deux lignes de contenu sont insérées (readme) ; .txt a deux lignes de contenu).

Pourquoi Git demande-t-il add，commit d'ajouter un fichier en deux étapes ? Parce que commit peut soumettre plusieurs fichiers à la fois, vous pouvez add différents fichiers plusieurs fois

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

Si la remarque soumise est fausse, vous pouvez utiliser la commande suivante pour modifier la remarque qui vient d'être soumise

$ git commit --amend

3. Modifiez le fichier

Modifiez le fichier test.txt comme suit :

Hello World ABC

Soumettre

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

Chaque commit générera un "instantané"

4. Afficher l'historique

$ 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

le journal de git affiche le journal de soumission le plus récent au plus éloigné. Nous pouvons voir deux soumissions, la dernière est ajoutée à ABC

Le numéro de version de git est calculé à l'aide. SHA1 Le nombre hexadécimal résultant

Si vous pensez que les informations de sortie sont trop nombreuses, vous pouvez ajouter --pretty=oneline

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

5. Restaurer la version historique

$ git reset

. Tout d'abord, Git doit savoir quelle version est la version actuelle. Dans Git, HEAD est utilisé pour représenter la version actuelle, qui est le dernier commit 1094adb..., la version précédente est HEAD^ et la version précédente est <🎜. >, bien sûr en montant Il est plus facile de compter 100 versions de 100 HEAD^^, donc ça s'écrit ^. HEAD~100

Revenir à la version précédente

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

Vérifiez à nouveau la version historique

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

    a new file

La version précédente n'est plus visible. Si vous souhaitez revenir à la version précédente, vous devez connaître le numéro de version, il y a un pointeur de tête pointant vers la version actuelle à l'intérieur de git, qui pointe le pointeur vers l'arrière de la version actuelle, donc git annule la version très rapidement

$ git reset --hard 1094adb7

6. Voir l'historique commandes

Sinon N'oubliez pas le numéro de version tout à l'heure, vous pouvez utiliser la commande suivante :

$ git reflog

7. Vérifiez l'état

$ git status

4. Espace de travail et zone de préparation

Une différence entre Git et SVN La seule différence est qu'il y a la notion de zone de stockage temporaire

Explication des termes :

Répertoire de travail : fait référence au répertoire que l'on peut voir sur l'ordinateur. Par exemple, le dossier mymenu est un répertoire de travail. Zone

Dépôt : répertoire .git Il y a beaucoup de choses stockées dans le référentiel de Git, dont la plus importante est la zone de stockage temporaire appelée stage (. ou index), et Git nous fournit La première branche

est automatiquement créée, et un pointeur pointant vers master est appelé master. HEAD

git add consiste à ajouter les fichiers qui doivent être soumis à la zone de stockage temporaire

git commit consiste à tout ajouter le contenu de la zone de stockage temporaire Soumettre à la branche actuelle

----------------------Tester-------- ----- -------------

Ajoutez un fichier texte de test dans l'espace de travail

Utilisez

d'abord pour vérifier l'état : 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 nous dit très clairement que

a été modifié, mais test.txt n'a jamais été ajouté, son statut est donc testfile. Untracked

Soumettez le fichier de test puis vérifiez le statut

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

    new file:   testfile
    modified:   test.txt

Si vous n'avez pas modifié l'espace de travail après la soumission, vérifiez le statut et l'espace de travail est propre

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

---- - --------------------------Fin du test-------------------------- ------ ---------------

5. Modification

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...

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!