git init --用于在本地创建一个新的 Git 仓库的命令
-
git init是用于在本地创建一个新的 Git 仓库的命令。执行该命令后，Git 会在当前目录下生成一个.git文件夹，将该目录及其所有子文件夹变成一个 Git 仓库，能够进行版本控制。基本用法
git init
-
在当前目录初始化一个 Git 仓库。
git init <directory>
-
在指定的目录中创建一个新的 Git 仓库。目录可以是一个已存在的文件夹，也可以是新建的。 例如：
git init my_project
运行后效果
-
创建
.git文件夹 在初始化的目录下会生成一个隐藏的.git文件夹，包含 Git 版本控制所需的所有文件和配置。 -
目录成为 Git 仓库 执行
git init后，当前目录被视为一个 Git 仓库，可以使用 Git 命令（如git add、git commit、git push等）对文件进行版本控制。 -
设置默认分支 现代 Git 版本会自动将主分支命名为
main。不过，如果你的 Git 设置中有不同的默认分支名称，它将以该名称创建。
典型应用场景
-
创建新项目：在开发一个新项目时，通过
git init来开始对项目文件进行版本控制。 -
将已有项目纳入版本控制：对于一个未被 Git 控制的现有项目文件夹，使用
git init可以快速将其变为 Git 仓库。
示例
# 在当前目录初始化 Git 仓库 git init # 在指定目录 my_project 中创建一个 Git 仓库 git init my_project # 初始化后查看仓库状态 git status
注意事项
-
不可重复初始化：
git init只需在新建项目或首次将文件夹转为仓库时使用，重复运行不会对现有.git文件夹产生影响，但通常也没有必要。 -
关联远程仓库：初始化本地仓库后，若要同步到远程仓库，可以使用
git remote add origin <remote-url>命令进行关联，然后再进行git push等操作。
总结
-
git init：在当前目录初始化一个 Git 仓库。 -
git init <directory>：在指定目录下创建一个新的 Git 仓库。 -
初始化后会创建
.git文件夹，使目录成为 Git 仓库并可进行版本控制。
-
git add 与 git commit
-
git add和git commit是 Git 中的两个核心命令，用于将更改添加到代码库中：1.
git add-
作用：将更改（新增、修改、删除的文件）添加到暂存区（staging area）。
-
用途：当在项目中进行更改后，使用
git add将文件加入到暂存区，准备进行提交。 -
示例：
git add <file> # 添加指定文件到暂存区 git add . # 添加当前目录下的所有更改到暂存区 git add -A # 添加所有更改到暂存区，包括已删除的文件
-
说明：
git add只是将更改暂时放入暂存区，并未正式提交到仓库。要让这些更改永久保存，还需要使用git commit命令。
2.
git commit-
作用：将暂存区的更改提交到 Git 仓库中，形成一个新的提交（commit）。
-
用途：在添加文件到暂存区后，用
git commit提交更改，并为这次提交添加一条说明或注释。 -
示例：
git commit -m "Add a descriptive commit message" # 提交并附带说明 git commit -am "Add and commit in one step" # 将已跟踪文件的更改添加到暂存区并提交
-
说明：
git commit会把当前暂存区的所有内容作为一个快照保存到版本历史中。提交后，更改会被记录，并可以在需要时回溯到该版本。
总结
-
git add把更改添加到暂存区，准备提交。 -
git commit把暂存区的内容提交到仓库并生成历史记录。
-
git log --查看 Git 仓库的提交历史
-
git log命令用于查看 Git 仓库的提交历史。通过它可以看到各个提交的详细信息，例如提交者、提交时间、提交说明等。git log可以使用多种选项来调整输出内容，便于更高效地浏览和过滤提交记录。基本用法
git log
该命令会列出仓库中的所有提交记录，包括以下信息：
-
提交 ID（SHA 值）
-
作者
-
日期
-
提交说明
常用选项
-
-n <number>：限制显示的提交条数git log -n 5 # 显示最近的 5 次提交
-
--oneline：以简洁的一行格式显示提交记录，每个提交只显示 SHA 的前几位和提交信息git log --oneline
-
--graph：以图形化方式展示提交历史的分支和合并情况git log --oneline --graph
-
--author=<name>：过滤显示特定作者的提交git log --author="username"
-
--since和--until：显示从指定日期开始或结束的提交git log --since="2023-01-01" # 从指定日期之后的提交 git log --until="2023-01-01" # 在指定日期之前的提交
-
-p：显示每个提交的详细变更内容（即 diff）git log -p
-
--stat：显示每个提交中更改的文件和行数统计信息git log --stat
示例
组合多个选项可以更方便地查看提交记录，例如：
git log --oneline --graph --author="username" -5
以上命令会显示该作者最近的 5 条提交记录，简洁、直观。
-
git reset --撤销重置
-
git reset是 Git 中用于撤销更改和重置提交记录的命令。它可以用于更改当前分支的提交历史、撤销暂存区的更改，或取消对工作目录的更改。git reset的操作级别取决于指定的参数，可以是文件级别或提交级别。基本用法
git reset [options] [target]
git reset常用选项-
--soft：仅重置提交记录，保留暂存区和工作目录的更改-
用途：想要撤销一次或多次提交，但保留更改内容以便重新提交。
-
示例：
git reset --soft HEAD~1 # 撤销上一次提交，但保留更改在暂存区
-
-
--mixed（默认）：重置提交记录和暂存区，保留工作目录的更改-
用途：想要撤销提交，并将更改放回到工作目录（未暂存的状态）。
-
示例：
git reset --mixed HEAD~1 # 撤销上一次提交，取消暂存，但保留更改在工作目录
-
-
--hard：重置提交记录、暂存区和工作目录-
用途：彻底删除指定提交后的所有更改。
-
注意：
--hard操作是不可逆的，会丢失未提交的更改。 -
示例：
git reset --hard HEAD~1 # 撤销上一次提交，并丢弃所有更改
-
其他常见用法
-
重置到指定的提交
git reset --hard <commit-hash> # 将当前分支重置到指定提交
-
撤销暂存区的更改
-
如果只想从暂存区中移除某个文件的更改，可以使用
git reset <file>。
git reset <file> # 取消暂存指定文件的更改
-
-
取消所有暂存区的更改
git reset # 将所有文件从暂存区移除，但保留更改在工作目录
总结
-
git reset --soft：撤销提交，保留更改在暂存区。 -
git reset --mixed：撤销提交并取消暂存，保留更改在工作目录。 -
git reset --hard：彻底撤销提交、暂存和工作目录的更改（不可恢复）。
-
git reflog --查看本地仓库中分支或引用的所有历史变更的命令
-
git reflog是 Git 中用于查看本地仓库中分支或引用的所有历史变更的命令。即使使用了git reset --hard或git checkout等命令导致提交丢失，git reflog也可以帮助找回“丢失”的提交记录。用途
-
找回丢失的提交：当意外重置或删除某个提交时，可以通过
git reflog找到对应的提交哈希，进行恢复。 -
追踪 HEAD 的变更：记录所有指向
HEAD的变更，包括reset、checkout、merge等操作。 -
查看本地分支的变更历史：每次更改分支指针的位置都会在
reflog中记录下来，方便追踪分支历史。
基本用法
git reflog
该命令将显示所有分支指针移动的记录，包括提交哈希、操作说明、时间和提交信息。例如：
f6a1fbe (HEAD -> main) HEAD@{0}: commit: Fix bug in user login 3b7e9f0 HEAD@{1}: reset: moving to HEAD~1 6a8e123 HEAD@{2}: checkout: moving from feature-branch to main 9f8e4cd HEAD@{3}: commit: Add new feature常用操作
-
恢复到某个特定的提交
使用
reflog查找到想要恢复的提交哈希，然后用git reset或git checkout回到该提交。git reset --hard <commit-hash>
-
指定
HEAD的历史位置HEAD@{n}语法可以用于直接指定HEAD在某个位置时的状态，n是reflog中的相对位置。git reset --hard HEAD@{2} # 恢复到 HEAD@{2} 的状态 -
清理 Reflog
为了节省空间，可以定期清理
reflog。例如，删除超过 90 天的reflog记录：git reflog expire --expire=90.days git gc --prune=now # 删除不可达的对象
总结
-
git reflog是用于追踪分支变更历史的命令，特别是在误操作或丢失提交时非常有用。 -
通过
reflog可以找到提交哈希，使用git reset或git checkout进行恢复。
-
git status --显示 Git 仓库的当前状态
-
git status命令用于显示 Git 仓库的当前状态，包括哪些文件已更改、哪些文件在暂存区中，哪些文件没有被跟踪，以及是否有尚未提交的更改。它是了解工作目录和暂存区状态的关键命令。基本用法
git status
执行
git status后，会显示：-
Untracked files：未被 Git 跟踪的文件（即新创建但尚未添加到暂存区的文件），可以用
git add <file>将其添加到暂存区。 -
Changes not staged for commit：已修改但尚未添加到暂存区的文件，需要用
git add <file>暂存这些更改。 -
Changes to be committed：已暂存的文件（已被
git add），这些文件将包含在下次提交中。 -
Current branch：当前所在的分支名称，以及与远程分支的同步状态（例如，有无提交尚未推送到远程仓库等）。
常见信息
-
“working tree clean”：表示没有任何未提交或未暂存的更改。
-
Untracked files：未被 Git 跟踪的文件，Git 不会包含这些文件，除非使用
git add将它们添加到暂存区。 -
Changes not staged for commit：文件已被修改，但未添加到暂存区。若想将这些更改包含在下次提交中，需使用
git add命令。 -
Changes to be committed：文件已被添加到暂存区，准备进行提交。
示例
执行
git status命令后，可能会看到以下输出：On branch main Your branch is ahead of 'origin/main' by 1 commit. (use "git push" to publish your local commits) Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: file1.txt 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: file2.txt Untracked files: (use "git add <file>..." to include in what will be committed) file3.txt
解释
-
Changes to be committed部分中的file1.txt已暂存，等待提交。 -
Changes not staged for commit部分中的file2.txt已修改，但尚未暂存。 -
Untracked files部分中的file3.txt尚未被 Git 跟踪。
-
git diff --显示工作目录(工作区)、暂存区（stage）和已提交文件（分支）之间的差异
-
git diff命令用于显示工作目录、暂存区和已提交文件之间的差异，帮助开发者检查代码更改并了解哪些部分被修改了。用法及常见选项
-
查看工作目录与暂存区之间的差异：
git diff
-
此命令显示当前工作目录中的更改内容，即尚未被
git add暂存的部分。
-
-
查看暂存区与最后一次提交之间的差异：
git diff --cached
-
此命令显示已暂存但还未提交的内容，即使用
git add后但未git commit的内容。
-
-
查看工作目录与最后一次提交之间的差异：
git diff HEAD
-
此命令显示当前工作目录中的更改和最后一次提交之间的差异，包括暂存和未暂存的更改。
-
-
查看两个提交之间的差异：
git diff <commit1> <commit2>
-
例如，
git diff abc123 def456会显示abc123和def456提交之间的差异。
-
-
查看特定文件的差异：
git diff <file>
-
仅显示工作目录中某个文件的未暂存更改。
-
示例输出
git diff的输出通常类似以下格式：diff --git a/file.txt b/file.txt index d3adb33f..5f1b94a 100644 --- a/file.txt +++ b/file.txt @@ -1,3 +1,3 @@ -Line 1 +Modified Line 1 Line 2 -Line 3 +Modified Line 3
-
-表示删除的行（红色），即在工作目录中删除的内容。 -
+表示新增的行（绿色），即在工作目录中新添加的内容。
常用选项总结
-
git diff：查看工作目录中的未暂存更改。 -
git diff --cached：查看已暂存的更改。 -
git diff HEAD：查看工作目录和最后一次提交之间的所有差异。 -
git diff <commit1> <commit2>：对比两次提交之间的差异。
-
git checkout -- 用于切换分支、恢复文件内容到某个特定的状态以及创建新分支。
-
git checkout是一个多用途的 Git 命令，主要用于切换分支、恢复文件内容到某个特定的状态以及创建新分支。用法及常见操作
-
切换分支
git checkout <branch-name>
-
切换到已有的分支。例如，
git checkout main将切换到main分支。 -
若在切换分支前没有提交当前更改，Git 可能会提示需要提交或暂存更改，否则无法切换分支。
-
-
创建并切换到新分支
git checkout -b <new-branch-name>
-
例如，
git checkout -b feature-branch会创建一个名为feature-branch的新分支，并切换到该分支。
-
-
恢复文件到指定的提交状态
git checkout <commit-hash> -- <file-path>
-
将文件恢复到特定提交的状态。
commit-hash是指要恢复到的提交的哈希值，file-path是文件路径。例如，git checkout abc123 -- file.txt会将file.txt恢复到abc123版本的内容。
-
-
撤销未提交的更改
git checkout -- <file>
-
该命令会丢弃指定文件在工作目录中的未暂存更改，将其恢复到上一次提交的状态。
-
注意：这一操作无法撤销，所以谨慎使用！
-
-
切换到某个特定的提交（分离 HEAD 状态）
git checkout <commit-hash>
-
该操作将
HEAD指针直接指向某次提交（不是某个分支的最新提交），进入“分离 HEAD”状态。这时，所有更改不会关联到任何分支上。 -
例如，
git checkout abc123会将工作目录切换到哈希为abc123的提交，但不更新当前分支指针。
-
总结
-
git checkout <branch>：切换到指定分支。 -
git checkout -b <new-branch>：创建并切换到新分支。 -
git checkout <commit> -- <file>：恢复文件到指定提交的状态。 -
git checkout -- <file>：撤销文件的未暂存更改，将其恢复到上一次提交状态。 -
git checkout <commit>：切换到某次提交，进入分离 HEAD 状态。
-
git checkout 与git reset的区别
-
git checkout和git reset是 Git 中两个重要的命令，它们都可以用于撤销更改、回退到特定提交状态，但它们的用途和效果有所不同：1.
git checkout-
主要作用：用于切换分支、恢复文件状态或进入特定的提交状态（“分离 HEAD”状态）。
-
应用场景：
-
切换分支：在不同分支间切换工作。
-
恢复文件：可以恢复文件到上一次提交或某次特定提交的状态。
-
进入特定提交的分离状态：允许查看某次历史提交的代码，但不修改分支指针。
-
-
不改变分支的提交历史：
checkout不会删除或更改分支的历史记录，仅会更改当前的工作目录和暂存区。 -
示例：
git checkout <branch> # 切换到其他分支 git checkout <commit> -- <file> # 将文件恢复到指定提交的状态 git checkout <commit> # 切换到某个历史提交，进入分离 HEAD 状态
2.
git reset-
主要作用：用于重置分支的提交历史、暂存区和工作目录。
-
应用场景：
-
撤销提交：可以删除或回滚到某次提交，影响整个分支的提交历史。
-
撤销暂存更改：将暂存区中的内容撤回到工作目录，取消暂存。
-
彻底丢弃更改：使用
--hard参数时，可以丢弃所有未提交的更改，重置到某次提交的状态。
-
-
影响分支的提交历史：
reset直接移动当前分支的指针到指定提交，从而修改分支历史，尤其是--hard模式会丢弃未提交的更改。 -
示例：
git reset --soft HEAD~1 # 回滚提交，但保留更改在暂存区 git reset --mixed HEAD~1 # 回滚提交并取消暂存，保留更改在工作目录 git reset --hard HEAD~1 # 回滚提交并丢弃所有更改
总结对比
特性 git checkoutgit reset分支切换 是 否 恢复文件内容 是（恢复单个文件） 否 修改分支历史 否 是（回滚提交历史） 回滚暂存区 否 是（ --mixed和--soft选项）丢弃更改 否（只影响工作目录或单个文件） 是（ --hard选项可彻底丢弃工作目录和暂存区更改）分离 HEAD 状态 可以（进入某次提交的状态，不影响分支指针） 不适用于分离 HEAD 状态 -
git checkout：更常用于切换分支、查看或恢复文件的某次状态，影响工作目录而不修改分支历史。 -
git checkout 其实是使用版本库里的版本替换工作区（工作目录）的版本，所以可以很轻松地把删除的文件恢复到最新版本
-
git reset：用于回滚提交历史、撤销暂存或丢弃更改，直接修改分支的指针位置。
-
git rm -- 用于从暂存区和工作目录中删除文件的命令
-
git rm是 Git 中用于从暂存区和工作目录中删除文件的命令。它不仅删除文件，还将删除操作添加到下次提交中。基本用法
git rm <file>
-
执行后会将指定文件从 Git 暂存区和工作目录中删除。
常用选项
-
删除文件并添加到暂存区
git rm <file>
-
将文件从暂存区和工作目录中删除，删除操作会被添加到下次提交中。
-
-
仅从 Git 暂存区删除文件，保留在工作目录
git rm --cached <file>
-
只删除暂存区中的文件，将文件从版本控制中移除，但文件仍保留在本地磁盘。
-
适用于：希望将文件移出版本控制但不删除本地文件的情况（比如
.env文件）。
-
-
递归删除文件夹
git rm -r <directory>
-
删除指定文件夹及其所有内容。
-
-
强制删除
git rm -f <file>
-
如果文件已被修改但未暂存，默认情况下
git rm会提示错误，-f参数可强制删除。
-
示例
-
从版本控制中删除文件：
git rm example.txt git commit -m "Remove example.txt from repository"
-
移除文件但保留在本地：
git rm --cached example.txt git commit -m "Stop tracking example.txt"
-
删除文件夹及所有内容：
git rm -r folder/ git commit -m "Remove folder and its contents"
总结
-
git rm <file>：删除文件并添加到下次提交。 -
git rm --cached <file>：只从 Git 中删除文件，保留在本地。 -
git rm -r <directory>：递归删除文件夹。 -
注意：删除文件后需要
git commit提交更改，以便在远程仓库中同步这些操作。
-
git remote add origin GitHub - xxxx/leaengit
-
git remote add origin https://github.com/xxxx/leaengit.git是用于将本地 Git 仓库连接到远程仓库的命令。以下是该命令的详细解释：命令分解
-
git remote add：用于添加一个新的远程仓库。 -
origin：这是远程仓库的名字。通常，origin作为默认的远程仓库名称，但可以使用其他名称。 -
https://github.com/xxxx/leaengit.git：这是远程仓库的 URL，指向 GitHub 上的一个仓库。可以是 HTTPS URL 或 SSH URL。
作用
执行此命令后，你的本地仓库会被关联到远程仓库
https://github.com/JsutBeacause/leaengit.git，这意味着你可以使用git push、git pull等命令与该远程仓库进行交互。常见后续操作
-
推送本地分支到远程仓库
git push -u origin main
这将
main分支推送到origin（即远程仓库），并将其设置为本地main分支的默认上游分支。之后，可以直接使用git push推送到该分支。 -
拉取远程分支到本地
git pull origin main
这将从远程仓库的
main分支拉取最新更改，并合并到本地main分支。 -
查看当前远程仓库信息
git remote -v
显示当前配置的远程仓库地址列表，包含
fetch和push两个操作的 URL。
总结
-
git remote add origin <url>：将本地仓库与远程仓库关联。 -
通常后续使用
git push、git pull等命令进行同步。 -
origin是远程仓库的默认名称，可以使用git remote rename更改名称。
-
git push --用于将本地仓库的提交推送到远程仓库的命令
-
git push是 Git 中用于将本地仓库的提交推送到远程仓库的命令。它将本地的提交同步到远程仓库，以便团队成员可以查看、拉取或合并这些更改。基本用法
git push <remote> <branch>
-
<remote>：远程仓库的名称，例如origin。 -
<branch>：要推送的分支名称，例如main或feature-branch。
常见操作
-
首次推送并设置上游分支
git push -u origin main
-
-u选项用于将远程origin/main分支设置为本地main分支的上游分支。以后可以直接使用git push进行推送，而无需指定分支名称。
-
-
普通推送
git push
-
将当前分支的更改推送到上游分支，前提是已经设置了上游分支。
-
-
推送所有分支
git push --all origin
-
将本地仓库的所有分支推送到远程
origin。
-
-
强制推送
git push --force
-
强制将本地分支推送到远程仓库，覆盖远程分支的内容。谨慎使用，可能会覆盖其他人的工作。
-
-
删除远程分支
git push origin --delete <branch>
-
删除远程仓库中的指定分支。
-
示例
假设本地的提交已准备好推送，可以使用以下命令：
git push origin main
该命令会将本地的
main分支推送到远程仓库origin的main分支。其他人可以使用git pull拉取这些更改。常见场景
-
团队协作：在多人协作中，推送代码后，团队成员可以拉取代码以保持一致。
-
新建远程仓库后首次推送：第一次推送时通常用
git push -u origin <branch>设置上游分支。 -
覆盖错误的提交：使用
--force覆盖错误的提交，但需要确保没有影响他人工作。
总结
-
git push将本地的更改提交到远程仓库。 -
-u选项可以设置上游分支，方便后续直接使用git push。 -
使用
--force强制推送需谨慎，以免覆盖他人更改。
-
git remote --用于管理 Git 仓库中远程仓库的命令
-
git remote是一个用于管理 Git 仓库中远程仓库的命令。它可以查看、添加、修改或删除远程仓库的别名，以便与远程仓库同步代码。基本用法
-
查看远程仓库
git remote
-
列出当前所有远程仓库的名称，例如
origin。 -
如果想查看详细信息（包括 fetch 和 push URL），可以使用
-v选项：git remote -v
-
-
添加远程仓库
git remote add <name> <url>
-
<name>：远程仓库的别名，通常使用origin作为主远程仓库的别名。 -
<url>：远程仓库的 URL 地址，可以是 HTTPS、SSH 或本地路径。例如：git remote add origin https://github.com/user/repo.git
-
-
修改远程仓库 URL
git remote set-url <name> <new-url>
-
更新指定远程仓库的 URL，例如：
git remote set-url origin https://github.com/user/new-repo.git
-
-
删除远程仓库
git remote remove <name>
-
移除指定的远程仓库别名。例如：
git remote remove origin
-
-
重命名远程仓库
git remote rename <old-name> <new-name>
-
更改远程仓库的别名。例如：
git remote rename origin upstream
-
常见场景
-
添加远程仓库：克隆项目或初始化项目后，将本地仓库与远程仓库关联。
-
修改远程 URL：例如，更换远程仓库的 HTTPS 地址为 SSH 地址，或更改项目托管位置。
-
查看所有远程仓库：确认仓库中配置了哪些远程地址。
-
删除远程仓库：项目重构或更换远程仓库地址时，移除不再使用的远程仓库。
示例
# 查看当前所有远程仓库 git remote -v # 添加一个新的远程仓库 git remote add origin https://github.com/user/repo.git # 修改远程仓库 URL git remote set-url origin git@github.com:user/repo.git # 重命名远程仓库别名 git remote rename origin backup # 删除远程仓库 git remote remove backup
总结
-
git remote -v：查看详细的远程仓库 URL。 -
git remote add <name> <url>：添加远程仓库。 -
git remote set-url <name> <new-url>：修改远程仓库 URL。 -
git remote remove <name>：删除指定的远程仓库。
-
git clone --用于将远程 Git 仓库复制到本地的命令
-
git clone是用于将远程 Git 仓库复制到本地的命令，它会创建一个本地副本，包含所有的提交记录、分支和标签。这是开始与已有 Git 项目协作的第一步。基本用法
git clone <repository-url>
-
<repository-url>：远程仓库的地址。可以是 HTTPS、SSH、或本地路径。
常用选项
-
克隆到指定目录
git clone <repository-url> <directory>
-
将仓库克隆到指定的文件夹，而不是默认的仓库名称。例如：
git clone https://github.com/user/repo.git my-folder
-
-
只克隆指定分支
git clone -b <branch-name> <repository-url>
-
默认情况下，
git clone会克隆整个仓库，包括所有分支。使用-b参数可以仅克隆特定分支：git clone -b develop https://github.com/user/repo.git
-
-
克隆并只获取最新提交
git clone --depth 1 <repository-url>
-
这会使用浅克隆，只获取最新的提交记录，适合快速下载和查看代码而不需要完整历史。例如：
git clone --depth 1 https://github.com/user/repo.git
-
-
克隆包含子模块的仓库
git clone --recurse-submodules <repository-url>
-
如果仓库包含子模块，使用
--recurse-submodules可以将主仓库和子模块一起克隆下来：git clone --recurse-submodules https://github.com/user/repo.git
-
示例
# 克隆整个仓库到当前目录 git clone https://github.com/user/repo.git # 克隆仓库并重命名文件夹 git clone https://github.com/user/repo.git my-repo # 克隆特定分支 git clone -b feature-branch https://github.com/user/repo.git # 浅克隆（只获取最近的提交） git clone --depth 1 https://github.com/user/repo.git # 克隆包含子模块的仓库 git clone --recurse-submodules https://github.com/user/repo.git
典型应用场景
-
获取现有项目：
git clone是获取现有项目的标准方式，适用于多人协作、开源项目或多分支开发。 -
节省时间与空间：使用浅克隆或特定分支克隆可以节省克隆时间和磁盘空间。
-
管理包含子模块的项目：如果项目依赖其他仓库，
--recurse-submodules可帮助同时克隆这些子模块。
总结
-
git clone <url>：克隆远程仓库到本地。 -
-b <branch>：克隆特定分支。 -
--depth 1：浅克隆，只获取最新提交。 -
--recurse-submodules：克隆包含子模块的仓库。
-
git branch --用于查看、创建、删除或管理 Git 分支的命令
-
git branch是用于查看、创建、删除或管理 Git 分支的命令。分支是 Git 用来并行开发、隔离功能和版本管理的重要工具。基本用法
-
查看本地分支
git branch
-
列出当前仓库的所有本地分支，并在当前分支前显示
*号。
-
-
查看远程分支
git branch -r
-
仅列出远程分支。
-
-
查看本地和远程所有分支
git branch -a
-
列出所有分支，包括本地和远程分支。
-
分支管理操作
-
创建新分支
git branch <branch-name>
-
创建一个新的分支，但不会自动切换到该分支。例如：
git branch feature-login
-
-
切换到指定分支
git checkout <branch-name>
-
切换到已有的分支。创建分支并切换可使用
-b参数：git checkout -b new-feature
-
-
删除分支
git branch -d <branch-name>
-
删除本地分支，但前提是该分支已经被合并。若尚未合并，可以使用
-D强制删除：git branch -D old-feature
-
-
重命名分支
git branch -m <new-branch-name>
-
将当前分支重命名。若需指定分支，则格式为：
git branch -m old-name new-name
-
常用示例
# 查看当前分支 git branch # 创建新分支 git branch feature-auth # 切换到新分支 git checkout feature-auth # 创建并切换到新分支 git checkout -b feature-ui # 删除分支 git branch -d feature-auth # 强制删除未合并的分支 git branch -D feature-legacy # 列出所有分支（本地和远程） git branch -a
典型应用场景
-
创建开发分支：通常用于实现新功能或修复 Bug。开发完后可以将分支合并回主分支。
-
删除废弃分支：删除不再需要的分支，保持仓库整洁。
-
重命名分支：规范分支名称或修正拼写错误时很有用。
总结
-
git branch：查看当前本地分支。 -
git branch -a：查看所有分支，包括远程。 -
git branch <name>：创建新分支。 -
git branch -d <name>：删除分支（若已合并）。 -
git branch -m <new-name>：重命名当前分支。
-
git switch --用于切换分支的命令
-
git switch是一个用于切换分支的命令，也是git checkout切换分支操作的替代方法。它专门用于处理分支切换，而不用于切换文件或暂存区内容，简化了分支管理的操作。基本用法
-
切换到已有分支
git switch <branch-name>
-
切换到指定的分支，例如：
git switch main
-
-
创建并切换到新分支
git switch -c <new-branch-name>
-
-c是--create的简写，表示创建并切换到一个新的分支。例如：git switch -c feature-login
-
-
切换到上一个分支
git switch -
-
-是快捷方式，用于在两个分支之间来回切换。例如，如果你在main分支上，切换到dev分支，再执行git switch -将回到main。
-
常用选项
-
-c或--create：创建并切换到一个新的分支。 -
-：快速切换到上一个分支。
示例
# 切换到现有分支 git switch develop # 创建并切换到新分支 git switch -c feature-auth # 在两个分支之间切换 git switch -
git switchvsgit checkout-
专注性：
git switch仅用于分支操作，专注于分支切换，而git checkout同时用于切换文件和分支，操作更为复杂。 -
易用性：
git switch更简洁、语义清晰，尤其对新手友好，减少了误操作的可能。
典型应用场景
-
切换到开发分支：例如从
main切换到feature分支。 -
创建新分支并切换：快速进行分支创建和切换，方便功能开发或 bug 修复。
总结
-
git switch <branch>：切换到指定分支。 -
git switch -c <branch>：创建并切换到新分支。 -
git switch -：切换到上一个分支。
git switch是git checkout的替代方式，专门用于处理分支切换，让操作更简单。git merge --用于将一个分支的更改合并到当前分支的 Git 命令
-
-
git merge是用于将一个分支的更改合并到当前分支的 Git 命令。它通常用于将开发分支的更新整合到主分支或其他功能分支，以保持代码同步。基本用法
git merge <branch-name>
-
<branch-name>：要合并进当前分支的分支名称。比如，在main分支上运行git merge feature-login将把feature-login分支的更改合并到main分支。
合并的类型
-
快进合并（Fast-forward merge）
-
如果当前分支是目标分支的祖先分支，Git 会直接把当前分支的指针移动到目标分支的末尾。这种情况不会生成新的合并提交。
git merge feature-branch
-
如果
main分支没有新的提交，这会直接让main指向feature-branch的最新提交。
-
-
三路合并（Three-way merge）
-
当分支有各自独立的提交时，Git 会创建一个新的合并提交，将当前分支和目标分支的修改合并。
-
比如，如果在
main和feature-branch上都有独立的提交，执行合并时会产生一个新的合并提交。
git merge feature-branch
-
处理合并冲突
有时，两个分支的同一文件的同一行发生了更改，Git 无法自动合并，这就是合并冲突。解决冲突的步骤：
-
Git 会提示冲突文件，打开冲突文件，找到冲突标记（
<<<<<<<、=======和>>>>>>>）。 -
手动修改冲突的内容，删除标记，并保留需要的修改。
-
将解决后的文件重新添加到暂存区：
git add <conflict-file>
-
最后，完成合并提交：
git commit
常用选项
-
--no-ff：禁止快进合并，总是创建一个新的合并提交。git merge --no-ff feature-branch
-
--squash：合并时将所有提交压缩为一个提交，而不会创建新的合并提交记录。git merge --squash feature-branch
示例
# 切换到目标分支 git checkout main # 将 feature-branch 合并到 main 分支 git merge feature-branch # 禁止快进合并 git merge --no-ff feature-branch # 处理合并冲突，手动修改冲突文件 # 添加解决后的文件并提交合并 git add conflict-file git commit
常见场景
-
功能合并：将功能分支的更改合并回
main，以发布新功能。 -
同步代码：在团队开发中，合并他人分支的更改以保持代码库一致。
-
修复冲突：多分支开发中解决代码冲突，将更改整合。
总结
-
git merge <branch>：将指定分支合并到当前分支。 -
--no-ff：禁止快进合并，保留合并历史。 -
--squash：将合并内容压缩成一个提交。
-
git merge --用于将一个分支的更改合并到当前分支的 Git 命令
-
git merge是用于将一个分支的更改合并到当前分支的 Git 命令。它通常用于将开发分支的更新整合到主分支或其他功能分支，以保持代码同步。基本用法
git merge <branch-name>
-
<branch-name>：要合并进当前分支的分支名称。比如，在main分支上运行git merge feature-login将把feature-login分支的更改合并到main分支。
合并的类型
-
快进合并（Fast-forward merge）
-
如果当前分支是目标分支的祖先分支，Git 会直接把当前分支的指针移动到目标分支的末尾。这种情况不会生成新的合并提交。
git merge feature-branch
-
如果
main分支没有新的提交，这会直接让main指向feature-branch的最新提交。
-
-
三路合并（Three-way merge）
-
当分支有各自独立的提交时，Git 会创建一个新的合并提交，将当前分支和目标分支的修改合并。
-
比如，如果在
main和feature-branch上都有独立的提交，执行合并时会产生一个新的合并提交。
git merge feature-branch
-
处理合并冲突
有时，两个分支的同一文件的同一行发生了更改，Git 无法自动合并，这就是合并冲突。解决冲突的步骤：
-
Git 会提示冲突文件，打开冲突文件，找到冲突标记（
<<<<<<<、=======和>>>>>>>）。 -
手动修改冲突的内容，删除标记，并保留需要的修改。
-
将解决后的文件重新添加到暂存区：
git add <conflict-file>
-
最后，完成合并提交：
git commit
常用选项
-
--no-ff：禁止快进合并，总是创建一个新的合并提交。git merge --no-ff feature-branch
-
--squash：合并时将所有提交压缩为一个提交，而不会创建新的合并提交记录。git merge --squash feature-branch
示例
# 切换到目标分支 git checkout main # 将 feature-branch 合并到 main 分支 git merge feature-branch # 禁止快进合并 git merge --no-ff feature-branch # 处理合并冲突，手动修改冲突文件 # 添加解决后的文件并提交合并 git add conflict-file git commit
常见场景
-
功能合并：将功能分支的更改合并回
main，以发布新功能。 -
同步代码：在团队开发中，合并他人分支的更改以保持代码库一致。
-
修复冲突：多分支开发中解决代码冲突，将更改整合。
总结
-
git merge <branch>：将指定分支合并到当前分支。 -
--no-ff：禁止快进合并，保留合并历史。 -
--squash：将合并内容压缩成一个提交。
-
git stash --用于临时保存当前工作区的修改，以便在不提交代码的情况下切换分支或进行其他操作。
-
git stash命令用于临时保存当前工作区的修改，以便在不提交代码的情况下切换分支或进行其他操作。存储的修改可以稍后恢复，使得开发过程更加灵活。基本用法
git stash
-
将当前工作区中的修改（包括暂存区和未暂存的更改）保存到一个栈中，并恢复工作区至干净状态。
常用选项
-
保存未提交的更改（包括暂存和未暂存的修改）
git stash -u
-
使用
-u或--include-untracked选项可以将未跟踪的文件也一起保存。
-
-
指定描述保存状态
git stash save "message"
-
保存时添加描述，方便以后查找。例如：
git stash save "WIP: Feature login page"
-
-
查看所有存储的更改
git stash list
-
查看当前分支中所有的暂存记录。记录格式如下：
stash@{0}: WIP on main: some message stash@{1}: WIP on feature: another message
-
-
恢复存储的更改
git stash apply
-
恢复最近一次的暂存，但不会删除该暂存记录。若需恢复特定暂存，可以指定索引：
git stash apply stash@{1}
-
-
弹出并应用最近的存储
git stash pop
-
将最近一次的存储恢复到工作区，并删除该存储。用法同
apply，但会删除应用的记录。
-
-
删除指定的暂存记录
git stash drop stash@{index}-
删除特定的暂存记录，指定索引即可。例如：
git stash drop stash@{0}
-
-
清空所有暂存
git stash clear
-
删除所有的暂存记录。
-
示例
# 保存当前的修改 git stash # 保存当前的修改，并包括未跟踪的文件 git stash -u # 查看所有暂存记录 git stash list # 恢复并删除最近的暂存记录 git stash pop # 恢复特定暂存记录 git stash apply stash@{1} # 删除特定的暂存记录 git stash drop stash@{0} # 清空所有暂存记录 git stash clear典型应用场景
-
在未提交代码的情况下切换分支：当当前分支有未提交的更改，而你需要切换到其他分支时，可以使用
git stash临时保存工作区的修改。 -
尝试新功能：暂存当前工作，然后测试新的代码或功能，确保当前代码状态不受影响。
-
避免多次提交：当功能未完成但需要暂时保存代码以进行其他操作时，可以使用
git stash暂存代码，而不提交不完整的工作。
总结
-
git stash：将当前更改存储到暂存栈。 -
git stash pop：恢复最近一次暂存并移除记录。 -
git stash apply：恢复指定的暂存，但保留记录。 -
git stash clear：清空所有暂存记录。
-
git cherry-pick --用于从一个分支中选择特定提交并将其应用到当前分支的命令。
-
git cherry-pick是用于从一个分支中选择特定提交并将其应用到当前分支的命令。这个命令常用于将某些提交从一个分支移植到另一个分支，而不需要合并整个分支。基本用法
git cherry-pick <commit-hash>
-
<commit-hash>是提交的哈希值，通过git log可以找到它。cherry-pick会把指定提交的更改应用到当前分支。
常用选项
-
选择多个提交
git cherry-pick <commit1> <commit2> ...
-
按顺序将多个提交应用到当前分支，例如：
git cherry-pick a1b2c3d4 e5f6g7h8
-
-
选择提交范围
git cherry-pick <start-commit>^..<end-commit>
-
使用
^符号指定从某个提交的前一个开始，可以快速将多个连续的提交应用。例如：git cherry-pick a1b2c3d4^..e5f6g7h8
-
-
处理冲突
-
当 cherry-pick 操作导致冲突时，Git 会提示冲突的文件。解决冲突后，使用以下命令继续：
git add <file> git cherry-pick --continue
-
如果要中止 cherry-pick 操作，可以使用：
git cherry-pick --abort
-
-
跳过冲突的提交
git cherry-pick --skip
-
若遇到冲突不想解决，直接跳过当前提交，继续下一个提交的应用。
-
-
取消 Cherry-pick
git cherry-pick --abort
-
取消当前 cherry-pick 操作并恢复到未执行 cherry-pick 之前的状态。
-
示例
# 选择单个提交并应用到当前分支 git cherry-pick a1b2c3d4 # 选择多个非连续提交 git cherry-pick a1b2c3d4 e5f6g7h8 # 选择连续提交范围 git cherry-pick a1b2c3d4^..e5f6g7h8 # 遇到冲突时，解决冲突并继续 git add conflict-file git cherry-pick --continue # 遇到冲突跳过当前提交 git cherry-pick --skip # 取消 cherry-pick git cherry-pick --abort
典型应用场景
-
Bug 修复移植：在一个分支修复的 Bug 需要应用到其他分支时，可以用
cherry-pick将该提交移植到目标分支。 -
移植功能：当一个功能只需从开发分支应用到主分支，而不需要合并整个分支的所有改动时。
-
跨分支合并特定改动：团队开发中，从一个分支挑选某些重要的提交合并到另一个分支，保持分支独立性。
总结
-
git cherry-pick <commit>：将指定提交应用到当前分支。 -
--continue：处理冲突后继续 cherry-pick。 -
--abort：取消 cherry-pick 操作。 -
--skip：跳过当前冲突的提交。
-
git pull --用于将远程仓库的更改拉取到本地仓库的命令。
-
git pull是一个用于将远程仓库的更改拉取到本地仓库的命令。它结合了git fetch和git merge的功能，先拉取远程更新，然后将它们合并到当前分支。基本用法
git pull <remote> <branch>
-
<remote>是远程仓库的名称，通常是origin。 -
<branch>是要拉取的分支名称，例如main。
使用示例：
git pull origin main
这将从远程仓库
origin拉取main分支的最新更新，并合并到本地的当前分支。常用选项
-
拉取并重写本地更改
git pull --rebase
-
使用
--rebase选项会先拉取远程的更改，再将本地未提交的修改重新应用在最新的基础上，避免合并历史中的多余提交。
git pull --rebase origin main
-
-
只拉取不合并
git fetch <remote> <branch>
-
如果只想拉取而不立即合并，可以使用
git fetch，然后根据需要进行合并或查看差异。
git fetch origin main
-
-
指定合并策略
git pull --no-ff
-
该选项会使用
--no-ff合并策略，确保产生一个合并提交而不是快进合并。
-
-
拉取时自动解决冲突
git pull -X theirs
-
使用
-X theirs或-X ours选项可以在拉取时自动解决冲突。例如，-X theirs会保留远程仓库的更改，-X ours会保留本地的更改。
-
合并冲突处理
当
git pull过程中遇到冲突时，可以按照以下步骤解决：-
Git 会提示冲突文件，打开文件找到冲突标记（
<<<<<<<、=======和>>>>>>>）。 -
手动编辑文件以解决冲突，保存更改。
-
将解决后的文件重新添加到暂存区：
git add <conflict-file>
-
最后，完成合并提交：
git commit
示例
# 拉取并合并默认分支的最新更改 git pull # 从远程仓库 origin 拉取 main 分支并合并 git pull origin main # 使用 rebase 方式拉取并合并 git pull --rebase origin main # 仅拉取而不合并 git fetch origin main git merge origin/main
典型应用场景
-
同步远程更改：团队开发时，通过
git pull获取他人提交的最新更改，保持本地代码与远程同步。 -
合并冲突前更新：在提交前使用
git pull以合并其他更改，减少冲突。 -
定期更新：定期从远程仓库拉取最新更新，保持本地代码库与远程仓库一致。
总结
-
git pull：拉取并合并远程仓库的最新更改。 -
--rebase：拉取后将本地修改应用到最新代码上，避免额外的合并提交。 -
-X theirs/-X ours：在拉取时自动解决冲突，指定优先保留远程或本地的更改。
-
git rebase --用于将一系列提交移动到另一基础之上，以优化提交历史的 Git 命令。
-
git rebase是一个用于将一系列提交移动到另一基础之上，以优化提交历史的 Git 命令。它常用于将当前分支的修改整合到目标分支的最新状态之上，从而保持项目的提交历史简洁、线性。基本用法
git rebase <base-branch>
-
<base-branch>是你希望作为新基础的分支，例如main。git rebase会把当前分支的提交“重新定位”到<base-branch>的最新提交之上。
例如：
git checkout feature git rebase main
此命令会将
feature分支上的提交重新应用到main分支的最新提交之上。典型场景和示例
-
更新分支 将当前分支基于最新的目标分支（如
main）重新应用自己的提交，避免冗长的合并历史。# 在 feature 分支上执行 git rebase main
-
交互式 Rebase
git rebase -i <base-branch>
-
使用
-i或--interactive选项可以打开交互式编辑模式，允许对每个提交进行编辑、合并、删除、重排等操作。
例如：
git rebase -i main
在交互模式中可以选择：
-
pick：保持提交不变。 -
squash：将多个提交合并成一个提交。 -
reword：修改提交信息。 -
edit：修改提交内容。
-
-
自动跳过冲突
在 rebase 操作中遇到冲突时，可以自动跳过冲突的提交并继续：
git rebase --skip
-
中止 Rebase
如果在 rebase 过程中遇到严重冲突或需要退出 rebase，可以中止操作：
git rebase --abort
解决冲突流程
-
执行
git rebase <branch>后，如果遇到冲突，Git 会停止在冲突的提交处，并提示冲突文件。 -
手动解决冲突并保存更改。
-
使用
git add <file>将解决后的文件添加到暂存区。 -
使用以下命令继续 rebase：
git rebase --continue
常见选项
-
-i/--interactive：交互式 rebase，可以选择、合并、修改提交。 -
--abort：中止当前 rebase，恢复到原始状态。 -
--skip：跳过当前冲突提交，继续 rebase。 -
--continue：在解决冲突后继续 rebase。
示例
# 将 feature 分支的提交重新定位到 main 分支的最新提交之上 git checkout feature git rebase main # 交互式 rebase，将提交合并或重新排序 git rebase -i main # 解决冲突后继续 rebase git add <conflict-file> git rebase --continue # 跳过冲突的提交 git rebase --skip # 中止 rebase git rebase --abort
典型应用场景
-
保持提交历史整洁：避免多次合并，保持提交历史线性，以便更清晰地查看项目的演变。
-
合并多个提交：在代码 review 之前，可以使用交互式 rebase 将多个小提交合并成一个，以减少提交数量。
-
更新功能分支：在开发功能的过程中，通过
git rebase将最新的main分支合并进来，保持分支最新。
总结
-
git rebase <branch>：将当前分支重新定位到指定分支的最新提交。 -
-i/--interactive：交互式 rebase，编辑提交历史。 -
--abort：中止当前 rebase。 -
--continue/--skip：处理冲突后的操作。
-
git tag -- 用于为 Git 仓库中的特定提交创建标签（tag）
-
git tag用于为 Git 仓库中的特定提交创建标签（tag），常用于标记版本发布，例如v1.0或v2.1，便于版本管理和查找特定历史版本。标签分为轻量标签和附注标签。基本用法
-
创建轻量标签
git tag <tag-name>
-
轻量标签（Lightweight Tag）只是简单地给当前提交添加一个名字，不附带额外信息。 例如：
git tag v1.0
-
-
创建附注标签
git tag -a <tag-name> -m "message"
-
使用
-a选项可以创建附注标签（Annotated Tag），附注标签带有标签创建者的信息、日期和标签说明，适合用于发布版本。 例如：
git tag -a v1.0 -m "First release version"
-
-
为指定提交创建标签
git tag <tag-name> <commit-hash>
-
可以为某个历史提交打标签，
<commit-hash>为提交的哈希值。例如：git tag v1.0 a1b2c3d4
-
查看标签
git tag
-
查看所有标签。
git show <tag-name>
-
显示指定标签的详细信息（适用于附注标签），例如：
git show v1.0
删除标签
git tag -d <tag-name>
-
删除本地标签，例如：
git tag -d v1.0
推送标签到远程仓库
-
推送单个标签
git push origin <tag-name>
-
将指定标签推送到远程仓库，例如：
git push origin v1.0
-
-
推送所有本地标签
git push origin --tags
-
将所有本地标签一次性推送到远程仓库。
-
删除远程标签
-
删除本地标签：
git tag -d <tag-name>
-
使用以下命令删除远程仓库中的标签：
git push origin :refs/tags/<tag-name>
-
例如：
git push origin :refs/tags/v1.0
-
重命名标签
Git 不支持直接重命名标签，因此可以通过以下步骤来“重命名”标签：
-
删除旧标签（本地和远程）：
git tag -d <old-tag-name> git push origin :refs/tags/<old-tag-name>
-
创建新标签并推送：
git tag <new-tag-name> git push origin <new-tag-name>
示例
# 创建轻量标签 git tag v1.0 # 创建附注标签 git tag -a v1.1 -m "Second release version" # 查看标签 git tag git show v1.1 # 推送标签到远程仓库 git push origin v1.1 # 推送所有标签 git push origin --tags # 删除本地标签 git tag -d v1.0 # 删除远程标签 git push origin :refs/tags/v1.0
典型应用场景
-
发布版本：在发布新版本时，通过标签标记特定的提交，便于版本管理。
-
回滚版本：通过标签快速找到历史版本并进行回滚。
-
代码快照：将里程碑或重要变更点标记为标签，方便定位。
总结
-
git tag <tag-name>：创建轻量标签。 -
git tag -a <tag-name> -m "message"：创建附注标签。 -
git push origin <tag-name>：推送标签到远程仓库。 -
git tag -d <tag-name>/git push origin :refs/tags/<tag-name>：删除本地/远程标签。
-
扫一扫
1278
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
