前段时间感冒,好久没更CSDN了,现在整理一篇git,现在大部分的开发团队都以 Git 作为自己的版本控制工具,需要对 Git 的使用非常的熟悉。这篇文章中本人整理了自己在开发过程中经常使用到的 Git 命令,方便在偶尔忘记时速查。
Git是一个开源的分布式版本控制系统,主要用于管理软件开发过程中的版本控制。它提供了一种高效的方式来跟踪、管理和协作代码更改,从很小的项目到非常大的项目都可以使用Git进行版本控制。Git由Linus Torvalds于2005年开发,最初是为了替代BitKeeper作为Linux内核开发的版本控制软件。Git通过记录每次对文件的更改,可以轻松地回溯、查看历史记录、恢复误删除的文件等,从而帮助开发人员更好地协作和管理代码。
git基础命令
git clone: 克隆远程Git仓库到本地的命令
git clone是一个用于克隆远程Git仓库到本地的命令。通过执行git clone命令,你可以将远程仓库的所有历史记录和文件复制到本地,从而在本地进行修改、提交和推送等操作。
要使用git clone命令,你需要提供远程仓库的地址。这个地址可以是HTTP、HTTPS、SSH或Git等协议的URL。例如:
git clone https://gitee.com/openharmony/arkcompiler_ets_runtime.git
上述命令将克隆名为arkcompiler_ets_runtime的远程仓库到本地的当前目录下。你可以将openharmony/arkcompiler_ets_runtime.git替换为你要克隆的远程仓库的实际地址。
如果你希望克隆的仓库使用SSH协议,你可以提供SSH地址,并确保你已经设置了正确的SSH密钥对。例如:
git clone git@gitee.com:openharmony/arkcompiler_ets_runtime.git
克隆过程中,Git会获取远程仓库的所有历史记录和文件,并在本地创建一个完整的副本。一旦克隆完成,你就可以在本地进行修改、提交等操作,并将更改推送到远程仓库。
需要注意的是,克隆操作可能需要一些时间,具体取决于远程仓库的大小和你的网络速度。在克隆过程中,Git会显示正在复制的对象和进度信息。
git clone -b: 克隆指定分支的Git命令
git clone -b 是一个用于克隆指定分支的Git命令。通过使用 -b 参数,你可以在克隆仓库时指定要克隆的特定分支。这对于只克隆特定分支的内容非常有用,例如当你只需要某个特定分支的开发代码时。
例如,如果你想克隆名为 master2 的分支,可以使用以下命令:
git clone -b master2 <repository_url>
上述命令将克隆名为 master2 的分支,并下载该分支的所有历史记录和文件到本地。在本地,你可以在该分支上工作并进行提交,但如果你需要推送更改回远程仓库,你需要先切换到远程仓库的相应分支。
需要注意的是,如果省略 -b 参数,git clone 默认会克隆主分支(通常是 master 或 main 分支)
git branch: 创建、删除和查看分支
在Git中,git branch是一个用于创建、删除和查看分支的命令。分支是版本控制中的一个重要概念,它允许开发人员在同一个版本库中并行推进多个任务。每个分支都是一个独立的副本,可以在不影响主线分支的情况下进行开发。
以下是关于git branch命令的一些常用操作:
1.创建分支:使用git branch <分支名称>
命令可以创建一个新的分支。例如,git branch feature-A
将创建一个名为feature-A
的分支。
2.切换分支:使用git checkout <分支名称>
命令可以切换到指定的分支。例如,git checkout feature-A
将切换到feature-A
分支。
3.删除分支:使用git branch -D <分支名称>
命令可以删除指定的分支。例如,git branch -D feature-A
将删除名为feature-A
的分支。
4.查看分支:使用git branch
命令可以查看本地所有的分支。当前活跃的分支前面会有一个星号(*)。
5.查看本地与远程分支:git branch -a
是一个用于查看所有本地分支和远程跟踪分支的Git命令。这个命令将列出本地仓库中所有的分支,包括本地分支和远程跟踪分支。
git status: 是显示工作目录和暂存区的状态信息的Git命令
git status
git status是一个用于显示工作目录和暂存区的状态信息的Git命令。它用于查看哪些文件被修改、添加或删除,以及哪些文件还没有被Git跟踪。
git status命令将列出当前工作目录中的状态信息,包括:
修改的文件:这些文件已经被修改,但还没有被提交到暂存区。
未跟踪的文件:这些文件是新添加到工作目录的,还没有被Git跟踪。
已暂存的文件:这些文件已经被添加到暂存区,可以被提交到仓库。
已删除的文件:这些文件已经被删除,并从工作目录移到了暂存区。
此外,git status还会显示当前分支的信息,以及最后一次提交的哈希值和提交信息。
这个命令对于了解当前工作目录的状态和确定下一步操作非常有用。你可以根据git status的输出来决定是否需要执行提交、添加、删除等操作。
git checkout: 切换分支或恢复工作区的命令
git checkout是一个用于切换分支或恢复工作区的命令。它的功能多样,具体用法如下:
切换分支:git checkout <branch>
。这个命令会切换到指定的分支。
恢复工作区:git checkout .
。这个命令会恢复工作区的所有更改,未跟踪的文件不会有变化。恢复工作区的所有文件风险比较大,会丢失所有工作区的修改,一定要慎用。
恢复单个文件:git checkout <file>
。这个命令可以只恢复单个文件。
版本切换:git checkout <commit>
。这个命令可以取出某个版本的提交,HEAD会指向当前分支,与分支不动,造成HEAD和分支分离。
总的来说,git checkout命令用于切换分支或者恢复工作区,其具体用法会因命令参数的不同而有所差异。在实际使用时,需要结合具体情况选择合适的用法。
git checkout -b: 用于创建并切换到新分支的命令
git checkout -b 是一个用于创建并切换到新分支的命令。
这个命令会创建一个新的分支,并将当前HEAD切换到这个新分支上。新分支的名称可以通过指定参数来指定。例如,git checkout -b new-branch
将会创建一个名为 new-branch
的新分支,并将当前HEAD切换到这个新分支上。例如:
git checkout -b new-branch
这个命令可以用于创建新的开发线或者处理特定的问题。一旦创建了新的分支,就可以在这个分支上独立地进行更改,而不会影响到其他分支。
需要注意的是,在使用 git checkout -b
命令创建新分支之前,需要先确认当前所在的分支。如果在未指定分支名称的情况下使用 git checkout -b
命令,将会在当前所在分支上创建一个新的分支。
此外,如果新分支已经存在,使用 git checkout -b
命令将会覆盖已有的分支,并切换到这个分支上。因此,在执行这个命令之前,需要确保不会误操作到已有的分支。
git add: 将文件添加到Git暂存区的命令
git add是一个用于将文件添加到Git暂存区的命令。暂存区是一个区域,用于存储尚未提交的更改。当你使用git add命令时,你告诉Git你想要将某个文件或更改添加到暂存区,以便稍后提交。
git add命令可以用于添加单个文件或多个文件。例如,要添加一个名为file1.txt的文件,你可以运行以下命令:
git add file1.txt
如果要添加多个文件,你可以指定多个文件名,用空格分隔。例如:
git add file2.txt file3.txt
此外,你还可以使用通配符来添加具有特定模式的文件。例如,要添加所有.txt文件,你可以运行以下命令:
git add *.txt
除了添加单个文件或多个文件外,你还可以使用git add命令将整个目录添加到暂存区。例如:
git add ./path/to/directory
git add .是一个用于将所有更改添加到Git暂存区的命令。这个命令会将当前目录下的所有修改过的文件和新增文件添加到暂存区,但不会包括已删除的文件:
git add .
git commit: 将暂存区的更改提交到本地仓库中
在Git中,git commit是一个非常重要的命令,用于将暂存区的更改提交到仓库中。每次提交都会生成一个唯一的标识符,以便于回溯和管理代码的历史。
提交的目的是为了记录代码的变动和历史。通过git commit,我们可以追踪代码的演进过程,了解每一次变动的原因和影响。同时,git commit也是Git协作的基础,允许多个开发者在同一个代码库中进行并行开发,并能够合并彼此的代码变动。
在执行git commit之前,通常需要先使用git add命令将需要提交的更改添加到暂存区。然后,执行git commit命令来进行提交操作。例如:
git add .
git commit -m "提交信息"
在上面的命令中,.表示添加当前目录下的所有修改过的文件和新增文件到暂存区。-m参数后面是提交的说明信息,描述了本次提交的内容和变更。
需要注意的是,每次提交都应该包含有用的信息,以便于其他开发者理解代码变动的目的和影响。同时,如果可能的话,应该尽量保持提交的粒度,每个提交只解决一个具体的问题或实现一个具体的功能。这样可以让代码的历史更清晰,便于追踪和管理。
git push: 将本地分支的更新推送到远程主机的Git命令
git push的一般形式为 git push <远程主机名> <本地分支名> <远程分支名> ,例如:
git push origin master :refs/for/master
即是将本地的master分支推送到远程主机origin上的对应master分支。origin 是远程主机名,第一个master是本地分支名,第二个master是远程分支名。
git push命令需要指定远程主机的名称和要推送的本地分支的名称。例如,如果要将本地的master分支推送到名为origin的远程主机,可以运行以下命令:
git push origin master
这将会将本地的master分支的更改推送到远程主机的master分支上。
如果本地分支与远程分支存在追踪关系,则可以使用简写形式来推送更改。例如,如果本地分支与远程分支同名,可以使用以下命令来推送更改:
git push origin
这将会将当前分支的更改推送到与之存在追踪关系的远程分支上。
需要注意的是,在推送更改之前,应该确保本地分支的代码已经通过测试并且没有问题。同时,也应该确保已经与远程仓库同步,以避免冲突和数据丢失。
git 其他命令
git pull: 从远程仓库获取更新并合并到当前分支的命令
git pull是一个用于从远程仓库获取更新并合并到当前分支的命令。它执行了两个操作:从远程仓库拉取最新的更改(使用git fetch),并将这些更改合并到当前分支(使用git merge)。
默认情况下,git pull会从当前配置的远程仓库获取最新更改,并将其合并到当前所在的分支。如果当前分支只有一个追踪分支,则可以省略远程仓库名。
例如,要从名为origin的远程仓库的master分支获取更新,并 合并到当前分支,可以运行以下命令:
git pull origin master
如果当前分支与远程分支存在追踪关系,则可以省略远程仓库名和分支名。例如:
git pull origin
这将会从名为origin的远程仓库的追踪分支获取最新更改,并将其合并到当前分支。
需要注意的是,git pull命令实际上是git fetch + git merge
的简写版。如果你希望仅执行git fetch
操作而不进行合并,可以使用git fetch origin master
命令。同样地,如果你希望手动进行合并而不执行自动合并,可以使用git merge origin/master
命令。
git pull origin 远程分支名: 拉取远程分支代码
git pull 分支名
下拉的只是本地的分支,而想要拉取远程分支需要加origin才可以,命令git pull origin 远程分支名
。所有远程分支可以通过git branch -a
来查看
例如:
git log: 查看提交历史的命令
git log是一个用于查看提交历史的命令。通过git log,你可以查看项目的提交记录,包括提交的哈希值、作者、提交时间、提交说明等信息。
默认情况下,git log会按照提交的时间顺序显示所有的提交记录。你可以通过添加参数和选项来定制git log的输出,例如使用-p参数可以显示每次提交的差异,使用–oneline参数可以将多行输出简化为单行输出等。
例如,要查看最近10次提交的简短信息,可以使用以下命令:
git log -10
要查看某个特定分支的提交历史,可以使用–branch参数。例如:
git log feature/new-feature
这将显示名为feature/new-feature分支的所有提交记录。
另外,你还可以使用各种选项来定制git log的输出。例如:
- -p:显示每次提交的差异。
- –stat:显示每次提交的文件统计信息。
- –patch或-p:显示补丁。
- –oneline:在一行中显示每个提交。
- –graph:显示提交历史的图形表示。
- –all:显示所有分支的提交记录。
- –branches:显示所有分支的提交记录。
- –tags:显示所有标签的提交记录。
可以根据需要组合这些选项来查看详细的提交历史信息。
git rebase:变基(内涵流程时间线图)
git rebase 是一个 Git 命令,主要用于将一个分支的提交合并到另一个分支上。在进行 rebase 操作时,Git 会提取当前分支(待变基分支)上的修改,然后将其应用到目标分支(基分支)的最新提交上。这样,待变基分支就会基于目标分支的最新状态,形成一个线性的提交历史。
具体过程如下:
- 找到两个分支的共同祖先。
- 从共同祖先开始,提取待变基分支上的修改,并临时保存为 patch 文件。
- 将待变基分支更新到目标分支的最新提交。
- 将之前保存的 patch 文件应用到更新后的待变基分支上。
具体流程图如下:
git rebase 的主要优点是能够保持一个干净、线性的提交历史,便于代码审查和理解项目演进过程。然而,它也有一些潜在的风险,比如在处理合并冲突时可能会引入错误,或者在多人协作的环境中可能导致提交历史的混乱。因此,在使用 git rebase 时需要谨慎操作,确保理解其工作原理和潜在影响。
以下是一个简单的git rebase
的例子(如上图):
假设你正在开发一个新功能,并且创建了一个新的分支(feature
)。在feature分支上,你进行了多次提交(C1, C2, C3
)。然后,主分支(master
)上有一些新的提交(M1, M2
)。
你想要将你的feature分支上的修改合并到主分支上。一种常见的方法是使用git merge
,但如果你想要保持一个线性的提交历史,可以使用git rebase
。
步骤如下:
在feature
分支上,运行 git fetch
获取最新的远程仓库状态。
运行 git rebase master
,将feature
分支的修改合并到主分支上。
在这个过程中,Git会找到feature
分支和主分支的共同祖先(也就是B
),然后将C1, C2, C3
提交应用到M2
提交上。因此,feature
分支现在基于主分支的最新提交(M2
),而不是之前的B
。
注意:如果在rebase
过程中出现合并冲突,需要手动解决冲突,然后使用 git add .
命令标记冲突已解决,最后使用 git rebase --continue
继续进行rebase
操作。如果想要放弃rebase
操作,可以使用 git rebase --abort
命令。
git apply xx.diff:打补丁
Git 提供了两种补丁方案,一是用git diff生成的UNIX标准补丁.diff文件,二是git format-patch生成的Git专用.patch 文件。
- diff文件只是记录文件改变的内容,不带有commit记录信息,多个commit可以合并成一个diff文件。
- patch文件带有记录文件改变的内容,也带有commit记录信息,每个commit对应一个patch文件。
我这里使用的是git apply打补丁的方式:git-apply专门用来apply那些用git-diff生成的补丁
git apply xx.diff
操作步骤:
1、每次提交commit都会有记录id,提交到主仓也会有每次提交的变化补丁,把补丁下载下来。
2、把下载好的补丁放到要修复的本地代码仓里:
3、打补丁:
git apply xx.diff
4、提交代码就好了,不要把补丁一块提交了。可以
删掉补丁
后git add .
全提交,也可以git add test
只提交修改代码