Git实践——分支管理与标签管理及git个性化配置

Git实践------git远程仓库操作https://blog.csdn.net/xiaochenXIHUA/article/details/160627788

一、分支管理

1.1、合并分支时禁用Fast forward模式

合并分支时，Git默认会用【Fast forward】模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

注意：【Fast forward】模式，是直接把 master的指针直接指向了dev分支的最新提交；而如果采用【--no-ff】模式合并分支，就不能直接把master指针直接指向dev分支的最新提交， master 分支只能进行一次提交操作，简单地说就是-no-ff模式进行了一次新的 git commit 操作。

#分支管理策略------强制禁用【Fast forward】模式
#1-进入仓库中创建并进入新分支中
cd /data/gitlearn/gitdemo/
git checkout -b dev
git branch

#2-编辑新分支中的文件且添加到暂存后提交到仓库中
#2.1-给readme.txt文件追加内容
cat >>readme.txt <<EOF
test diabled merge Fast forword
EOF
#2.2-将当前目录下的所有修改内容都添加到暂存区并提交
git add .
git commit -m "强制禁用分支合并的Fast forward模式"

#3-切换到master分支中,并禁用默认的Fast forward模式合并
#注意【--no-ff】参数，表示禁用Fast forward
git checkout master
git merge --no-ff -m "master分支合并dev分支禁用默认的Fast forward模式" dev

#4-查看日志的图表记录
git log --graph  --oneline

分支策略总结（实际开发中，应按照如下4个基本原则进行分支的关联）
master分支应该是非常稳定的（也就是仅用来发布新版本，平时不能在上面干活）；
干活都在dev分支上（也就是说，dev分支是不稳定的，到某个时候【如：1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本】）；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了；
合并分支时，加上【--no-ff】参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

1.2、bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

在具体工作中，如果你的开发工作进行到一半，突然接到了修复bug的通知，那么怎么办呢？（Git提供了一个stash功能，可以把当前工作现场"储藏"起来，等以后恢复现场后继续工作）：

bug分支总结
《1》修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
《2》当手头工作没有完成时，先把工作现场git stash一下储藏起来，然后去修复bug，修复后，再【git stash pop】命令回到工作现场；
《3》在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commitID>命令，把bug提交的修改"复制"到当前分支，避免重复劳动。

#bug分支的示例
#1-进入仓库的dev分支中模拟项目开发
cd /data/gitlearn/gitdemo
git switch dev
git branch
cat >>readme.txt <<EOF
> developing func mode of current.
> EOF
cat >>sysinfo.txt <<EOF
> 获取系统的基础信息
> 获取设备的硬件信息
> EOF

#2-你正处于项目的dev分支开发过程中，且目前的开发工作还没有完成；但是，接到了需要修复BUG的任务，需要优先处理（此时可以将当前开发分支的所有内容先添加到仓库暂存区中；然后使用【git stash】命令将当前的"工作现场储藏起来"，待后续恢复现场后继续工作）
git status
git add .
git stash
git status

#3-切换到需要修复问题的分支(如master分支)然后再创建一个bug修复分支来修复bug
git switch master
git branch
git switch -c bugfix-BUG20260430
git branch
#3.1-在bug分支中编辑指定的文件修复Bug，修复完成后添加到暂存区并提交到仓库
vi readme.txt
git add readme.txt
git commit -m "bugfix-BUG2026.430"

#4-bug修复完成后，切换到当时报bug的分支中（如：master）合并修复了bug的分支
git branch
git switch master
git branch
git merge --no-ff -m"master分支合并bugfix-BUG20260430分支" bugfix-BUG20260430

#5-继续自己未完成的开发（即：切换到自己的开发分支dev中，并将当时的储藏的工作现场恢复）
#回到自己的开发分支后，执行【git status】发现工作区是干净的，刚才的工作现场存到哪去了？此时可用【git stash list】命令查看
#查看后发现工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
#《1》一是用【git stash apply】恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
#《2》另一种方式是用【git stash pop】，恢复的同时把stash内容也删了：
git switch dev
git status
git stash list
git stash pop
git status
git stash list

#6-同样的bug，如果要在dev分支上修复，是否要重复上面的操作一次？不用，有更简单方法
#为了方便操作，Git专门提供了一个【cherry-pick】+【bug分支提交后的编号ID】命令，让我们能复制一个特定的提交到当前分支
#注意，若在执行【cherry-pick】+【bug分支提交后的编号ID】命令提示"错误：您的本地修改将被拣选覆盖。提示： 提交您的修改或贮藏后再继续。致命错误：拣选失败"错误信息则需要先将当前分支下的内容都添加到暂存区，然后在统一提交到仓库中后重试该命令；最后就可以查看bug修复后的文件了，已经同步到了这里的dev分支中，修复了这个bug
git branch
git cherry-pick cbce7b9

二、多人协作

2.1、查看远程分支与推送分支

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。要查看远程库的信息，用【git remote】命令：

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

#git多人协作

#1-查看远程仓库信息
git remote
git remote -v


#2-推送分支【就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上】
#注意：将本地仓库的分支推送到远程仓库的分支时，两者的分支保持一致，这样才能保证分支与分支内容一致，否则会混乱
#2.1-将本地仓库的master分支推动到远程仓库的master分支中
git branch
git switch master
git push origin master

#2.2-将本地仓库的dev分支内容推送到远程仓库的dev分支中
git branch
git switch dev
git branch
#模拟开发分支的开发过程，新增一个文件，并将这个文件上添加到本地仓库的暂存区，然后再提交到仓库中
cp /etc/yum.repos.d/epel.repo .
git add .
git commit -m "add file epel.repo"
git status
git push origin dev

2.2、拉取与推送分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

Git实践------git远程仓库操作

#从远程仓库拉取分支

#1-在新设备指定路径新生成指定名称的密钥对
ssh-keygen -t ed25519
/root/.ssh/id_ed25519_github
#由于没有使用默认的文件名称，因此需要配置SSH
vi ~/.ssh/config
#【~/.ssh/config】文件的内容
Host github.com
  HostName github.com
  User git
  IdentityFile /root/.ssh/id_ed25519_github

#2-创建存放仓库的路径并拉取仓库
#注意：当别人从远程库clone时，默认情况下，只能看到本地的main或master分支。可以用git branch命令查看 
mkdir -p /data/gitlearn
cd /data/gitlearn
git clone git@github.com:kafeiweimei/gitdemo.git
cd gitdemo
git branch

#3-现在需要开发则需要在dev分支操作，就必须创建远程origin的dev分支到本地[新版可用：git switch -c dev origin/dev]
git checkout -b dev origin/dev
git branch
#还可拉取远程master分支到本地
git checkout -b master origin/master
#切换到dev分支
git checkout dev
#可在当前的dev分支下进行开发
cat >>coffeemilk.txt <<EOF
this is a blog of coffeemilk.
EOF
git add coffeemilk.txt
git commit -m"add file coffeemilk.txt"
git branch
git push origin dev

2.3、多分支冲突的解决

当别人已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送就会出错：

多人协作的工作模式通常是这样：
《1》首先，可以试图用git push origin <branch-name>推送自己的修改；
《2》如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并； 【注意：如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>】。
《3》如果合并有冲突，则解决冲突，并在本地提交；
《4》没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

多人协作总结
1. 查看远程库信息，使用【git remote -v】； 2. 本地新建的分支如果不推送到远程，对其他人就是不可见的； 3. 从本地推送分支，使用【git push origin branch-name】，如果推送失败，先用git pull抓取远程的新提交； 4. 在本地创建和远程分支对应的分支，使用【git checkout -b branch-name origin/branch-name】，本地和远程分支的名称最好一致； 5. 建立本地分支和远程分支的关联，使用【git branch --set-upstream branch-name origin/branch-name】； 6. 从远程抓取分支，使用【git pull】，如果有冲突，要先处理冲突。

git config --global pull.rebase 值 * false = 安全合并（推荐） * true = 线性整洁（高手） * only = 严格模式（几乎不用）
git config pull.rebase false → 合并（merge）【推荐新手用】 作用： 拉代码时，把远程的新提交合并到你的本地分支。 特点： * 会生成一个合并提交 * 历史记录会有分叉、再合并的痕迹 * 最安全，几乎不会弄丢代码 * 适合团队、多人协作、新手
git config pull.rebase true → 变基（rebase） 作用： 把你的本地提交 "挪" 到远程最新提交的上面，让提交线变成一条直线。 特点： * 提交历史非常干净、线性 * 不会产生合并提交 * 有一定风险：如果不会处理冲突，容易搞乱代码 * 适合熟练 Git 的人
git config pull.ff only → 仅快进（fast-forward） 作用： 只有你本地完全没改动，才能拉取成功； 只要你本地有提交，直接失败、拒绝拉取。 特点： * 极度严格 * 不允许合并、不允许变基 * 只允许 "干净更新" * 几乎不适合日常开发

#多分支冲突的解决
#1-先在A设备的dev分支编辑开发并提交到仓库中，推送到远程仓库
#1.1-切换到dev分钟
git checkout dev
git branch

#1.2-在本地仓库的dev分支中（编辑sysinfo.txt文件模拟开发）
cat >>sysinfo.txt <<EOF
> 这是A设备新增的内容
> EOF

#1.3-将开发好的内容添加到仓库的暂存区与提交到仓库中
git add sysinfo.txt
git commit -m"append '这是A设备新增的内容' to sysinfo.txt"
git status

#1.4-将本地仓库内容的dev分支推送到远程仓库的dev分支（此时可能会报错"错误：无法推送一些引用到 'github.com:kafeiweimei/gitdemo.git';更新被拒绝，因为远程仓库包含您本地尚不存在的提交。这通常是因为另外一个仓库已向该引用进行了推送。如果您希望先与远程变更合并，请在推送前执行 'git pull'"）
git push origin dev

#1.5-拉取远程仓库的dev分支内容到本地的dev分支中
#注意1：若在拉取远程仓库到本地时最后提示"如果您想要为此分支创建跟踪信息，您可以执行：git branch --set-upstream-to=origin/<分支> dev"则需要按照提示配置一下，构建本地仓库分支与远程仓库的关联;
#注意2：设置完成本地仓库与远程仓库的关联后，再次拉取提示"您有偏离的分支，需要指定如何调和它们。您可以在执行下一次，pull 操作之前执行下面一条命令来抑制本消息：git config pull.rebase false  # 合并；git config pull.rebase true   # 变基；git config pull.ff only       # 仅快进；您可以将 "git config" 替换为 "git config --global" 以便为所有仓库设置；缺省的配置项。您也可以在每次执行 pull 命令时添加 --rebase、--no-rebase，或者 --ff-only 参数覆盖缺省设置【致命错误：需要指定如何调和偏离的分支】（执行设置全局通用合并【git config --global pull.rebase false】）"
git pull
git branch --set-upstream-to=origin/dev dev
git pull
git config --global pull.rebase false
git pull
git push origin dev

三、标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

3.1、创建标签

创建标签小结
命令【git tag <tagname>】用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令【git tag -a <tagname> -m "该标签的简要描述"】可以指定标签信息；
命令【git tag】可以查看所有标签。

#打标签

#1-切换到需要打标签的分支(一般是main或master)
git checkout master
git branch

#2-直接在当前分支上打标签
git tag v0.1
#查看所有标签命令
git tag


#默认标签是打在最新提交的commit上的。有时候，如果忘了打标签（如：本来应该在周一的分支上打标签的，但是忘记了，现在是周五了，如何处理？（或者是想在【指定提交ID】上打标签）
#解决方案是：【找到历史提交的commit id，然后打上就可以】
#1-先查寻到当前的所有提交日志
git log --pretty=oneline --abbrev-commit

#2-给指定的提交ID(commit id)打标签
git tag v0.0.6 c4f1539

#3-注意:标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
git tag
git show v0.0.6

#4-创建带有说明的标签，用-a指定标签名，-m指定说明
git tag -a v0.0.7 -m"稳定版本0.0.7，主要用于XXX场景" 2f27686
git show v0.0.7

3.2、操作标签

操作标签小结
命令【git push origin <tagname>】可以推送一个本地标签到远程仓库中；
命令【git push origin --tags】可以推送全部未推送过的本地标签到远程仓库中；
命令【git tag -d <tagname>】可以删除一个本地标签；
命令【git push origin :refs/tags/<tagname>】可以删除一个远程标签。

#操作标签
#1-若标签打错，则可删除
git tag
git tag -d v0.1

#2-推送指定标签到远程仓库【使用命令git push origin <tagname>】
#注意：因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
git push origin v0.0.6

#3-一次性推送全部尚未推送到远程的本地标签：
git push origin --tags

#4-删除远程仓库的指定标签（需要先删除本地仓库的标签，然后在删除远程仓库的标签）
git tag -d v0.0.6
git push origin :refs/tags/v0.0.6

四、git个性化设置

4.1、让git命令的输出更醒目

#Git会适当地显示不同的颜色配置
git config --global color.ui true

4.2、忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们（如：保存了数据库密码的配置文件），要忽略这些文件，可以在Git工作区的根目录下创建一个特殊的【.gitignore】文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件**【忽略某些文件时，需要编写.gitignore；.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！】。**

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则
《1》忽略操作系统自动生成的文件（如：缩略图等）；
《2》忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库（如：Java编译产生的.class文件）；
《3》忽略你自己的带有敏感信息的配置文件（如：存放口令的配置文件）。

#忽略特殊文件（如：忽略Python编译产生的.pyc、.pyo、dist等文件或目录）
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

最后一步就是把【.gitignore】也提交到Git，就完成了！

检验 .gitignore 是否生效的唯一标准：

运行 git status，如果输出 nothing to commit, working directory clean

= 你的 .gitignore 完全生效、配置正确！

#如果添加一个文件到Git，但发现添加不了，可能原因是这个文件被.gitignore忽略了，如果你确实想添加该文件，可以用-f强制添加到Git：
git add -f App.class

#如果要要检查是否是.gitignore文件限制了git提交，可以用git check-ignore命令检查：
#Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。
git check-ignore -v App.class

4.3、配置别名

#有没有经常敲错命令？比如git status？status这个单词真心不好记。
#如果敲【git st】就表示git status那就简单多了，我们只需要敲一行命令，告诉Git，以后st就表示status：
git config --global alias.st status

#还有别的命令可以简写，很多人都用【co】表示checkout，【ci】表示commit，【br】表示branch：
#【--global】参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch

注意1： 每个仓库的Git配置文件都放在【.git/config】文件中，上面配置的别名就在.git/config文件的[alias]段后面，要删除别名，直接把对应的行删掉即可。
**注意2：**当前用户的Git配置文件放在用户主目录下的一个隐藏文件【~/.gitconfig】中，配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。