awesomeGit用法和常见问题的解决

type

status

slug

summary

Git学习笔记

版本控制--Git的基本使用

一、写在前面

Git Basics
Git是一款免费开源的世界上最流行最广泛使用的版本控制系统，Git是分布式的：每个开发人员都在本地拥有完整的代码仓库历史记录。Git还对分支、合并和重写仓库历史有出色的支持，允许团队在Git分支上合作，高效地审查彼此的代码。
☘️
How Git works(overview) First, Create a "repository" (project) with a git hosting tool (like Bitbucket)
Copy (or clone) the repository to your local machine
Add a file to your local repo and "commit" (save) the changes
"Push" your changes to your main branch
Make a change to your file with a git hosting tool and commit
"Pull" the changes to your local machine
Create a "branch" (version), make a change, commit the change
Open a "pull request" (propose changes to the main branch)
"Merge" your branch to the main branch

二、使用Git的主要原因

Git功能强大，性能卓越，安全性高，灵活性强，满足了大多数团队和个人开发者的需求。

Git已成为事实上的标准，被广泛采用。这使得Git具有以下吸引力：

许多开发者已经具备Git经验，很多大学毕业生可能只有Git经验。

Git的主导地位意味着许多第三方软件工具和服务已经与Git集成，包括IDE、DVCS桌面客户端Sourcetree、问题和项目跟踪软件Jira以及代码托管服务Bitbucket。

Git是一个质量很高的开源项目，有超过十年的稳健管理支持。它享有强大的社区支持和庞大的用户基础，文档丰富，包括书籍、教程和专门的网站，还有播客和视频教程。

Git是开源的，降低了业余开发者的成本，并在开源项目中得到广泛应用。

三、Git的安装和下载

鉴于笔者是Mac OS系统，因此下面的介绍主要针对在Mac系统上进行展开：

如果你已经安装了XCode或者是Command Line Tools，Git可能已经被安装了，因此可以打开terminal输入以下指令

如果之前并没有安装git，那么直接在官网上进行下载 Git for Mac installer.

第二种方法是使用Homebrew

$ brew install git //Open your terminal and install Git using Homebrew$ git --version //Verify the installation was successful

使用以下命令配置你的Git用户名和电子邮件

$ git config --global user.name "CSGO FUFU" $ git config --global user.email "3220105511cs@gmail.com"

四、设置一个个人的仓库

(1).什么是Git仓库

是你项目的虚拟存储空间。允许你保存代码的不同版本，便于你在需要时进行访问

(2).对Git仓库的一系列操作：

1.创建一个git仓库

git init命令用于创建一个新的Git仓库。它可以用于将现有的、未进行版本控制的项目转换为Git仓库，或者初始化一个新的、空的仓库。大多数其他Git命令在未初始化的仓库中不可用，因此通常这是在新项目中首次运行的命令。执行git init会在当前工作目录中创建一个名为.git的子目录，其中包含了新仓库所需的所有Git元数据。这些元数据包括对象、引用和模板文件的子目录。还会创建一个指向当前检出提交的HEAD文件。除了.git目录之外，在项目的根目录中，现有项目保持不变（与SVN不同，Git不需要在每个子目录中都有一个.git子目录）。一般的.git是被自动隐藏的，因此需要使用ls-a指令进行进一步查看默认情况下，git init将初始化Git配置到.git子目录路径中。如果希望它位于其他位置，可以修改和自定义子目录路径。你可以将$GIT_DIR环境变量设置为自定义路径，然后git init将在那里初始化Git配置文件。此外，你还可以传递--separate-git-dir参数以实现相同的效果。将.git子目录分开的一个常见用例是将系统配置的"dotfiles"（如.bashrc、.vimrc等）放在主目录，同时将.git文件夹放在其他位置。git clone：git clone首先调用git init创建一个新仓库。然后它复制现有仓库的数据，并检出一个新的工作文件集。裸仓库（Bare repositories）--- git init --bare 使用git init --bare <directory>命令可以初始化一个空的Git仓库，但省略了工作目录。共享仓库应始终使用--bare标志创建（参见下面的讨论）。按照惯例，使用--bare标志初始化的仓库以.git结尾。例如，名为my-project的仓库的裸版本应存储在一个名为my-project.git的目录中。--bare标志创建的仓库没有工作目录，因此无法在该仓库中编辑文件和提交更改。你会创建一个裸仓库用于git push和git pull操作，但不会直接在其中进行提交。中央仓库应始终作为裸仓库创建，因为向非裸仓库推送分支有覆盖更改的潜力。可以将--bare视为将仓库标记为存储设施而不是开发环境的一种方式。这意味着对于几乎所有的Git工作流程，中央仓库是裸仓库，而开发者的本地仓库是非裸仓库。使用git init templates或git init <directory> --template=<template_directory>命令可以初始化一个新的Git仓库，并将文件从模板目录复制到仓库中。模板允许你使用预定义的.git子目录初始化一个新的仓库。你可以配置一个模板，使其具有默认的目录和文件，这些目录和文件将被复制到新仓库的.git子目录中。默认的Git模板通常位于/usr/share/git-core/templates目录中，但在你的机器上可能是不同的路径。默认模板是如何利用模板功能的很好的参考和示例。模板的一个强大特性，展示在默认模板中，是Git Hook配置。你可以创建一个带有预定义Git Hook的模板，并使用常见的Hook初始化你的新Git仓库。

2. git clone一个现存的仓库

git clone用于创建远程仓库的副本或克隆。你需要传递一个仓库的URL给git clone。Git支持几种不同的网络协议和相应的URL格式。在这个例子中，我们将使用Git的SSH协议。Git的SSH URL遵循以下模板：git@HOSTNAME:USERNAME/REPONAME.git

一个示例的Git SSH URL为：git@bitbucket.org:rhyolight/javascript-data-store.git，其中模板的值匹配如下：

HOSTNAME：主机名，例如bitbucket.org。

USERNAME：用户名，例如rhyolight。

REPONAME：仓库名，例如javascript-data-store。

通过这样的SSH URL，你可以克隆远程仓库到本地进行操作。

执行git clone命令时，远程仓库的最新版本文件将被拉取并添加到一个新文件夹中。新文件夹的名称将根据REPONAME（在这种情况下是javascript-data-store）命名。这个文件夹将包含远程仓库的完整历史记录和一个新创建的main分支。

关于git clone的更多用法和支持的Git操作，请参阅Git的官方文档。

需要理解的是，Git对于"工作副本"的概念与从SVN仓库检出代码所得到的工作副本非常不同。与SVN不同，Git不区分工作副本和中央仓库，它们都是完整的Git仓库。在Git中，每个仓库都具有完整的历史和版本记录，可以独立操作，这使得Git在协作和分布式开发方面具有很大的灵活性。这使得使用Git进行协作与使用SVN基本不同。而SVN依赖于中央仓库和工作副本之间的关系，Git的协作模型基于仓库与仓库之间的交互。与将工作副本检入SVN的中央仓库不同，你可以将提交从一个仓库推送或拉取到另一个仓库中。这种方式使得协作更加灵活，使多个开发者能够同时工作，并将更改合并到各自的仓库中。没有什么阻止你赋予某些Git仓库特殊的意义。例如，通过简单地将一个Git仓库指定为"中央"仓库，可以使用Git来复制集中式工作流。关键在于，这是通过约定而不是被硬编码到版本控制系统中来实现的。Git的灵活性使你能够根据项目的需求自定义协作流程。

git clone主要用于指向一个现有的仓库,并且在一个新的目录中创建一个克隆或者是副本

git clone命令复制一个现有的Git仓库。这有点像SVN的checkout操作，不同之处在于"工作副本"是一个完整的Git仓库，它有自己的历史记录，管理自己的文件，是与原始仓库完全隔离的环境。

clone一个特定的仓库文件：

使用git clone <repo> <directory>命令可以将位于<repo>的仓库克隆到本地机器上名为<directory>的文件夹中。
使用git clone --branch <tag> <repo>命令可以克隆位于<repo>的仓库，并只克隆<tag>的引用。这样可以只获取特定标签的内容。
使用git clone --depth=1 <repo>命令可以克隆位于<repo>的仓库，并只克隆通过-depth=1选项指定的提交历史。在这个示例中，克隆了<repo>，并只包括最近的一次提交在新克隆的仓库中。浅克隆在与具有大量提交历史的仓库一起工作时非常有用。大量的提交历史可能导致一些问题，比如磁盘空间限制和克隆时长等。浅克隆可以帮助缓解这些扩展性问题。

配置选项：

git clone --branch选项允许你指定要克隆的特定分支，而不是远程HEAD指向的分支，通常是主分支。此外，你也可以传递一个标签而不是分支，达到相同的效果。

例如，上面的示例将仅克隆远程Git仓库中的new_feature分支。这只是一个方便的工具，可以节省下载仓库的HEAD引用的时间，然后还需要额外获取所需引用的时间。

git clone -mirror与git clone -bare之间的区别：

git clone --bare：使用-bare选项时，创建的仓库是一个裸仓库，它没有工作目录，只包含项目的历史记录，可以进行推送和拉取操作，但不能直接编辑。此外，不会为该裸仓库配置任何远程分支，通常用于创建开发者不直接编辑的托管仓库。
git clone --mirror：使用-mirror选项时，隐式传递了-bare选项，因此-bare的行为也适用于-mirror。这将创建一个裸仓库，没有可编辑的工作文件。此外，-mirror将克隆远程仓库的所有扩展引用，并保持远程分支跟踪配置。你可以在镜像上运行git remote update命令，它将覆盖所有来自原始仓库的引用，实现精确的"镜像"功能。
git clone --template命令克隆位于<repo location>的仓库，并将来自<template directory>的模板应用于新创建的本地分支。关于Git模板的详细参考可以在我们的git init页面找到。
本次深入研究了git clone命令，其中最重要的要点包括：

git clone用于创建目标仓库的副本。

目标仓库可以是本地的或远程的。

Git支持多种网络协议以连接到远程仓库。

有许多不同的配置选项可用于更改克隆的内容。

3. 保存更改到命令的指令

保存更改到仓库的步骤包括使用git add和git commit命令：

使用git add命令将要保存的文件或更改添加到仓库的暂存区。例如，git add CommitTest.txt将CommitTest.txt文件添加到暂存区。

使用git commit命令创建一个新的提交，提交暂存区中的更改，并附带一条描述性消息，解释这个提交所做的工作。例如，git commit -m "Add test content"会创建一个提交，其中包含了添加测试内容的更改，并附带了描述消息"Add test content"。

执行git add --all将会把仓库中所有已更改和未跟踪的文件添加到仓库的暂存区，并更新仓库的工作树（工作目录）以反映这些更改。这个命令可以用来批量添加所有更改，包括新创建的文件和修改过的文件，以便在随后的提交中包含它们。

在Git或其他版本控制系统中，"保存"的概念与在文字处理器或其他传统文件编辑应用程序中的保存更为复杂。传统软件中的"保存"等同于Git术语中的"提交"。一个提交是Git中的"保存"等效操作。传统的保存应该被视为一个文件系统操作，用于覆盖现有文件或写入新文件。相反，Git中的提交是对一组文件和目录执行的操作。在Git和SVN中，保存更改的过程也是不同的。SVN的提交或"check-in"是向集中式服务器进行远程推送的操作。这意味着SVN提交需要Internet访问才能完全"保存"项目更改。Git的提交可以在本地捕获和构建，然后根据需要使用git push -u origin main命令推送到远程服务器。这两种方法之间的区别是架构设计的根本差异。Git是分布式应用模型，而SVN是集中式模型。分布式应用通常更健壮，因为它们没有像集中式服务器那样的单一故障点。Git具有额外的保存机制，称为"stash"（藏匿）。stash是用于存储尚未准备好提交的更改的临时存储区。stash操作在工作目录上进行，这是三个树中的第一个，它具有广泛的使用选项。要了解更多信息，请访问git stash页面。Git仓库可以配置为忽略特定的文件或目录。这将阻止Git保存对任何被忽略内容的更改。Git有多种配置方法来管理忽略列表。有关Git忽略配置的详细信息，请参阅git ignore页面。

git add

git add命令将工作目录中的更改添加到暂存区。它告诉Git你想在下一次提交中包含对特定文件的更新。然而，git add并没有在仓库中产生实质性的影响，直到你运行git commit时，更改才会真正记录下来。

与这些命令一起使用时，你还需要使用git status来查看工作目录和暂存区的状态。

git add和git commit命令构成了Git工作流程的基础。无论团队的协作模型如何，每个Git用户都需要理解这两个命令。它们是将项目版本记录到仓库历史中的手段。

开发一个项目围绕着基本的编辑/暂存/提交模式展开。首先，在工作目录中编辑文件。当你准备保存项目的当前状态副本时，使用git add暂存更改。在你对已暂存的快照满意后，使用git commit将其提交到项目历史中。git reset命令用于撤销提交或已暂存的快照。

除了git add和git commit之外，第三个命令git push对于完整的协作Git工作流程至关重要。git push用于将已提交的更改发送到远程仓库以进行协作。这使得其他团队成员能够访问一组已保存的更改。

git add命令不应与svn add混淆，后者用于将文件添加到仓库。相反，git add在更抽象的层次上操作更改。这意味着每次你修改文件时都需要调用git add，而svn add只需要为每个文件调用一次。这听起来可能有些多余，但这个工作流程使得项目更容易保持有组织性。在Git中，你可以选择性地将更改添加到暂存区，而不是强制性地添加整个文件。这使得可以将相关更改分成多个提交，更精细地管理项目的版本历史。

暂存区

暂存区 git add命令的主要功能是将工作目录中的待提交更改推送到Git的暂存区。暂存区是Git的一个比较独特的特性，如果你来自SVN（甚至是Mercurial）的背景，可能需要一些时间来理解它。将其视为工作目录和项目历史之间的缓冲区可能有助于理解。暂存区被认为是Git的"三棵树"之一，包括工作目录、暂存区和提交历史。

与将自上次提交以来所做的所有更改一起提交不同，暂存区允许你将相关更改分组到高度聚焦的快照中，然后再将其实际提交到项目历史中。这意味着你可以对无关的文件进行各种编辑，然后返回并将它们拆分成逻辑提交，通过将相关更改添加到暂存区并逐个提交它们。与任何版本控制系统一样，创建原子提交是重要的，这样就可以轻松追踪错误并在对项目的其余部分产生最小影响的情况下撤消更改。

交互式

将<directory>中的所有更改暂存以供下一次提交。

使用git add -p开始一个交互式的暂存会话，允许你选择要添加到下一次提交的文件部分。这将呈现给你一块更改并提示你输入命令。使用y来暂存这一块，使用n来忽略这一块，使用s将其拆分成更小的块，使用e来手动编辑这一块，使用q来退出。这个交互式方式可以帮助你更精细地管理要提交的更改。

总结

回顾一下，git add是一系列操作中的第一个命令，它指示Git将当前项目状态的"快照"保存到提交历史中。当单独使用时，git add将从工作目录提升待提交的更改到暂存区。git status命令用于检查仓库的当前状态，并可用于确认git add的推送。git reset命令用于撤销git add的操作。然后，git commit命令用于将暂存目录的快照提交到仓库的提交历史中。这是Git中保存更改并记录项目历史的基本工作流程。

3. 仓库之间的协作git push

理解Git的“工作副本”概念与从SVN仓库检出源代码得到的工作副本有很大的不同是很重要的。与SVN不同，Git不区分工作副本和中央仓库，它们都是完全成熟的Git仓库。

这使得与Git合作与与SVN合作根本不同。而SVN依赖于中央仓库和工作副本之间的关系，Git的协作模型是基于仓库与仓库之间的交互。与将工作副本检入SVN的中央仓库不同，你可以从一个仓库推送或拉取提交到另一个仓库。

当然，你可以给某些Git仓库特定的含义。例如，通过简单地将一个Git仓库指定为“中央”仓库，可以使用Git复制中心化的工作流程。这是通过约定而不是通过版本控制系统本身的硬编码来实现的。

裸仓库与克隆仓库的区别：

如果在前面的“初始化一个新仓库”部分中使用了git clone来设置你的本地仓库，那么你的仓库已经配置好了用于远程协作。
git clone会自动为你的仓库配置一个指向你克隆的Git URL的远程仓库。这意味着一旦你对文件进行了更改并提交了它们，你就可以使用git push将这些更改推送到远程仓库。

$ git push <remote> <branch>$ git push <remote> --all //将所有的branches都推送到远程仓库中
git push 是 Git 同步过程中的一个组成部分。同步命令操作远程分支，这些分支是使用 git remote 命令配置的。git push 可以被视为一个 '上传' 命令，而 git fetch 和 git pull 可以被视为 '下载' 命令。一旦变更集通过下载或上传被移动，就可以在目标地点执行 git merge 以集成这些变更。

有时分支需要进行清理以进行簿记或组织目的。要完全删除一个分支，必须在本地和远程都删除它。（完全删除一个分支）

上述命令将删除名为 branch_name 的远程分支。通过在 git push 中传递一个以冒号为前缀的分支名，可以删除远程分支。

git pull 是许多命令之一，负责“同步”远程内容。git remote 命令用于指定同步命令将操作的远程端点。git push 命令用于将内容上传到远程仓库。

git fetch 命令可能与 git pull 混淆。它们都用于下载远程内容。git pull 和 git fetch 之间有一个重要的安全区别。git fetch 可以被认为是“安全”的选项，而 git pull 可以被认为是不安全的选项。git fetch 将下载远程内容，但不会改变本地仓库的状态。相反，git pull 将下载远程内容并立即尝试更改本地状态以匹配该内容。这可能会意外地导致本地仓库陷入冲突状态。

git commit命令是Git中的一个基本操作，用于保存暂存的项目更改到项目历史记录中。在提交之前，您应该使用git add选择要包含在提交中的更改。git commit创建了这些暂存更改的快照，并将其记录在项目的历史记录中。要检查暂存区和待提交更改的状态，可以使用git status命令。

值得注意的是，Git中的提交模型与SVN中的提交模型有很大的不同。Git提交非常高效，应该经常使用，而SVN提交涉及更多的开销，较不频繁。了解这种差异对于从SVN过渡到Git很重要。

如果本地分支的名称与远程仓库中的分支名称不一样，通常会发生以下情况：

本地分支推送到远程仓库： 当您使用 git push 命令推送本地分支时，Git 会尝试将本地分支的更改推送到与本地分支同名的远程分支。如果找不到同名的远程分支，Git 将创建一个新的远程分支，并使用本地分支的名称作为远程分支的名称。

例如，如果您有一个本地分支叫做 feature，并且要推送它到远程仓库，Git 将尝试推送到名为 origin/feature 的远程分支。如果 origin/feature 不存在，Git 将创建它。

推送到不同名称的远程分支： 如果您希望将本地分支推送到远程仓库中的不同名称的远程分支，可以使用以下命令：

这将允许您将本地分支的更改推送到与指定的远程分支名称不同的远程分支上。例如，如果您希望将本地的 feature 分支推送到远程的 new-feature 分支，可以执行：

总之，如果本地分支的名称与远程仓库的分支名称不一样，Git 通常会根据一定的规则尝试将更改推送到相应的远程分支，或者您可以使用显式命令来指定推送的目标分支。确保在推送前仔细检查分支名称以避免不必要的混淆。

4. 配置与设置conflig

配置与设置：git config 一旦你设置好了远程仓库，你就需要将远程仓库的URL添加到你的本地git配置中，并为你的本地分支设置上游分支。git remote命令提供了这样的实用功能。

使用以下命令将远程仓库映射到你的本地仓库：

这个命令将把远程仓库映射到你本地仓库的一个引用下。一旦映射了远程仓库，你就可以将本地分支推送到它上面：

这个命令将把本地仓库中的分支（在 <local_branch_name> 下）推送到位于 <remote_name> 的远程仓库中。

要深入了解git remote，请参阅Git远程页面。

除了配置远程仓库的URL，你可能还需要设置全局的Git配置选项，如用户名或邮箱。git config命令允许你从命令行配置你的Git安装（或一个单独的仓库）。这个命令可以定义从用户信息到偏好设置再到仓库行为等方面的内容。下面列出了一些常见的配置选项。

在这个文档中，我们将深入探讨git config命令。我们在设置仓库页面上简要讨论了git config的用法。git config命令是一个方便的函数，用于在全局或本地项目级别上设置Git配置值。这些配置级别对应于.gitconfig文本文件。执行git config将修改一个配置文本文件。我们将涵盖常见的配置设置，如电子邮件、用户名和编辑器。我们将讨论Git别名，允许你为经常使用的Git操作创建快捷方式。熟悉git config和各种Git配置设置将帮助你创建一个强大的、定制的Git工作流程。
在进一步讨论git config的用法之前，让我们花一点时间了解配置级别。git config命令可以接受参数来指定要操作的配置级别。以下是可用的配置级别：
-local 默认情况下，如果没有传递配置选项，git config将写入本地级别。本地级别配置适用于git config被调用的上下文仓库。本地配置值存储在一个文件中，可以在仓库的.git目录中找到：.git/config
-global 全局级别配置是特定于用户的，这意味着它适用于操作系统用户。全局配置值存储在位于用户主目录中的文件中。在Unix系统上是~/.gitconfig，在Windows上是C:\Users<用户名>.gitconfig。
-system 系统级别配置适用于整个计算机。这包括操作系统上的所有用户和所有仓库。系统级别配置文件位于系统根路径下的gitconfig文件中。在Unix系统上是$(prefix)/etc/gitconfig。在Windows上，这个文件可以在Windows XP的C:\Documents and Settings\All Users\Application Data\Git\config中找到，在Windows Vista及更高版本中可以在C:\ProgramData\Git\config中找到。
因此，配置级别的优先顺序是：本地，全局，系统。这意味着在查找配置值时，Git将从本地级别开始，然后向上冒泡到系统级别。

5. git commit和git add

git commit命令是Git中的一个基本操作，用于保存暂存的项目更改到项目历史记录中。在提交之前，您应该使用git add选择要包含在提交中的更改。git commit创建了这些暂存更改的快照，并将其记录在项目的历史记录中。要检查暂存区和待提交更改的状态，可以使用git status命令。

值得注意的是，Git中的提交模型与SVN中的提交模型有很大的不同。Git提交非常高效，应该经常使用，而SVN提交涉及更多的开销，较不频繁。

6.远程同步仓库

远程连接到仓库

目前的版本只能使用SSH版本的

当使用 git push 命令时，您需要提供远程仓库的名称以及要推送的本地分支和远程分支的名称。以下是一些示例 git push 操作：

推送本地分支到远程分支：

假设您有一个本地分支叫做 "feature"，您希望将其推送到名为 "feature" 的远程分支：

这会将本地 "feature" 分支的更改推送到远程仓库的 "feature" 分支。

推送本地分支到同名的远程分支：

如果本地分支与远程分支具有相同的名称，您可以简化命令，只需执行：

这将默认将本地 "feature" 分支的更改推送到远程 "feature" 分支。

推送所有分支到远程仓库：

如果您想将所有本地分支的更改都推送到远程仓库，可以使用以下命令：

这将推送所有本地分支（除了未跟踪的分支）到远程仓库。

删除远程分支：

如果要删除远程仓库上的分支，可以使用以下命令，其中 <分支名称> 是要删除的远程分支的名称：

这将删除指定的远程分支。

这些示例涵盖了一些常见的 git push 操作。请根据您的具体情况和需求来执行相应的操作。确保在执行推送操作之前，您已经添加、提交并合并了您的更改。

7.创建分支

Git 中的分支操作包括创建、切换、合并、删除等一系列操作。以下是一些常见的 Git 分支操作：

创建分支： 使用以下命令可以创建一个新分支：

切换分支： 使用以下命令可以切换到一个已存在的分支：

或者可以使用以下命令创建并切换到一个新分支：

查看分支： 使用以下命令可以查看所有分支以及当前所在的分支：

合并分支： 使用以下命令可以将一个分支的更改合并到当前分支：

删除分支： 使用以下命令可以删除一个分支：

如果要强制删除分支，即使它包含未合并的更改，可以使用 -D 选项：

重命名分支： 使用以下命令可以重命名一个分支：

查看分支历史： 使用以下命令可以查看分支历史及其提交记录：

推送分支： 使用以下命令可以将本地分支推送到远程仓库：

或者使用以下命令将当前分支推送到远程分支：

git rebase 是 Git 中一个强大的命令，它用于修改提交历史，通常用于将一个分支的提交移动到另一个分支上或者合并分支时优化提交历史。下面是 git rebase 的一些常见用法：

git pull 用于从远程仓库拉取最新代码并合并到本地工作目录。

更具体的用法包括：

其中 <branch-name> 是你想要拉取的远程分支的名称。默认情况下，它会拉取当前分支的最新代码。

如果你想要重新拉取整个历史，并强制覆盖本地更改，可以使用：

确保在执行前先备份任何重要的本地更改。

将当前分支的提交移动到另一个分支上：

这将会将当前分支的提交迁移到目标分支上，使得提交历史更加线性。

交互式 rebase：

使用交互式 rebase 可以更精细地控制提交历史。您可以合并、编辑、删除提交等。

跳过某些提交：

有时，您可能不希望移动所有的提交，您可以使用 -i 选项并在交互式 rebase 中跳过不需要的提交。

将分支拉取并进行 rebase：

您可以将远程分支拉取到本地并在本地进行 rebase 操作。

这将从远程仓库拉取 <分支名称> 并在本地进行 rebase 操作。

终止 rebase：

如果在 rebase 过程中出现问题，您可以使用以下命令终止 rebase 并回到之前的状态：

这些只是 git rebase 的一些常见用法。请注意，git rebase 可能会修改提交历史，因此在多人协作项目中使用时要小心谨慎，并与团队协商使用方式。

8.删除远端仓库上的对应文件

要删除远程仓库上的文件，您可以采取以下步骤：

使用 Git 删除文件： 首先，在本地仓库中删除要删除的文件。您可以使用以下命令从本地文件系统中删除文件：

或者如果您只删除了文件但未告知 Git，可以使用以下命令：

这将标记已删除的文件以供提交。

提交更改： 提交删除文件的更改到本地仓库：

推送更改到远程仓库： 最后，将更改推送到远程仓库：

请确保将 <分支名称> 替换为您要推送的分支名称。这将在远程仓库中删除相应的文件。

🛫

下面是常见的在Git问题上面可能遇到的问题

Q1：How do I force "git pull" to overwrite local files?

大致意思是说如何使用git-pull来强制归并本地和git仓库中都有的相同文件的名字

⚠️

waring：任何通过git但是没有提交的文件都会丢失，但是本地文件中那些没有参与到git中的文件不会收到任何的影响

第一步，首先update所有的 orgin/branch 到最新的状态

第二步，回到你当前的分支上去

第三步，回到最后一次提交的位置那里，然后重新检查最后一次提交那里的文件

🧑‍🦯

下面对上面的操作进行对应的原理解释：

git fetch 下载了最新最远端的分支，不需要合并或者是重写任何东西

git reset 将主分支重置为您刚刚获取的内容。——hard选项会将工作树中的所有文件更改为与origin/master中的文件匹配。

✅

值得注意的是，可以通过在重置之前从master创建分支来维护当前的本地提交,这样就可以避免导致本地没有提交的文件丢失的情况了

在进行这次操作之后，所有的文件都会被保留在 new-branch-to-save-current-commits 这个新分支当中，这样完成之后就可以较好的解决上面的问题了