Git の基本的な一般的なコマンドと概要

Git の基本的な一般的なコマンドと概要

1. リポジトリを作成する

# 初始化版本库（随后文件夹会生成一个.git的文件夹，是git的版本库）
git init

# 初始化git信息
git config --global user.name '用户名'
git config --global user.email '邮箱地址'

2. 作業エリアおよび一時保管エリア

Git 制御システムは、作業領域と一時記憶領域の 2 つの概念に分かれています。ワークスペースは、このプロジェクトによって作成されたローカル フォルダーです。gitコマンド、ワークスペース.gitは多くのものを含むフォルダーを生成します。その中で最も重要なものは とstage呼ばれる、最初のフォルダーがあります。 Git が自動的に作成したブランチmasterと、そのブランチmasterへのHEAD。

ファイルを Git リポジトリに追加するときは、次の 2 つの手順で行います。

ステップ 1:git addコマンドファイルの変更を一時記憶領域に追加します。

ステップ 2:git commitコマンド一時記憶領域のすべての内容を現在のブランチに送信します。

3. ファイルを追加して送信する

# 将readme.txt文件添加到暂存区
git add readme.txt
# 将所有的文件添加到暂存区
git add . 

# 将暂存区的所有文件提交到本地版本库中
git commit -m '提交时的备注'

4. 変更を元に戻す

# 查看当前状态
git status

$ git status
On branch master
# 还未添加到暂存区时的状态
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt
        
$ git status
# 添加到暂存区后的状态（待提交）
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt


# 撤销工作区的修改
# 比如：在readme.txt文件中，修改了某些内容，但还未将文件添加到暂存区中，若此时想放弃本次修改的内容，则使用以下命令即可放弃修改，readme.txt文件中的内容就会恢复到修改内容之前
git checkout -- readme.txt 
或 
git restore readme.txt （新版本Git，建议使用）

# 撤销暂存区的修改
# 比如：在readme.txt文件中，修改了某些内容，并且将文件添加到了暂存区中，若此时想放弃本次添加到暂存区中的文件，则使用以下命令即可放弃添加，暂存区会恢复到添加文件之前
git reset HEAD readme.txt
或 
git restore --staged readme.txt（新版本Git，建议使用）

5. ファイルを削除する

# 1.本地删除readme.txt文件
rm -f readme.txt

# 2.将删除的文件提交到暂存区
git add readme.txt
或
git rm readme.txt

# 3.提交到本地仓库
git commit -m '删除readme.txt文件'

# 若本地误删除某个文件，但未提交到本地版本库，则可以使用上节所述的撤销修改命令来恢复文件（删除文件本身也是一种修改）
git restore 文件名
git restore --staged 文件名

6. バージョンのロールバック

# 查看提交的日志
git log 

$ git log
# 下面的字符串表示提交的版本号
commit 45655a0a6041eaf6190f6c279b81096f9bef04f9 (HEAD -> master) 
Author: 别回头丶 <[email protected]>
Date:   Wed Jan 12 14:02:12 2022 +0800

    第二次提交

commit 121d79b208a791180b621cc14da33c32c6ef0244
Author: 别回头丶 <[email protected]>
Date:   Wed Jan 12 13:15:11 2022 +0800

    第一次提交
    
# 以图表的方式展示日志
git log --graph

$ git log --graph
* commit 45655a0a6041eaf6190f6c279b81096f9bef04f9 (HEAD -> master) 
| Author: 别回头丶 <[email protected]>
| Date:   Wed Jan 12 14:02:12 2022 +0800
|
|     第二次提交
|
* commit 121d79b208a791180b621cc14da33c32c6ef0244
| Author: 别回头丶 <[email protected]>
| Date:   Wed Jan 12 13:15:11 2022 +0800
|
|     第一次提交

# 查看操作日志
git reflog

$ git reflog
# 首位的字符串表示版本号（版本号的前几位）
45655a0 (HEAD -> master) HEAD@{
    
    0}: commit: 第二次提交
121d79b HEAD@{
    
    1}: commit (initial): 第一次提交
  
 
# 版本回退
# 首先，要进行版本回退，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新一次的
# 提交45655a0...，而上一个版本就是HEAD^，上上一个版本就是HEAD^^，往上100个版本写100个^比较容易写不
# 过来，所以写成HEAD~100。

git reset --hard 指定的版本(使用HEAD或者版本ID)

# 回退到上一个版本
git reset --hard HEAD^

# 回退到指定的版本
git reset --hard 45655a0

セブン、遠隔倉庫

# 本地版本库关联远程版本库
git remote add origin https://gitee.com/LLS312885991/test.git

# 将本地仓库中的当前分支推送到远程仓库中所对应的分支
# 若多人协作时，有其他开发者先于自己push到了远程仓库，则自己先要pull拉取最新的提交，并且在本地合并之
# 后，才能push成功
git push
git push origin master
git push origin dev

# 由于远程仓库是空的，所以我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推# 送到远程新的master分支上，还会把本地的master分支和远程的master分支关联起来，这样在以后的推送或者拉
# 取时就可以简化命令，直接使用 git push 或者 git pull
git push -u origin master

# 拉取远程仓库的代码同步到本地仓库
git pull

# 查看关联的远程仓库信息
git remote -v

$ git remote -v
origin  https://gitee.com/LLS312885991/test.git (fetch)
origin  https://gitee.com/LLS312885991/test.git (push)

# 解除本地仓库与远程仓库的关联绑定
git remote rm origin

# 克隆远程仓库到本地
git clone https://gitee.com/LLS312885991/test.git

8. 支店管理

ブランチの役割は非常に強力で、複数の人が互いに干渉することなく作業および開発する場合、全員が独自の独立した開発スペースを確保できるようになります。一般的に複数人で開発する場合、まず各人が自分のブランチを作成して開発を行い、開発が完了したらメインブランチにマージし、最後に自分のブランチを削除します。

# 创建分支
git branch 分支名称
git branch dev

# 查看所有分支（*代表当前分支）
git branch

$ git branch
  dev
* master

# 切换到dev分支
git switch dev

$ git switch dev
Switched to branch 'dev'

# 创建并切换到dev分支
git switch -c dev

$ git switch -c dev
Switched to a new branch 'dev'

# 将dev分支上的内容合并到当前分支（此命令只能简单合并，即两个分支上所修改的内容无冲突）
git merge dev

# 删除dev分支
git branch -d dev

# 合并冲突（即两个分支上修改同一个文件，且修改的内容不一致时，会出现合并冲突，此时需要手动解决冲突）
$ git merge dev
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt # 显示合并冲突，且告知是在a.txt文件中有冲突
Automatic merge failed; fix conflicts and then commit the result.

$ cat a.txt 
<<<<<<< HEAD # 显示的是当前分支上，a.txt中修改的内容
hello world! liulusheng
=======
hello world! dev # 显示的是dev分支上，a.txt中修改的内容
>>>>>>> dev

$ vim a.txt
hello world! liulusheng # 手动解决冲突，修改为需要保留的内容

$ git add a.txt # 再添加该文件到暂存区

$ git commit -m '合并冲突' # 再提交该文件到版本库即可
[master ceeba28] 合并冲突

# 使用git log也可以查看合并情况，--graph表示以图表的方式展示
git log --graph

$ git log --graph
*   commit ceeba28f86befa755d72d61155e3a4bb95d04bb3 (HEAD -> master, origin/master)
|\  Merge: f74d466 6aaee45
| | Author: 别回头丶 <[email protected]>
| | Date:   Wed Jan 12 18:29:17 2022 +0800
| |
| |     合并冲突
| |
| * commit 6aaee45e1e0838a0f8b9a1d0ab368dddf030e41e (dev)
| | Author: 别回头丶 <[email protected]>
| | Date:   Wed Jan 12 18:22:19 2022 +0800
| |
| |     dev分支上修改a.txt
| |
* | commit f74d4662153a4a665e638352df528c3c9cb3bdbd
|/  Author: 别回头丶 <[email protected]>
|   Date:   Wed Jan 12 18:21:49 2022 +0800
|
|       master分支上修改a.txt
|

知らせ: Git がブランチを自動的にマージできない場合は、まず競合を解決する必要があります。競合を解決した後、再度送信するとマージが完了します。競合を解決するには、Git とのマージに失敗したファイルを必要なコンテンツに手動で編集し、送信します。

ナイン、バグ支店

ソフトウェア開発において、BUG は一般的な食べ物のようなものです。BUG では修正する必要がありますが、Git ではブランチが非常に強力であるため、各 BUG は新しい一時ブランチによって修正でき、修復後にブランチがマージされ、一時ブランチが削除されます。

しかし、コードネーム 101 のバグを修正するタスクを受け取った場合、当然のことながら、それを修正するためのブランチを作成したいと思うでしょう。しかしissue-101、待て、現在行われている作業はコミットされていません。コミットしたくないからではありません。コミットする必要がありますが、dev問題は作業が途中であり、まだ送信できないことです。完了までに 1 日かかると推定されています。ただし、バグは 2 時間以内に修正する必要があります。どうすればよいですか?

幸いなことに、Git には、stash現在の作業サイトを「保存」し、バグの解決後にサイトを復元して作業を継続できる機能も提供されています。

# 比如，新建了一个b.txt文件，并且添加到了暂存区，但未提交到版本库中。查看此时状态
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b.txt

# 将当前分支上的工作现场储存起来
git stash

# 再查看状态
$ git status
On branch master
nothing to commit, working tree clean

# 查看所有stash工作现场
git stash list

$ git stash list
stash@{
    
    0}: WIP on master: 76f2c95 合并冲突
stash@{
    
    1}: WIP on master: 76f2c95 合并冲突

# 恢复最近一次的工作现场
git stash apply (恢复现场，但恢复后，stash的内容不会删除，需要手动删除)
$ git stash apply
On branch dev
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b.txt

git stash pop (恢复现场，并且会删除对应的stash内容)
$ git stash pop
On branch dev
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   b.txt

Dropped refs/stash@{
    
    0} (f89d3263c666988318456ba3a0676213920af788)

# 恢复指定的工作现场
git stash apply stash@{
    
    1}

# 删除最近一次的工作现场
git stash drop

# 删除指定的工作现场
git stash drop stash@{
    
    1}

10. タグ管理

バージョンをリリースする場合、通常、最初にリポジトリにタグ（タグ）を付けます。これにより、タグを付けた時点のバージョンが一意に決定されます。将来的には、タグ付きバージョンを取得することは、タグ付けの時点での履歴バージョンを取得することになります。したがって、タグはリポジトリのスナップショットでもあります。标签実際には、ある に対応しており、の関係に相当することcommit idが分かります。标签和版本号域名和IP

# 在当前分支上创建标签（标签默认是打在最新提交的commit上）
git tag 标签名称
git tag v1.0

# 在指定commit上创建标签
git tag 标签名称 提交ID
git tag  v2.0  45655a0

# 创建带说明信息的标签
git tag -a 标签名称 -m 说明信息 

# 查看当前分支上的所有标签
git tag

# 查看对应的标签信息
git show 标签名称
git show  v1.0

# 删除对应的标签
git tag -d 标签名称
git tag -d  v1.0

# 推送指定的标签到远程仓库
git push origin 标签名称
git push origin v1.0

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.2]
To https://gitee.com/LLS312885991/test.git
 * [new tag]         v1.0 -> v1.0

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

# 删除远程仓库的标签
# 1. 先删除本地仓库的标签
git tag -d v1.0

# 2. 再从远程仓库中删除
git push origin :refs/tags/v1.0