GIT

git命令速查

命令	描述
git init	初始化一个新的 Git 仓库
git clone <repository>	克隆（下载）一个远程仓库到本地
git add <file>	将文件添加到暂存区
git commit -m <message>	将暂存区的更改提交为一个新的提交
git status	显示工作区和暂存区的状态
git log	查看提交历史
git branch	列出本地分支
git checkout <branch>	切换到指定分支
git merge <branch>	将指定分支合并到当前分支
git pull	拉取远程仓库的更新并合并到当前分支
git push	推送当前分支的更改到远程仓库
git remote add <name> <url>	添加一个远程仓库
git remote -v	显示远程仓库的详细信息
git diff	显示工作区与暂存区之间的差异
git reset <file>	从暂存区中移除文件
git stash	将当前更改暂存起来并清空工作区
git cherry-pick <commit>	选择一个提交并将其应用到当前分支
git tag <tagname>	创建一个标签
git remote remove <name>	移除指定的远程仓库
git config --global <option>	配置全局 Git 选项

git的常用指令?

我们要开始一个新项目。以下是在项目过程中可能会用到的 Git 指令：

当我们开始搭建一个新的项目仓库，首先我们会用 git init 来初始化仓库；搭建好之后，我们会在 GitHub 或者 GitLab 上设置好公钥，以便能够进行安全的通信。

然后我们使用 git clone [url] 来克隆拉取仓库代码。因为是多人协作开发，所以每个人会用 git branch [branch-name] 来创建自己的分支。

开始编写代码，编写代码就使用 git add [file] 和 git commit -m "commit message" 和 git push 将更改提交到自己的分支上。

当我们准备将我们的更改合并到主分支时，我们会用 git checkout master 切换到主分支，然后使用 git merge [branch-name] 将我们的更改合并到主分支上。

在提交或合并的过程中，有可能出现代码冲突。当这种情况发生时，我们可以使用 git diff 来查看冲突的详细信息，然后手动解决冲突，并使用 git add [file] 和 git commit -m "resolve conflict" 来提交解决冲突后的代码。

在开发过程中，我们经常会遇到这样的情况：正在开发的时候，突然要加新功能，而且新功能比较急。这时我们可以使用 git stash 命令将当前的更改保存起来，然后切换到新的分支进行新功能的开发。等新功能开发完毕并合并到主分支后，我们再用 git stash pop 将之前保存的更改恢复，继续我们之前的工作。

git init 和 git init --bare 的区别?

git init 和 git init --bare 都是 Git 命令，用于初始化一个新的 Git 仓库，但它们创建的仓库类型有所不同。

1.git init 命令用于创建一个标准的 Git 仓库。这个仓库包括一个 .git 子目录，它存储了所有的仓库元数据，以及一个工作目录，用于保存你的项目文件。这意味着你可以在这个工作目录中编辑你的文件，然后使用 git add 和 git commit 命令来保存你的更改。这是在你需要在本地进行开发工作时应该使用的仓库类型。

2.git init --bare 命令用于创建一个裸仓库（bare repository）。裸仓库只包含 Git 仓库的元数据，而没有工作目录。这意味着你不能直接在裸仓库中编辑或提交文件。裸仓库常常被用作共享仓库，例如在服务器上，让其他人可以克隆（clone）或推送（push）更改。这通常在你需要设置一个纯粹用于版本控制的仓库时使用，例如在服务器上托管的中央仓库。

所以，git init 创建的是一个有工作目录的仓库，用于日常的开发工作；而 git init --bare 创建的是没有工作目录的裸仓库，用于作为共享仓库，存储版本历史信息。

git reset 和 git revert 的 区别?

git revert 和 git reset 都是用来撤销 Git 历史的命令，但它们的工作方式和使用场景有所不同。

• git reset 是一个强大的命令，它能将 HEAD 指针移动到指定的提交，同时可以选择性地修改暂存区或工作目录以匹配该提交。git reset 有三种模式：
  • git reset --soft 仅移动 HEAD 指针而不更改暂存区和工作目录。
  • git reset --mixed（默认） 移动 HEAD 并更改暂存区以匹配该提交，但不影响工作目录。
  • git reset --hard 移动 HEAD 并更改暂存区和工作目录以匹配该提交。 这使得 git reset 成为一个灵活的命令，可以用于撤销更改或者清理工作区和暂存区。但是，它也有一个缺点，那就是它会重写 Git 历史，这可能会导致困扰如果与其他开发者共享了这些更改。

• 相比之下，git revert 则会创建一个新的提交，这个提交的内容与要撤销的提交相反。这意味着它不会重写历史，这使得它成为一个更安全的选择，特别是在公共或者团队的环境中。当你想要撤销某个提交的更改，但又不想影响项目的历史时，你应该使用 git revert。

总的来说，git reset 是一个更强大且灵活的命令，但也更危险。git revert 则是一个更安全的选择，特别是在团队环境中。选择使用哪个命令主要取决于你的具体需求以及你的工作环境。

git cherry-pick 它是什么命令？

git cherry-pick 是一个非常实用的 Git 命令，它允许你将一个特定的提交从一个分支复制（或“挑选”）到当前的分支。这在许多情况下都非常有用，例如你想要获取一个在其他分支上的修复，但是并不想合并整个分支。

使用 git cherry-pick 的基本语法如下：

git cherry-pick <commit-hash>

在这里，<commit-hash> 是你想要挑选的提交的哈希值。执行这个命令后，Git 会在当前分支上创建一个新的提交，这个提交的更改集与你挑选的提交一样。请注意，这个新的提交是一个全新的提交，它有自己的哈希值，尽管它的更改集与原始提交相同。

总的来说，git cherry-pick 是一个非常强大的工具，可以帮助你精确地管理你的提交和分支。

如何处理合并冲突的？

解决冲突的关键是理解冲突的本质：两个或更多的开发者试图修改同一个地方。你的任务是决定最终的文件应该是什么样的。有了这个思路，解决冲突就会变得更容易。

当在使用 Git 进行协同开发时，代码冲突是常见的问题。它通常发生在两个或更多的开发者尝试修改同一个文件的同一部分时。解决冲突的过程通常需要人工介入，以下是解决冲突的一般步骤：

1. 定位冲突：首先，Git 会告诉你哪些文件存在冲突。你可以通过运行 git status 命令来查看这些文件。

2. 打开冲突文件：然后，你需要打开这些存在冲突的文件，查看冲突的具体位置。Git 会在文件中插入标准的冲突解决标记，这可以帮助你找到冲突的位置。这些标记看起来像这样：

<<<<<<< HEAD
(你的更改)
=======
(对方的更改)
>>>>>>> branch-name

3. 解决冲突：接下来，你需要手动编辑这些文件，决定应该保留哪些更改。你可以选择保留你的更改，保留对方的更改，或者合并你们的更改。在你决定好之后，删除 Git 插入的冲突解决标记。

4. 提交解决冲突后的文件：最后，当你解决了所有冲突后，运行 git add 命令来更新暂存区，然后运行 git commit 来提交你的更改。这时，Git 会自动创建一个新的合并提交，表示你已经解决了所有的冲突。

为什么在团队协助中 不能用 push -f 去推代码？

使用 git push -f 或 git push --force 命令会强制 Git 将你本地的分支推送到远程仓库，即使这意味着会覆盖远程仓库中现有的提交。这就是为什么在团队协作中，你应该避免使用这个命令。

以下是几个关键的原因：

1. 会丢失他人的工作：如果你的团队成员已经在同一个分支上推送了他们的更改，然后你用 git push -f 推送你的更改，他们的更改就会被你的更改覆盖，从而导致他们的工作丢失。

2. 破坏仓库的历史：git push -f 会改写远程仓库的历史，这会使得理解项目的历史变得更困难。例如，如果你用 git push -f 命令覆盖了一个已经发布的版本，那么你的团队就无法准确地知道哪个提交是发布的一部分。

3. 引发混乱：如果你强制推送了更改，那么你的团队成员在拉取最新的代码时可能会遇到各种问题。例如，他们可能会看到一些他们从未见过的冲突，或者他们的 Git 历史可能会与实际的项目历史不一致。

总的来说，虽然 git push -f 在某些情况下可能会有用（例如，你在自己的私有分支上工作，或者你需要修正一个你自己刚刚推送的错误提交），但在团队协作中，你应该尽量避免使用这个命令。

git 查看别人的某一次提交内容，回滚某一次或多次提交的内容

git show <commit-id>

git revert <commit-id> -m 1