git 使用手册

1， 常用命令

git新建/切换分支

//不带参数，列出已经存在的远程分支
git remote 

// 查看分支
git branch

//查看远程分支
git branch -a  

//切换分支
git checkout <name> 

//创建分支的同时切换到该分支（写法2）
git checkout -b <name>    

git分支和远程交互

//将本地的仓库和远程的仓库关联起来
git branch --set-upstream-to=origin/remote_branch your_branch

// 如果远程新建了一个分支，本地没有该分支。可以利用，
// 这时本地会新建一个分支名叫 branch_name ，会自动跟踪远程的同名分支 branch_name。
// 如果报错，就切换到 master 分支 , pull 下 ，在输入上述命令
git checkout --track origin/branch_name

// 本地有，远程没有
git push --set-upstream origin branch_name    

Git 撤销 提交的 commit

git reset --soft HEAD^

删除远程分支

git push origin :branchName  //删除远程分支  
git push origin --delete stark # 删除远程分支stark  

删除本地分支

git branch -d branchName     // 删除本地分支，强制删除用-D  
git branch -d stark      // 删除本地stark分支   
git branch -D stark      // 强制删除本地stark分支

git 暂存代码

在开发中经常会遇见：正在A分支开发，但是有紧急需求需要在B分支处理，此时A分支代码没有开发完整，又不能提交代码，这个时候暂存本地代码就非常的YYDS了！

// 查看当前修改的文件
git status  

//暂存当前未commit的代码
git stash  

//暂存当前未commit的代码并添加备注
git stash save "备注的内容"  

//查看所有stash记录
git stash list  

//应用最近一次stash
git stash apply  

//应用指定的stash
git stash apply stash@{序号} 

// 应用最近一次stash并删除其记录
git stash pop

// 应用指定的stash并删除其记录
git stash pop stash@{序号}

// 删除最近一次stash
git stash drop 

//删除指定的stash
git stash drop  stash@{序号} 

//删除所有stash记录
git stash clear 

修改git commit 信息

比如：修改最近的五次commit记录信息

这个过程涉及到几个步骤，包括使用交互式变基、修改提交信息、解决冲突，以及最后的强制推送。下面是详细的步骤：

1. 开始交互式变基

首先，你需要打开终端并定位到你的Git仓库目录。使用以下命令开始交互式变基，回溯你想要修改的提交数量，这里是5次：

git rebase -i HEAD~5

这个命令会在默认的文本编辑器中打开一个列表，显示最近的5个提交。

2. 选择要修改的提交

在打开的编辑器中，你会看到类似下面的内容：

pick e3a1b35 提交信息1
pick 7ac9a67 提交信息2
pick 1d2a3f4 提交信息3
pick 76f4a1b 提交信息4
pick 4b2b9d6 提交信息5

对于你想要修改提交信息的每个提交，将行首的 pick 改为 reword。例如，如果你想修改所有五个提交的信息，你应该修改它们如下：

reword e3a1b35 提交信息1
reword 7ac9a67 提交信息2
reword 1d2a3f4 提交信息3
reword 76f4a1b 提交信息4
reword 4b2b9d6 提交信息5

保存并关闭编辑器后，Git将依次为每个标记为 reword 的提交打开一个新的编辑器窗口，让你输入新的提交信息。

3. 输入新的提交信息

每次编辑器打开时，输入你想要的新提交信息，保存并关闭编辑器。这将更新每个提交的信息。

4. 完成变基

如果在变基过程中没有冲突，Git将自动完成变基。如果出现冲突，Git会暂停并让你解决冲突。解决每个冲突后，你需要运行：

git add <解决冲突的文件>
git rebase --continue

重复此过程直到所有冲突都解决，并且变基完成。

5. 强制推送到远端

由于你已经改变了提交的历史，你需要使用强制推送来更新远端仓库。这可以通过以下命令完成：

git push --force-with-lease origin main

确保将 main 替换为你的实际分支名。

注意事项

• 通知团队成员：在执行这些操作之前，确保通知所有团队成员，因为这将影响他们的本地仓库。
• 备份：在进行这样的操作之前，建议备份你的仓库，以防万一操作出错。

通过这些步骤，你可以安全地修改已经推送到远端的提交信息。

git 子仓管理

Git 子仓库（Git Submodule）是 Git 版本控制系统中的一个功能，用于将一个 Git 仓库作为另一个 Git 仓库的子目录。这使得你可以在一个项目中引用另一个项目，同时保持它们的版本控制独立。这在多个项目需要共享代码或资源时非常有用。

使用 Git 子仓库的主要优点如下：

1. 代码重用：子仓库允许你在不同的项目中重用相同的代码库，而不需要复制或创建新的副本。
2. 版本控制：子仓库保持了它自己的版本控制历史，这意味着它的更改不会影响到主仓库。
3. 独立开发：子仓库可以独立于主仓库进行开发和维护，这有助于团队在不同的项目中进行协作。
4. 易于集成：通过 Git 子仓库，你可以轻松地将外部项目集成到你的主项目中，同时保持版本控制的一致性。

在使用 Git 主仓库（主仓）和子仓库（子仓）时，需要注意它们之间的版本控制是相互独立的。这意味着主仓和子仓的代码提交是分开进行的。这里是如何理解并处理主仓和子仓之间的代码提交的：

1. 子仓的代码提交：

   当你在子仓中进行更改时，你需要在子仓的目录中执行 git add、git commit 和 git push 等操作。这样，子仓的更改将被推送到子仓的远程仓库。请注意，这些操作不会影响主仓的版本控制。

2. 主仓的代码提交：

   当你在主仓中进行更改时（包括添加、删除或修改子仓），你需要在主仓的目录中执行 git add、git commit 和 git push 等操作。这样，主仓的更改将被推送到主仓的远程仓库。

   如果你更新了子仓（例如，检出了子仓的新分支或提交了新的更改），你需要在主仓中提交子仓的引用更新。这是因为主仓实际上存储了指向子仓特定提交的引用，而不是子仓的整个代码。

如果需要更新子仓，则在项目里面，切换到子仓的目录下

git checkout master
git pull
git checkout -b dev/xxx

//修改子仓代码
git add .
git commit -m "fix : 修复XXX"
git push origin

然后主仓会生成一个子仓的提交记录

要提交子仓的引用更新，请在主仓中执行以下操作：

git add .
git commit -m "fix : 更新子仓"
git push origin

即可对子仓代码进行修改

git和GitHub的关联

（1）GitHub GitHub 是一个商业网站，是当前全球最大的 Git 服务器。

Git 和 GitHub 的区别：Git 是一款版本控制软件，而 GitHub 是一个商业网站， 其本体是一个 Git 服务器，但这个网站上的应用程序可以让大家通过 Web 操作，来 完成原本要用复杂的 Git 指令才能做到的操作。

GitHub 的具体使用步骤，可访问以下网页：

www.runoob.com/w3cnote/git…

也可以使用码云：gitee.com/ 作为远程仓库。

GitHub 支持团队协同开发，另外 Idea 中也支持 GitHub 的应用，可自行查阅相 关材料进行自学

Git配置SSH Key

git config --global user.name "用户名"
git config --global user.email "绑定的电子邮箱"
ssh-keygen -t rsa -C“绑定的电子邮箱”
cat ~/.ssh/id_rsa.pub

如何将本地的项目上传到GitHub上?

git init  //把这个文件夹变成Git可管理的仓库

git add .
git commit -m "aaa"


//在Github上创建好Git仓库之后我们就可以和本地仓库进行关联了
 git remote add origin https://github.com/guyibang/TEST2.git
//或者
 git remote add origin git@github.com:GDUFS-IIIP-DEV/yunyin.git

git push -u origin master // 由于新建的远程仓库是空的，所以要加上-u这个参数

git push origin master //等远程仓库里面有了内容之后，下次再从本地库上传内容的时候只需这样就可以了


git pull --rebase origin master //当github上的仓库不是空的时，即在GitHub上创建仓库的时候勾选了创建README.md文件时，要先pull

git log --oneline --graph //以简洁的方式显示 git 记录


git log -最近提交的次数 //查看最近几次的 git 记录


Git rm 文件名 --cached //某个文件不再被 Git 控制


Git mv hello.txt world.txt //更新文件名

Git checkout 文件名 //找回已删除的文件： 

Git reset master^ //撤销某次 commit

git rebase

git rebase 是一个 Git 命令，用于将一个分支的修改重新应用到另一个分支上。它主要用于使提交历史更加清晰和线性。通过使用 rebase，可以把多个分支的改动整理成一个直线（线性）的历史，避免在 Git 历史中出现不必要的合并提交。

以下是一个简单的例子来说明 git rebase 的用法：

假设我们有一个项目，其中包含两个分支：master 和 feature。master 分支有两个提交，而 feature 分支基于 master 的第一个提交，并且增加了另外两个提交。

1. 初始状态：

   A---B  master
    \
     C---D  feature
   

   这里，A 和 B 是 master 分支上的提交，而 C 和 D 是 feature 分支上的提交。

2. 切换到 feature 分支并执行 git rebase master：

   git checkout feature
   git rebase master
   

   通过这个命令，Git 会取出 feature 分支上的改动（即 C 和 D），并尝试将它们重新应用在 master 分支的顶部（即在 B 提交之后）。

3. 重整后的状态：

   A---B  master
       \
        C'---D'  feature
   

   这里，C' 和 D' 是重新应用的提交。它们与原来的 C 和 D 提交内容相同，但它们的基本提交（或称父提交）已经变成了 B。

在实际开发中，git rebase 可以用于：

• 在将本地分支的更改合并到共享分支之前，先同步最新的共享分支的更改。
• 在创建 Pull Request（PR）之前，整理（squash）或重写提交历史，使得历史更加清晰。

需要注意的是，git rebase 会改变历史，所以在对已经推送到远程仓库的分支执行 rebase 操作时需要谨慎，因为这可能会影响其他协作者的工作流。在这种情况下，通常需要使用 git push --force 来强制推送更改。

例子

我当前分支为 feature/kavinkhuang_119750628_mie_2 我需要将master 分支上的代码应用到我当前这个分支，该怎么做

要将 master 分支上的代码应用到你当前的分支 feature/kavinkhuang_119750628_mie_2，你可以使用 git rebase 命令。下面是具体的步骤：

1. 首先，确保你的本地 master 分支是最新的。切换到 master 分支，然后从远程仓库拉取最新的代码：

   git checkout master
   git pull origin master
   

2. 切换回你的特性分支 feature/kavinkhuang_119750628_mie_2：

   git checkout feature/kavinkhuang_119750628_mie_2
   

3. 现在，你可以开始 rebase 操作，将 master 分支的更新应用到你的特性分支上：

   git rebase master
   

   这个命令会将你的 feature/kavinkhuang_119750628_mie_2 分支上的所有提交暂时“移除”，然后将 master 分支的最新提交作为基础，再将你的修改依次应用上去。

4. 如果在 rebase 过程中遇到冲突，Git 会暂停 rebase 并让你去解决冲突。解决冲突后，你需要使用以下命令继续 rebase 过程：

   git add <解决冲突的文件>
   git rebase --continue
   

   如果你决定不继续 rebase 操作，可以使用以下命令终止 rebase 进程：

   git rebase --abort
   

5. 一旦 rebase 完成并且所有冲突都被解决，如果你之前已经将 feature/kavinkhuang_119750628_mie_2 分支推送到了远程仓库，由于 rebase 改变了历史，你需要使用强制推送来更新远程分支：

   git push origin feature/kavinkhuang_119750628_mie_2 --force
   

请注意，强制推送可能会影响其他正在此分支上工作的协作者。在执行强制推送前，最好先与团队成员确认。

详细解释下git rebase master 的过程

git rebase master 是一个强大的 Git 命令，用于将一个分支的修改重新应用到另一个分支上。在这个例子中，你是从 feature/kavinkhuang_119750628_mie_2 分支进行 rebase 到 master 分支。下面详细解释这个过程：

1. 选择新的基点

当你运行 git rebase master 时，Git 首先会找到两个分支（即当前分支 feature/kavinkhuang_119750628_mie_2 和 master 分支）的共同祖先。然后，Git 将把当前分支的头部暂时移除，以 master 分支的最新提交为基点。

2. 临时移除更改

接下来，Git 会暂时移除 feature/kavinkhuang_119750628_mie_2 分支自从与 master 分支发散以来的所有提交。这些提交会被暂存起来，以便稍后重新应用。

3. 应用提交

一旦 master 分支的最新提交成为了基点，Git 接着将前面暂存的每个提交依次应用到 master 分支之上。这一过程是逐个进行的，每次应用一个提交。

4. 解决冲突

在重新应用提交的过程中，可能会遇到代码冲突，即当前特性分支的代码修改与 master 分支的最新代码不兼容。当这种情况发生时，Git 会暂停 rebase 操作，并提示你去解决这些冲突。你需要手动编辑冲突的文件，然后用 git add 命令标记为已解决冲突，接着使用 git rebase --continue 继续 rebase 过程。如果冲突太复杂或想放弃 rebase，可以使用 git rebase --abort 回到 rebase 开始前的状态。

5. 完成 Rebase

一旦所有的提交都被成功应用，并且所有的冲突都解决了，rebase 操作就完成了。此时，feature/kavinkhuang_119750628_mie_2 分支的头部会指向一个全新的提交，这个提交的内容是将 feature/kavinkhuang_119750628_mie_2 分支的更改应用在 master 分支的最新提交之上。

通过使用 rebase，你的特性分支可以模拟基于 master 分支最新状态的一个干净的历史。这使得将来合并特性分支回 master 分支时更为简洁，因为它将是一个快进合并（fast-forward merge），不会产生额外的合并提交。