甘德县公司网站建设,wordpress ajax form,网站如何屏蔽中国ip,网站建设四不问题一、Git命令
1.1 创建Git本地仓库 仓库是进行版本控制的一个文件目录。我们要想对文件进行版本控制#xff0c;就必须创建出一个仓库出来。创建一个Git本地仓库对应的命令是 git init #xff0c;注意命令要在文件目录下执行。
hrxlavm-1lzqn7w2w6:~/gitcode$ pwd
/home/hr…一、Git命令
1.1 创建Git本地仓库 仓库是进行版本控制的一个文件目录。我们要想对文件进行版本控制就必须创建出一个仓库出来。创建一个Git本地仓库对应的命令是 git init 注意命令要在文件目录下执行。
hrxlavm-1lzqn7w2w6:~/gitcode$ pwd
/home/hrx/gitcode
hrxlavm-1lzqn7w2w6:~/gitcode$ git init 我们会发现当前目录下多出了一个 .git 的隐藏文件.git 目录是Git来跟踪管理仓库的不要手动修改这个目录中的文件。
hrxlavm-1lzqn7w2w6:~/gitcode$ tree .git/
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── fsmonitor-watchman.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── pre-merge-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ ├── pre-receive.sample
│ ├── push-to-checkout.sample
│ └── update.sample
├── index
├── info
│ └── exclude
├── logs
│ ├── HEAD
│ └── refs
│ └── heads
│ └── master
├── objects
│ ├── 31
│ │ └── e5098c1fa351225c05f9286c124cab9d4beb8e
│ ├── 3b
│ │ └── 18e512dba79e4c8300dd08aeb37f8e728b8dad
│ ├── 75
│ │ └── eb93ca2dadfd16966679a9d5714118c77b6219
│ ├── c5
│ │ └── a5efacb403ff2606d106a60eeee5d0912aafc6
│ ├── e5
│ │ └── 1899e7b30c9f87ee4cf5ba320f9876acb928fd
│ ├── e6
│ │ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│ ├── info
│ └── pack
└── refs├── heads│ └── master└── tags
1.2 配置Git
当安装Git后首先要做的事情是设置你的用户名称和e-mail地址这是非常重要的。配置命令为
git config [--global] user.name Your Name
git config [--global] user.email emailexample.com # 把 Your Name 改成你的昵称
# 把 emailexample.com 改成邮箱的格式只要格式正确即可。
其中 --global 是一个可选项。如果使用了这个可选项表示这台机器上所有的Git仓库都会使用这个配置。如果你希望在不同的仓库中使用不同的 name 或者 e-mail可以不需要使用 --global选项但是要注意执行命令时必须要在仓库中。
查看配置命令为
git config -l 删除对应的配置命令为要注意如果使用可选项创建的配置删除也需要带上可选项
git config [--global] --unset user.name
git config [--global] --unset user.email
1.3 认识工作区暂存区版本库
工作区是在电脑上你要写代码或者文件的目录
暂存区英文叫做 stage 或者 index。一般存放在 .git 目录下的 index 文件.git/index中我们把暂存区有时叫做索引index。注意在刚开始创建一个仓库时是没有这个目录的只有在我们添加了一个文件后在仓库中才会有这个目录。
版本库又名仓库英文名叫做repository。工作区有一个隐藏目录 .git他不算工作区而是Git的版本库。这个版本库里面的所有文件都可以被Git管理起来每一个文件的修改、删除Git都能跟踪以便在任何时候都可以追踪历史或者在将来的某一恶搞时刻可以“还原”。
下面这张图展示了工作区、暂存区和版本库之间的关系
图中左侧为工作区右侧为版本库。Git的版本库里存放了很多东西其中最重要的就是暂存区。
在创建Git版本库时Git会为我们自动创建一个唯一的master分支以及指向master的一个指针叫做 HEAD。
当对工作区修改或者新增的文件执行 git add 命令时暂存区目录树的文件索引会被更新。
当执行提交操作 git commit 时master分支会做相应的更新可以简单理解为暂存区的目录树才会被真正写入到版本库中。
由上述描述我们便能得知通过新建或者粘贴进目录的文件并不能称之为向仓库中新增文件而只是在工作区新增了文件。必须要通过使用 git add 和 git commit 命令才能将文件添加到仓库中进行管理。
1.4 添加文件 —— 场景一
在包含 .git 的目录下新建一个ReadMe文件我们可以使用 git add 命令可以将文件添加到暂存区
添加一个或者多个文件到暂存区中git add [file1] [file2] ...
添加指定目录到暂存区中包括子目录git add [dir]
添加当前目录下的所有文件改动到暂存区git add .
再使用 git commit 命令将暂存区内容添加到本地仓库中
提交暂存区中全部内容到本地仓库中git commit -m message
提交暂存区的指定文件到仓库区git commit [file1] [file2] ... -m messsage 注意 git commit 后面的 -m选项要跟上描述本次提交的message由用户自己完成这部分内容绝对不能省略并要好好描述。是用来记录你的提交细节是给我们程序员看的。 当我们将已经写好的代码直接提交给本地仓库后我们可以使用 git log 命令爱查看历史提交记录。该命令显示的是从最近到最远的体检日志并且可以看到我们 commit 时的日志消息。如果觉得输出信息太多我们可以加上 --prettyoneline 参数。
显示提交日志的命令git log --prettyoneline 需要说明的是我们看到的一大串类似于 23807c5.....56eed6 的是每一次提交的 commit id版本号Git的 commit ID不是 1,2,3……递增的数字而是一恶搞SHAI计算出来的一个非常大的数字用十六进制表示你看到的 commit id 和我的肯定不一样以你自己的为主。
1.5 查看 .git 文件
先来看一看我们的 .git 的目录结构
hrxlavm-1lzqn7w2w6:~/gitcode$ tree .git/
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── fsmonitor-watchman.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── pre-merge-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ ├── pre-receive.sample
│ ├── push-to-checkout.sample
│ └── update.sample
├── index
├── info
│ └── exclude
├── logs
│ ├── HEAD
│ └── refs
│ └── heads
│ └── master
├── objects
│ ├── 31
│ │ └── e5098c1fa351225c05f9286c124cab9d4beb8e
│ ├── 3b
│ │ └── 18e512dba79e4c8300dd08aeb37f8e728b8dad
│ ├── 75
│ │ └── eb93ca2dadfd16966679a9d5714118c77b6219
│ ├── c5
│ │ └── a5efacb403ff2606d106a60eeee5d0912aafc6
│ ├── e5
│ │ └── 1899e7b30c9f87ee4cf5ba320f9876acb928fd
│ ├── e6
│ │ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│ ├── info
│ └── pack
└── refs├── heads│ └── master└── tags
index 就是我们的暂存区add后的内容都是添加到这里的
HEAD 就是我们的默认指向 master 分支的指针
cat .git/HEAD
ref: refs/heads/master
然而默认的 master 分支其实就是
cat .git/refs/heads/master
23807c536969cd886c4fb624b997ca575756eed6
object 作为Git的对象库里面包含了创建的各种版本库对象以及内容。当执行 git add 命令时暂存区的目录树被更新同时工作区修改或者新增的文件内容被写入到对象库中的一个新的对象中就位于“.git/objects”目录下让我们来看一看这些对象是什么
ls .git/objects/
23 83 8f 9c c6 e6 info pack
查找object时要将commit id 分为2部分其前2位是文件夹名称后38位是文件名称。当我们找到这个文件之后一般不能直接看到里面是什么该类文件是经过sha安全哈希算法加密过的文件好在我们可以使用 git cat-file 命令来查看版本库对象的内容
git cat-file -p 23807c536969cd886c4fb624b997ca575756eed6(commit id) 总结一下在本地的git仓库中有几个文件或者目录很特殊 index暂存区git add 后会更新该内容HEAD默认指向master分支的一个指针refs/heads/master文件里面保存当前 master 分支的最新的 commit idobject包含了创建的各种版本库对象以及内容可以简单理解为放了 git 维护的所有修改 1.6 添加文件 —— 场景二
当我们创建了多个文件的时候我们也需要使用add命令将所有创建的文件添加进暂存区中这样我们使用git commit 命令的时候会将暂存区中内容添加到本地仓库中。
1.7 修改文件 Git 比其他版本控制系统设计的优秀是因为Git跟踪管理的是修改而并不是文件。什么是修改呢比如你新增了一行这就是修改删除了一行也是一个修改更改了某些字符也是一个修改甚至创建一个文件也是一个修改。 当我们修改了ReadMe文件后此时在仓库中的ReadMe文件和工作区中的ReadMe文件是不同的如何查看当前仓库的状态呢我们可以使用 git status 命令开来查看在上次提交之后是否有对文件进行再次修改。
git statusOn branch master
Changes not staged for commit:(use git add file... to update what will be committed)(use git restore file... to discard changes in working directory)modified: ReadMe
no changes added to commit (use git add and/or git commit -a)
我们可以使用 git diff [file] 命令用来显示暂存区和工作区文件的差异显示的格式正是Unix通用的diff格式也可以使用 git diff HEAD -- [file] 命令来查看版本库和工作区文件的区别。
git diff [file]
git diff HEAD -- [file]
1.8 版本回退
之前我们也提到过Git能够管理文件的历史版本这也是版本控制器重要的能力。如果有一天你发现之前的工作出现了很大的问题需要在某一个特定的历史版本重新开始这个时候就需要版本回退的功能了。
执行 git reset 命令用于回退版本可以指定退回某一次提交的版本。需要解释一下“回退”的本质是要将版本库中的内容进行回退工作区或者暂存区是否回退由命令参数决定
git reset 命令语法格式为git reset [--soft | --mixed | --hard] [HEAD]
--mixed为默认选项使用时可以不用带该参数。该参数将暂存区的内容退回为执行提交版本内容工作区文件保持不变。
--soft参数对于工作区和暂存区的内容都不变只是将版本库回退到某一个指定的版本。
--hard参数将暂存区和工作区都退回到指定版本。切记工作区有未提交的代码时不要使用这个命令因为工作区会回滚你没有提交的代码就再也找不回了所以使用该参数前一定要慎重。 HEAD说明
可以直接写成commit id表示指定退回的版本
HEAD表示当前版本
HEAD^表示上一个版本
HEAD^^表示上上一个版本
以此类推
也可以使用 ~ 数字 表示
HEAD~0 表示当前版本
HEAD~1 表示上一个版本
HEAD~2 表示上上一个版本
以此类推
如果我们在回退版本之后我们反悔了想要拿到最开始的版本需要怎么办我们可以继续使用 git reset 命令回退到最开始的版本但是我们必须要拿到最开始版本的commit id 去指定回退的版本。
但是我们看到了 git log 并不能打印出最开始版本的 commit id运气好的话我们可以从终端上去找找之前的记录运气不好的话 commit id已经被我们弄丢了。
Git还提供了一个 git reflog 命令能补救一下该命令用来记录本地的每一次命令。
git reflog14c12c3 (HEAD - master) HEAD{0}: reset: moving to
14c12c32464d6ead7159f5c24e786ce450c899dd
d95c13f HEAD{1}: commit: add version3
14c12c3 (HEAD - master) HEAD{2}: commit: add version2
cff9d1e HEAD{3}: commit: add version1
94da695 HEAD{4}: commit: add modify ReadMe file
23807c5 HEAD{5}: commit: add 3 files
c614289 HEAD{6}: commit (initial): commit my first file 这样你就可以很方便地找到你的所有操作记录了但是 d95c13f 这个是什么东西这个是最开始版本的 commit id 的部分。没错Git版本回退的时候也可以使用部分 commit id 来代表目标版本。 值得说的是Git的版本回退速度非常快因为Git在内部有一个指向当前分支此处是master的HEAD指针refs/heads/master 文件里保存当前 master 分支的最新 commit id。当我们在回退版本的时候Git仅仅是给 refs/heads/master 中存储了一个特定的版本如下图所示 1.9 撤销修改
1.9.1 情况一对于工作区的代码还没有进行add
我们有两种方法去执行撤销修改第一种方法是直接删除当前工作区新增的代码但是如果我们写的代码很长怎么办第二种方法是Git为我们提供了更好的方法我们可以使用 git checkout -- [file] 命令让工作区的文件回到最近一次 add 或者 commit 时的状态。需要注意 git checkout -- [file]命令中的 -- 很重要切记不要省略一旦省略该命令就变为其他意思了。
git checkout -- [file]
1.9.2 情况二对于已经add的代码还没有进行commit
如果我们使用add命令后将代码保存到暂存区后我们应该怎么撤销呢 第一种方法让我们来回忆一下学过的 git reset 回退命令该命令如果使用 --mixed 参数可以将暂存区的内容退回为指定的版本内容但是工作区的文件保持不变那么我们就可以回退暂存区中的内容了
# --mixed 是默认参数使⽤时可以省略
hyb139-159-150-152:~/gitcode$ git reset HEAD ReadMe
Unstaged changes after reset:
M ReadMegit checkout -- [file] 第二种方法我们可以直接使用 --hard 参数直接进行全部回退。
1.9.3 已经add的代码并且也commit了
不要担心我们可以 git reset --hard HEAD^ 回退到上一个版本不过这是有条件的就是你还没有把自己的本地版本库推送到远程。一旦我们推送到远程就废了。
1.10 删除文件
在Git中删除也是一个修改操作我们实战一下如果要删除 file5 文件怎么办
~/gitcode$ ls
file1 file2 file3 file4 file5 ReadMe
~/gitcode$ rm file5如果我们直接删除是没有用的git status 命令会立刻告诉你哪些文件被删除了 此时工作区和版本库就不一致了要删除文件目前除了要删工作区的文件还要清除版本库的文件。 一般到这里有两种可能 确实要从版本库中删除该文件不小心删错了 对于第二种情况很明显误删了需要使用 Git 进行恢复删除也是修改
git checkout -- file5
对于第一种情况很明显是没有删完我们只删除了工作区的文件。这个时候就需要使用 git rm 将文件从暂存区和工作区中删除并且 commit
git rm file5
git commit -mdeleted file5
二、分支管理
2.1 理解分支
在版本回退里每一次提交Git都把他们串成一条时间线这条时间线就可以理解为是一个分支。截止到目前只有一条时间线在Git中这个分支叫做主分支即master分支。
再来理解一下HEADHEAD严格来说不是指向提交而是指向mastermaster才是指向提交的所以HEAD指向的就是当前分支。
每一次提交 master分支都会向前移动一步这样随着你的不断提交master分支的线也越来越长而HEAD只要一直指向master分支即可。
2.2 创建分支
Git支持我们查看或者创建其他分支我们来创建第一个自己的分支对应的命令为
git branch #查看当前本地所有分支git branch dev #新建分支dev
当我们创建新的分支后Git新建了一个指针叫做dev*表示当前HEAD指向的分支是master分支。
我们可以使用一张图来总结 2.3 切换分支
那么如何切换分支呢使用 git checkout 命令即可完成切换命令如下
git checkout dev
我们可以进行在dev分支上进行修改文件当我们将修改的文件进行add和commit操作后我们来切换到master分支发现在master分支下我们没有看见我们新修改的文件但是在dev分支下新修改的文件还在我们来看一看dev分支和master分支的指向发现两者指向的提交不一样。
这里就明白了因为我们是在dev分支上提交的但是master分支此刻的提交点并没有改变此时的状态图如下所示 当切换到master分支时HEAD就指向了master当然看不到提交了。
2.4 合并分支
为了在master主分支上看到新的提交就需要将dev分支合并到master分支命令如下
git branchgit checkout master # 切换到 master 上进行合并git merge dev # 合并 dev 分支 git merge 命令用于合并指定分支到当前分支。合并后master就能看到dev分支提交的内容了。此时的状态如下图所示 Fast-forward 代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度非常快。当然也不是每次合并都能 Fast-forward。
2.5 删除分支
合并完成后dev分支对于我们来说就没有用了那么dev分支就可以被删除掉注意如果当前正处于某一个分支下就不能删除当前分支命令如下
~/gitcode$ git branch
* devmaster
hyb139-159-150-152:~/gitcode$ git branch -d dev
error: Cannot delete branch dev checked out at /home/hrx/gitcode
但是可以在其他分支下删除当前分支命令如下
:~/gitcode$ git checkout master
Switched to branch master
:~/gitcode$ git branch -d dev
Deleted branch dev (was bdaf528).
:~/gitcode$ git branch
* master
此时的状态图如下图所示 因为创建、合并和删除分支非常快所以Git鼓励你使用分支完成某一个任务合并后再删除分支这和直接在master分支上工作的效果是一样的但是过程更加安全。
2.6 合并冲突
但是在实际分支合并的时候并不是想合并就能合并成功的有时候可能会遇到代码冲突的问题。为了演示这个问题创建一个新的分支dev1并切换到目标文件我们可以使用 git chechout -b dev1 一步完成创建并切换的动作命令如下
git chechout -b dev1
当我们在master和dev1下都进行修改文件两个分支都分别有自己的提交状态就会如下图所示 在这种情况下Git只能试图把各自的修改合并起来但是这种合并就可能会有冲突发现有文件有冲突后可以直接查看文件内容要注意的是Git会用 来标识出不同分支的冲突内容 此时我们必须要手动调整冲突代码并需要再次提交修正后的结果一定要再次提交
到这里冲突就解决完成了此时的状态就变成了 用带参数的 git log 也可以看到分支的合并情况命令如下所示
git log --graph --prettyoneline --abbrev-commit
2.7 分支管理策略
通常合并分支时如果可能Git会采用Fast forward 模式。在这种模式下删除分支后查看分支历史时会丢掉分支信息。看不出最新提交的到底是merge进来的还是正常提交的。
但是在合并冲突部分我们也可以看到通过解决冲突文件会再进行一次新的提交得到的最终状态为下图所示 那么这就不是Fast forward模式了这样的好处是从分支历史上就可以看出分支信息。
Git支持我们强制禁用Fast forward模式那么就会在merge时生成一个新的commit这样从分支历史上就可以看出分支信息。
请注意 --no-ff 参数表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的commit所以加上 -m 参数把描述写进去。
git merge --no-ff -m message dev2;
可以看到不使用 Fast forward 模式merge后就会像这样一样 所以在合并分支时加上 --no-ff 参数就可以使用普通模式合并了合并的历史有分支能看出来曾经做过合并而 Fast forward 合并看不出来曾经做过合并。
2.8 分支策略
在实际开发中我们应该按照几个基本原则进行分支管理
首先master分支应该是非常稳定的也就是仅仅用来发布新版本的平时不能在上面进行开发。我们做的开发任务基本都在dev分支中也就是说dev分支是不稳定的等到开发完成之后我们再将dev合并到master中。
2.9 bug分支
假如我们正在进行dev2分支上的开发开发到一半突然发现master分支上面有bug需要解决。在Git中每一个bu都可以通过一个新的临时分支来修复修复后合并分支然后将临时分支进行删除。
Git提供了git stash命令可以将当前的工作区信息进行隐藏被存储的内容可以在将来某一个时刻恢复出来。
git stash
这样使用git status查看工作区就是干净的除非没有被Git管理的文件因此我们可以放心创建分支来进行修复bug。
我们可以使用 git stash list命令来查看刚才保存的工作现场保存到哪里了
git stash list
工作现场还在Git把stash内容存在某一个地方了但是需要恢复一下如何恢复现场呢我们可以使用git stash pop 命令恢复的同时会把stash也进行删除。
git stash pop
另外恢复现场也可以采用 git stash apply 恢复但是恢复后stash 内容并不删除你需要使用 git stash drop 来删除。
但是我们注意到了修复bug的内容并没有在dev2上显示此时的状态图为 我们不能在master分支上进行合并我们需要在dev2的分支上进行合并因为在合并代码的过程中会有风险和冲突的出现这些风险和冲突需要我们手动进行解决但是在解决的过程中我们也会有风险和冲突的出现因此我们不能直接在master分支中进行合并代码我们需要在dev分支上进行合并代码最后检测没有问题后我们再将代码合并到master分支上。 2.10 删除临时分支
在软件开发中一直会有很多的新的功能要不断被添加进去在添加一个新的功能时我们肯定不希望因为一些实验性质的代码将主分支搞乱了所以我们每添加一个新功能时最好可以创建一个新的分支我们称之为feature分支开发在上面开发完成后合并最后删除该feature分支。
可是如果我们今天正在某一个feature分支上开发了一半被产品经理突然叫停要停止新的开发所以这个feature分支必须要被销毁这个时候使用传统的 git branch -d 命令删除分支的方法是不正确的我们需要使用新的删除分支的方法
git branch -D dev
总结一下
分支在实际上有什么作用呢我们可以将一个大的项目分割成多个小的功能模块每一个功能模块都可以分给不同的人进行开发最后当我们开发完毕之后我们再一次进行合并到主分支中这样即安全又不影响别人工作。并且 Git无论创建、切换和删除分支Git都能在1秒之内就可以完成。
三、远程操作
3.1 理解分布式版本控制系统
我们目前所说的所有内容工作区暂存区版本库等等都是在本地上也就是说在你的计算机中。但是现在的Git是分布式版本控制系统我们需要来进行理解一下
我们每一个人的电脑上都是一个完整的版本库这样你工作的时候就不需要联网了因为版本库就在你自己的电脑中。既然每一个人的电脑上都有一个完整的版本库那么多人是如何进行协作的呢比如说你在你自己的电脑中修改了文件A你的同事在他的电脑中也修改了文件A这时你们之间只需要将各自的修改推送到对方就可以互相看到对方的修改了。
分布式版本控制系统的安全性要高的多因为每一个人的电脑里都有一个完整的版本库某一个版本库丢失都不要紧随便从其他人那里复制一份即可。
在实际使用分布式版本控制系统的时候通常充当一个中央服务器的电脑但是这个服务器的作用仅仅是用来方便交换大家的修改没有它大家也一样干活只是交换修改不方便而已。
3.2 克隆远程仓库
克隆、下载远端仓库到本地需要使用 git clone 命令后面跟上我们的远端仓库的链接远端仓库的链接可以从仓库中找到。
在克隆远程仓库的时候我们可以选择两种协议SSH协议和HTTPS协议SSH协议使用了公钥加密和公钥登录机制体现了其实用性和安全性使用此协议需要将我们的公钥放上服务器有Git服务器进行管理。使用HTTPS方式时没有要求可以直接克隆下来。
3.3 向远程仓库推送
本地已经 clone 成功远程仓库后我们便可以向仓库中提交内容先创建出一个文件 提交时要注意如果我们之前设置过全局的name和e-mail这两项配置需要和gitee上配置的用户名和邮箱一致否则就会出错。或者从来没有设置过全局的name和e-mail那么我们第一次提交时也会进行报错。这就需要我们重新配置。
到这里我们已经将内容提交到本地仓库中如何将本地仓库的内容推送到远程仓库呢需要使用 git push 命令。该命令用于将本地的分支版本上传到远程进行合并命令格式如下所示
git push 远程主机名 本地分⽀名:远程分⽀名# 如果本地分⽀名与远程分⽀名相同则可以省略冒号
git push 远程主机名 本地分⽀名
如果现在远程仓库的版本要领先于本地仓库的版本时为了使本地仓库保持最新的版本我们需要拉取一下远端代码并合并到本地。Git提供了git pull 命令该命令用于从远端获取代码并合并本地的版本。命令格式如下
git pull 远程主机名 远程分⽀名:本地分⽀名# 如果远程分⽀是与当前分⽀合并则冒号后⾯的部分可以省略。
git pull 远程主机名 远程分⽀名
3.4 配置Git
3.4.1 忽略特殊文件
在日常开发中我们有一些文件不想或者不应该提交到本地比如保存了数据库密码的配置文件那么git应该怎么知道呢在GIt工作区的根目录下创建一个特殊的 .gitignore 文件然后把要忽略的文件名填进去Git就会自动忽略这些文件。
我们可以在创建仓库的时候勾选添加 .gitignore 文件那么如果当时在创建仓库的时候没有勾选这个选项我们可以在工作区创建一个也是可以的。
我们如果想要忽略以 .so 或者 .inii 结尾的所有文件.gitignore 文件的内容如下
# 省略选择模本的内容
...
# My configurations:
*.ini
*.so
我们也可以不排除指定文件可以在 .gitignore 文件中添加一条例外规则
# 排除所有 . 开头的隐藏文件
.*# 不排除.gitignore文件
.gitignore
3.4.2 给命令配置别名
在我们使用git的期间有一些命令的长度实在有点长我们可以使用一个命令来进行简化
举一个例子将git status 简化为 git st对应的命令为
git config --global alias.st status
--global 参数是全局参数也就是这些命令在这台电脑的所有Git仓库下都可以使用。如果不加这个参数那么只针对当前的仓库有作用。
四、标签管理
4.1 理解标签
标签 tag可以简单地理解为是对某次 commit 的一个标识相当于起了一个别名。例如在项目发布某一个版本的时候针对最后一次 commit 起了一个 v1.0 这样的标签来标识里程碑的意义。
那么标签有什么用呢相对于难以记住的 commit idtag 很好地解决了这个问题因为 tag 标签一定要给一个让人记住的且有意义的名字。当我们需要回退到某一个重要的版本时直接使用标签就能很快地定位。
4.2 创建标签
在 Git 中打标签非常简单首先切换到需要打标签的分支上
git branch* master
然后敲命令 git tag [name] 就可以打上一个新标签
git tag v1.0 // 注意这样是在最新的版本打上标签
可以使用命令 git tag 查看所有标签
git tagv1.0
默认标签是打在最新提交的 commit 上的。那么如何在指定的 commit 上打标签呢方法是找到历史提交的 commit id然后打上就可以了命令如下
git log --prettyoneline --abbrev-commit // 查看历史记录97811ab (HEAD - master, tag: v1.0, origin/master, origin/HEAD) add .gitignore60e6b0a update README.md.7ce3183 create file.txtc6ce3f0 Initial commit// 对于Initial commit 这次提交打上标签
git tag v0.9 c6ce3f0
git tagv0.9v1.0
注意标签并不是按时间顺序列出的而是按字母排序的。
我们可以使用 git show [tagname] 查看标签信息
git show v1.0commit 97811abd1d43774aeb54fee32bf4fc76b2b08170 (HEAD - master, tag: v1.0,
origin/master, origin/HEAD)
Author: hyb91 2689241679qq.com
Date: Fri May 12 17:27:06 2023 0800add .gitignore
diff --git a/.gitignore b/.gitignore
...
git还提供了可以创建带有说明的标签用 -a 指定标签名 -m 指定说明文字格式为
git tag -a [name] -m xxx [commit_id]
另外打完标签之后我们可以使用 tree .git 命令来查看一下本地仓库有什么变化
tree .git
4.3 操作标签
如果标签打错了也可以删除
git tag -d v0.9Deleted tag v0.9 (was c6ce3f0)
因为创建的标签都只从存储在本地。所以打错的标签可以在本地安全删除。
如果要推送到某一个标签到远程使用命令 git push origin tagname命令如下所示
git push origin v1.0Total 0 (delta 0), reused 0 (delta 0)
remote: Powered by GITEE.COM [GNK-6.4]
To gitee.com:hyb91/git_teaching.git* [new tag] v1.0 - v1.0
当然如果本地有很多标签也可以一次性的全部推送到远端
git push origin --tags
如果标签已经推送到远程要删除远程标签就会麻烦一些先从本地删除
git tag -d v1.0
然后从远程删除。删除命令也是 push。但是格式如下
git push origin :refs/tags/v1.0remote: Powered by GITEE.COM [GNK-6.4]
To gitee.com:hyb91/git_teaching.git- [deleted] v1.0
五、Git实战场景 —— 多人协作
5.1 多人协作一
5.2 多人协作二
5.3 远端分支删除后本地 git branch -a 依然能看到的解决方法
当前我们已经删除了远程的几个分支使用 git branch -a 命令可以查看所有本地分支和远程分支但是发现很多在远程仓库中已经删除的分支在本地依然可以看到。
我们可以使用 git remote show origin 命令来查看remote地址远程分支还有本地分支与之对应的关系信息。
git remote show origin
我们可以使用 git remote prune origin 命令来删除那些在远程仓库中不存在的分支。
git remote prune origin
六、企业级开发模型
6.1 讲一个故事
6.2 系统开发环境
对于开发人员来说在系统开发过程中最常用的几个环境必须要了解一下
开发环境开发环境是程序员专门用于日常开发的服务器。为了开发调试方便一般打开全部错误报告和测试工具是最基本的环境。测试环境一个程序在测试环境工作不正常那么肯定不能将其发布在生产机中。该环境是开发环境到生产环境的过渡环境。预发布环境该环境是为了避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。 其配置等基本和⽣产环境⼀致⽬的是能让我们发正式环境时更有把握所以预发布环境是你的产 品质量最后⼀道防线因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内为单独的⼀些机器。⽣产环境是指正式提供对外服务的线上环境例如我们⽬前在移动端或PC端能访问到的APP都生产环境。
6.3 Git分支设计规范
环境有了概念之后那么对于开发人员来说一般会针对不同的环境来设计分支如下图所示 6.3.1 master分支
master作为主分支该分支为只读且唯一的分支。用于部署到正式发布环境一般由合并release分支得到的。
主分支作为稳定的唯一的代码库任何情况下不允许直接在master分支上修改代码。
产品的功能全部实现后最终在master分支对外发布另外所在master分支的推送应该打标签tag做记录方便追溯。
master分支不可删除。
6.3.2 release分支
release为预发布分支基于本次上线所有的feature分支合并到develop分支上基于develop分支创建可以部署到测试或者预发布集群。
命令以release/开头建议的命令规则为 release/version_publishtime。
release分支主要用于提交给测试人员进行功能测试发布提测阶段会以release分支代码为基准进行提测。
如果在release分支测试出现问题需要回归验证develop分支看是否存在此问题。
release分支属于临时分支产品上线后可以选择删除。
6.3.3 develop分支
develop分支为开发分支基于master分支创建的只读且唯一的分支始终保持最新完成以及bug修复后的代码可以部署到开发环境对应集群中。
可以根据需求大小程度确定是由feature分支合并还是直接在上面进行开发非常不建议。
6.3.4 feature分支
feature分支通常为新功能或者新特性开发分支以develop分支为基础创建feature分支
命令以feature/开头建议的命名规则为feature/useruser_createtime_feature
新特性或者新功能开发完成后开发人员需要合并到develop分支中
一旦该需求发布上线需要将其删除
6.3.5 hotfix分支
hotfix分支为先线上bug修复分支或者叫做补丁分支主要用于对线上的版本进行bug修复。当线上出现紧急问题需要马上修复时需要基于master分支创建hotfix分支
命令以hotfix/开头建议的命令规则为hotfix/user_createtime_hotfix
当问题修复完成后需要合并到master分支和develop分支并推动到远程。一旦上线需要将其删除。
