Git workflow

最新推荐文章于 2023-05-17 09:08:59 发布
最新推荐文章于 2023-05-17 09:08:59 发布
阅读量188 收藏
点赞数
文章标签： git 运维 操作系统
原文链接：https://yq.aliyun.com/articles/324975
版权

Git workflow

大神镇楼：

这里写图片描述

这人不用说，应该都认识，他基本干了两件事，一个是Linux，一个就是git。每一件事，都在IT史上创建了一个巨大的Tag。

Git是什么

Git能干什么？

Git用来做版本控制，这就好比当初在小日本的公司，每次修改文件，都需要在文件第一页新增修改履历，详细记录修改内容，如果多人同时操作，你可以想象下维护的成本有多高。基本每天就在整理这些破事。

所以说，版本控制是项目开发的重中之重。那么问题来了，版本控制哪家强？一句话，Git是目前世界上最先进的分布式版本控制系统（没有之一）。其实也可以把分布式三个字去掉。

集中式版本控制

集中式的版本控制工具以SVN为代表，他有一个中央服务器，控制着所有的版本管理，其它所有的终端，可以对这个中央库进行操作，中央库保证版本的唯一性。

这里写图片描述

这样有一个非常不好的地方，就是如果中央服务器被天灾军团攻陷了，那么整个版本就gg了。因为终端只能对一部分代码进行修改，获取各种信息，需要不断与中央服务器通信。

  1. 容灾性差
  2. 通信频繁

分布式版本控制

分布式版本控制的典型，就是Git，它跟集中式的最大区别就是它的终端可以获取到中央服务器的完整信息，就好像做了一个完整的镜像，这样，我可以在终端做各种操作、获取各种信息而不需要与服务器通信，同时，就算服务器被炸，各个终端还有完整的备份。分布式的思路，在版本控制上，具有得天独厚的优势，当然，这只是git优势的冰山一角。

Git安装与配置

安装

Git的安装就不解释了，相信程序猿都有能力独立解决这样一个问题，Linux和Mac下基本都已经自带Git了，window，建议不要用Git了，命令行实在是受不了。

配置

在终端输入：

  ~  git --version
git version 1.8.4

来查看当前Git的版本，同时，输入：

  ~  git config --list --global
user.name=xuyisheng
user.email=xuyisheng@hujiang.com
push.default=current

或者：

  ~  git config user.name
xuyisheng

用来查看当前的配置信息，如果是新安装的，那么需要对global信息进行配置。配置的方法有两种，一个个变量配置，或者一起配置：

单独配置：

  ~  git config --global user.name xys

一起配置：

  ~  git config --global --add user.name xys

增加多个键值对

删除配置

  ~  git config --global --unset user.name xys

配置别名

这个功能在shell中是很常用的。我们可以做一些别名来取代比较复杂的指令。
比如：

git config --global alias.st status

我们使用st来取代status。

附上一个比较吊的：

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

PS:用git log –graph命令可以看到分支合并图。

配置文件

git的配置文件其实我们是可以找到的，就在.git目录下：

  testGit git:(master) ls -a
.          ..         .git       README.txt
  testGit git:(master) cd .git
  .git git:(master) ls
HEAD        description index       logs        packed-refs
config      hooks       info        objects     refs
  .git git:(master)

我们打开config文件：

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = false
[remote "origin"]
    url = git@github.com:xuyisheng/testGit.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "dev"]
    remote = origin
    merge = refs/heads/dev

这里就是我们所有的配置了。

创建Git仓库

版本控制就是为了管理代码，代码就要放在仓库中。创建仓库有二种方法：

Git init

  MyWork  mkdir gitTest
  MyWork  cd gitTest
  gitTest  git init
Initialized empty Git repository in /Users/hj/Downloads/MyWork/gitTest/.git/
  gitTest git:(master)

创建一个目录，并cd到目录下，通过调用git init来将现有目录初始化为git仓库，或者直接在git init后面跟上目录名，同样也可以创建一个新的仓库。

git clone

git clone用于clone一个远程仓库到本地，这个我们后面再将。

创建好仓库后，目录下会生成一个.git的隐藏文件夹，这里就是所有的版本记录，默认不要对这个文件夹进行修改。

提交修改

add && commit

在仓库中，我们创建代码，并将其提交：

  gitTest git:(master) touch README.txt
  gitTest git:(master)  open README.txt
  gitTest git:(master)  git add README.txt
  gitTest git:(master)  git commit -m "add readme"
[master (root-commit) c19081b] add readme
 1 file changed, 1 insertion(+)
 create mode 100644 README.txt

我们创建了一个README文件，并通过git add <文件名>的方式进行add操作，最后通过git commit操作进行提交，-m参数，指定了提交的说明。

这两个命令应该是最常使用的git命令。

查看修改

在版本控制中，非常核心的一点，就是需要指定，我们做了哪些修改，比如之前我们创建了一个README文件，并在里面写了一句话：
this is readme。

下面我们修改这个文件：
this is readme，modify。

接下来，我们使用git status命令来查看当前git仓库哪些内容被修改了：

  gitTest git:(master) git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   README.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

我们可以发现，git提示我们：
modified: README.txt，更进一步，我们可以使用git diff命令来查看具体的修改：

diff --git a/README.txt b/README.txt
index 2744f40..f312f1a 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-this is readme
\ No newline at end of file
+this is readme, modify
\ No newline at end of file
(END)

这样就查看了具体的修改。

下面我们继续add、commit：

  gitTest git:(master)  git add README.txt
  gitTest git:(master)  git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   README.txt
#
  gitTest git:(master)  git commit -m "modify readme"
[master 1629cdc] modify readme
 1 file changed, 1 insertion(+), 1 deletion(-)
  gitTest git:(master) git status
# On branch master
nothing to commit, working directory clean

add和commit之后，我们都使用status来查看下状态，可以发现，在commit之后，git提示我们，工作区是干净的。

版本记录

在项目中，一个仓库通常可能有非常多次的add、commit过程，这些记录都会被记录下来，我们可以使用git log来查看这些记录：

commit 1629cdcf2307bf26c0c5467e10035c2bd751e9d0
Author: xuyisheng <xuyisheng@hujiang.com>
Date:   Sun Jun 28 14:45:14 2015 +0800

    modify readme

commit c19081b6a48bcd6fb243560dafc7a35ae5e74765
Author: xuyisheng <xuyisheng@hujiang.com>
Date:   Sun Jun 28 14:35:00 2015 +0800

    add readme
(END)

每条记录都对应一个commit id，这是一个40个16进制的sha-1 hash code。用来唯一标识一个commit。

同时，我们也可以使用gitk命令来查看图形化的log记录：

这里写图片描述

git会自动将commit串成一个时间线。每个点，就代表一个commit。点击这些点，就可以看见相应的修改信息。

工作区与暂存区

Git通常是工作在三个区域上：

  1. 工作区
  2. 暂存区
  3. 历史区

其中工作区就是我们平时工作、修改代码的区域，而历史区，用来保存各个版本，而暂存区，则是Git的核心所在。

暂存区保存在我们前面讲的那个.git的隐藏文件夹中，是一个叫index的文件。

这里写图片描述

当我们向Git仓库提交代码的时候。add操作实际上是将修改记录到暂存区，我们来看gitk：

这里写图片描述

可以发现，我们在本地已经生成了一个记录，但是还没有commit，所以当前HEAD并没有指向我们的修改，修改还保存在暂存区。

当我们commit之后，再看gitk：

这里写图片描述

这时候，HEAD就已经移到了我们的修改上，也就是说，我们的提交生成了一个新的commit。git commit操作就是将暂存区的内容全部提交。如果内容不add到暂存区，那么commit就不会提交修改内容。

PS 这里需要说明一个概念，git管理的是修改，而不是文件，每个sha-1的值，也是根据内容计算出来的。

版本回退

如果这个世界一直只需要git add、commit，就不会有这么多的问题了，但是，愿望是美好的，现实是残酷的。如何处理版本的回退和修改，是使用git非常重要的一步。

checkout && reset

我们来考虑几种情况：

  1. 文件已经修改，但是还没有git add
  2. 文件已经add到暂存区，又作了修改
  3. 文件的修改已经add到了暂存区

分别执行以下操作：

  gitTest git:(master)  git checkout -- README.txt
  1. 修改被删除，完全还原到上次commit的状态，也就是服务器版本
  2. 最后的修改被删除，还原到上次add的状态，也就是修改前的暂存区状态

总的来说，就是还原到上次add、commit的状态。

而对于第三种情况，我们可以使用git reset：

  gitTest git:(master)  git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   README.txt
#
  gitTest git:(master)  git reset HEAD README.txt
Unstaged changes after reset:
M   README.txt
  gitTest git:(master)  git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   README.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

通过git reset HEAD README.txt，我们就把暂存区的文件清除了，这样，在本地就是add前的状态，通过checkout操作，就可以进行修改回退了。

PS : git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除

回退版本

当我们的仓库有了大量的提交的时候，我们可以通过git log来查看（可以指定 –pretty=oneline 来优化显示效果）。

e7ae095cafc8ddc5fda5a5d8b23d0bcaaf74ac39 modify again
5427c66703abfeaba3706f938317251ef2567e8b delete test.txt
08098a21a918cfbd6377fc7a03a08cac0e6bcef6 add new file
b687b06fbb66da68bf8e0616c8049f194f03a062 e
8038c502e6f5cbf34c8096eb27feec682b75410b update
34ad1c36b97f090fdf3191f51e149b404c86e72f modify again
1629cdcf2307bf26c0c5467e10035c2bd751e9d0 modify readme
c19081b6a48bcd6fb243560dafc7a35ae5e74765 add readme

那么我们如果回退到指定版本呢？在Git中，用HEAD表示当前版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本就不要这样写了，写成HEAD~100即可。

下面我们就可以回退了：

  testGit git:(master) git reset --hard HEAD^
HEAD is now at 5427c66 delete test.txt

要回退到哪个版本，只要HEAD写对就OK了。你可以写commit id，也可以HEAD^，也可以HEAD^^。

前进版本

有时候，如果我们回退到了旧的版本，但是却后悔了，想回到后面某个新的版本，但这个时候，我的commit id已经忘了，怎么办呢？
没事，通过这个指令：

5427c66 HEAD@{0}: reset: moving to HEAD^
e7ae095 HEAD@{1}: checkout: moving from dev to master
7986a59 HEAD@{2}: checkout: moving from master to dev
e7ae095 HEAD@{3}: checkout: moving from dev to master
7986a59 HEAD@{4}: checkout: moving from 7986a59bd8683acb560e56ff222324cd49edb5e5 to dev
7986a59 HEAD@{5}: checkout: moving from master to origin/dev
e7ae095 HEAD@{6}: clone: from git@github.com:xuyisheng/testGit.git

这样我们就可以找到commit id用来还原了。

git reflog记录的就是你的操作历史。

文件操作

git rm

如果我们要删除git仓库中的文件，我们要怎么做呢？

我们创建一个新的文件并提交，再删除这个文件：

  gitTest git:(master) rm test.txt
  gitTest git:(master)  git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

git提示我们delete一个文件，这时候你可以选择:

  gitTest git:(master)  git checkout test.txt

这样就撤销了删除操作，或者使用：

  gitTest git:(master)  git rm test.txt
rm 'test.txt'
  gitTest git:(master)  git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   deleted:    test.txt
#
  gitTest git:(master)  git commit -m "delete test.txt"
[master 5427c66] delete test.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 test.txt

通过git rm指令，删除文件，最后提交修改，就真实的删除了文件。

文件暂存

这里的暂存不是前面说的暂存区，而是只一次备份与恢复操作。举个例子，当前我们在dev分支上进行一个新功能的开发，但是开发到一半，测试提了一个issue，这时候，我们需要创建一个issue分支来修改这个bug，但是，当前dev分支是不干净的，新功能开发到一半，直接从dev上拉分支，代码是不完善的，可能会编译不过。
so，你可以使用：

git stash

指令来将当前修改暂存，这样就可以切换到其他分支或者就在当前干净的分支上checkout了。
比如你checkout了一个issue分支，修改了bug，使用git merge合并到了master分支，删除issue分支，切换到dev分支，想继续之前的新功能开发。
这时候，就需要恢复现场了：

首先，通过：

git stash list

我们可以查看当前暂存的内容记录。

然后，通过git stash apply或者git stash pop来进行恢复，它们的区别是，前者不会删除记录（当然你可以使用git stash drop来删除），而后者会。

远程仓库

既然git是分布式的仓库管理，那么我们肯定是需要多台服务器进行各种操作的，一般在开发中，我们会用一台电脑做中央服务器，各个终端从中央服务器拉取代码，提交修改。

那么我们如何去搭建一个git远程服务器呢，答案是不要搭建，个人开发者可以通过github来获取免费的远程git服务器，或者是国内的开源中国之类的，同样也提供免费的git服务器，而对于企业用户，可以通过gitlab来获取git远程服务器。

身份认证

当本地git仓库与git远程仓库通信的时候，需要进行SSH身份认证。

打开根目录下的.ssh目录：

  ~  cd .ssh
  .ssh  ll
total 40
-rw-------  1 xys  staff   1.7K  5 15 23:53 github_rsa
-rw-r--r--  1 xys  staff   402B  5 15 23:53 github_rsa.pub
-rw-------  1 xys  staff   1.6K  5 15 09:38 id_rsa
-rw-r--r--  1 xys  staff   409B  5 15 09:42 id_rsa.pub
-rw-r--r--  1 xys  staff   2.0K  6  3 13:34 known_hosts

如果没有id_rsa和id_rsa.pub这两个文件，就通过如下的命令生成：

ssh-keygen -t rsa -C "youremail@example.com"

id_rsa和id_rsa.pub这两个文件，就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，用在github上表明身份。

在github的ssh key中增加刚刚生成的key：

这里写图片描述

同步协作

现在你在本地建立了git仓库，想与远程git仓库同步，这样github的远程仓库可以作为你本地的备份，也可以让其他人进行协同工作。

我们先在github上创建一个repo（仓库）：

这里写图片描述

创建之后，github给我们提示：

这里写图片描述

github告诉了我们如何在本地创建一个新的repo或者将既存的repo提交到远程git。

由于我们已经有了本地的git，所以，安装提示：

  gitTest git:(master) git remote add origin git@github.com:xuyisheng/testGit.git
  gitTest git:(master) git push -u origin master
Counting objects: 18, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (18/18), 1.39 KiB | 0 bytes/s, done.
Total 18 (delta 1), reused 0 (delta 0)
To git@github.com:xuyisheng/testGit.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

现在我们再看github上的仓库：

这里写图片描述

README已经提交上去了。

git remote add origin git@github.com:xuyisheng/testGit.git这条指令中的origin，就是远程仓库的名字，你也可以叫别的，但是默认远程仓库都叫做origin，便于区分。

PS: 这里还需要注意下的是git push的-u参数，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来。不过后面的push就不需要这个参数了。

之后我们再做修改：

  gitTest git:(master)  git add README.txt
  gitTest git:(master)  git commit -m "modify again"
[master e7ae095] modify again
 1 file changed, 2 insertions(+), 1 deletion(-)
  gitTest git:(master) git push
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 285 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:xuyisheng/testGit.git
   5427c66..e7ae095  master -> master

可以直接使用git push或者git push origin master来指定仓库和分支名。

clone远程仓库

记得我们之前说的，创建本地仓库的几种方式，其中有一种是clone：

我们可以通过git clone指令来clone一个远程仓库：

这里写图片描述

下面就显示了远程仓库的地址，一般我们使用SSH的方式，当然，也可以使用其他方式，然并卵。

PS: 使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

直接使用：

  MyWork  git clone git@github.com:xuyisheng/testGit.git
Cloning into 'testGit'...
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 21 (delta 1), reused 21 (delta 1), pack-reused 0
Receiving objects: 100% (21/21), done.
Resolving deltas: 100% (1/1), done.
Checking connectivity... done

分支管理

个人认为，创建分支是git最大的魅力。
git中的分支就好像现在的平行宇宙，不同的分支互不干扰，相互独立，你就像一个上帝一样，可以随时对任意一个分支进行操作，可以今天去这个branch玩，明天去另一个branch，玩腻了，再把两个分支合并，一起玩。

举个比较恰当的例子，我现在要开发一个新功能，需要3个月的时间，但是我不能每天都把未完成的代码提交到大家都在用的分支上，这样人家拉取了我的代码就无法正常工作了，但是我又不能新建一个仓库，这也太浪费了，所以我可以新建一个分支，在这个分支上开发我的功能，同时能够备份我的代码，当开发完毕后，直接合并分支，整个新功能就一下子加入了大家的分支。

创建分支

你的每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。不创建分支时，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

这里写图片描述

这里的时间线就看的非常清楚了。

我们通过如下指令来创建分支：

  gitTest git:(master) git checkout -b dev
Switched to a new branch 'dev'
  gitTest git:(dev)

-b参数代表创建并切换到该分支，相当于：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

不加-b参数就是直接切换到已知分支了。

查看分支

通过git branch指令可以列出当前所有分支：

  gitTest git:(dev) git branch
* dev
  master

当前分支上会多一个*

合并分支

切换到dev分支后，我们进行修改，add并commit：

此时我们再切换到master分支，再查看当前修改，你会发现，dev分支上做的修改这里都没有生效。必须的，不然平行宇宙就不平行了。我们通过如下指令来进行分支的合并：

  gitTest git:(master) git merge dev
Updating e7ae095..7986a59
Fast-forward
 README.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

这样再查看master分支下的文件，dev上的修改就有了。

删除分支

使用完毕后，我们不再需要这个分支了，所以，放心的删除吧：

  gitTest git:(master) git branch -d dev
Deleted branch dev (was 7986a59).
  gitTest git:(master) git branch
* master

PS : 当分支还没有被合并的时候，如果删除分支，git会提示：
error: The branch ‘feature-vulcan’ is not fully merged.
If you are sure you want to delete it, run ‘git branch -D dev.
也就是提示我们使用-D参数来进行强行删除。

看完分支的操作，有人可能会问，创建这么多分支，git会不会很累，当然不会，git并不是创建整个文件的备份到各个分支，而是创建一个指针指向不同的分支而已。切换分支，创建分支，都只是改变指针指向的位置。

分支是非常好的团体协作方式，一个项目中通常会有一个master分支来进行发布管理，一个dev分支来进行开发，而不同的开发者checkout出dev分支来进行开发，merge自己的分支到dev，当有issue或者新需求的时候，checkout分支进行修改，可以保证主分支的安全，即使修改取消，也不会影响主分支。

查看远程分支

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
通过如下指令，我们可以查看远程分支：

  gitTest git:(master) git remote
origin

或者：

  gitTest git:(master) git remote -v
origin  git@github.com:xuyisheng/testGit.git (fetch)
origin  git@github.com:xuyisheng/testGit.git (push)

来显示更详细的信息。

推送分支

要把本地创建的分支同步到远程仓库上，我们可以使用：

  gitTest git:(master) git checkout -b dev
Switched to a new branch 'dev'
  gitTest git:(dev) git push origin dev
Everything up-to-date

这样就把一个dev分支推送到了远程仓库origin中。

抓取远程分支

当我们将远程仓库clone到本地后即使远程仓库有多个分支，但实际上，本地只有一个分支——master。

  MyWork  git clone git@github.com:xuyisheng/testGit.git
Cloning into 'testGit'...
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 24 (delta 2), reused 23 (delta 1), pack-reused 0
Receiving objects: 100% (24/24), done.
Resolving deltas: 100% (2/2), done.
Checking connectivity... done
  MyWork  cd testGit
  testGit git:(master) git branch
* master

现在，我要在dev分支上开发，就必须创建远程origin的dev分支到本地，用这个命令创建本地dev分支：

  testGit git:(master) git checkout -b dev origin/dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch 'dev'
  testGit git:(dev)

这样就把本地创建的dev分支与远程的dev分支关联了。
后面你可以使用git push origin dev继续提交代码到远程的dev分支。

这种情况下，如果其他人也提交了到dev分支，那么你的提交就会与他的提交冲突，因此，你需要使用git pull先将远程修改拉取下来，git会自动帮你在本地进行merge，如果没有冲突，这时候再提交，就OK了，如果有冲突，那么必须手动解除冲突再提交。

Tag

Tag的概念非常类似于branch。但是branch是可以不断改变、merge的，Tag不行，Tag可以认为是一个快照，用于记录某个commit点的历史快照。

创建标签

非常简单：

  testGit git:(master) git tag version1

默认Tag会打在最后的提交上。但是你也可以通过commit id来指定要打的地方。

  testGit git:(master) git tag version0 b687b06fbb66da68bf8e0616c8049f194f03a062
  testGit git:(master) git tag
version0
version1

PS : 实际上commit id不需要写很长，通过前6、7位，git就可以查找到相应的id了。

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

git tag -a v1 -m "version1" b687b06fbb66da68bf8e0616c8049f194f03a062

通过如下指令来查看详细信息：

git show <tagname>

查看标签

  testGit git:(master) git tag
version1

删除标签

-d参数就可以了，与branch类似。

  testGit git:(master) git tag
version0
version1
  testGit git:(master) git tag -d version0
Deleted tag 'version0' (was b687b06)
  testGit git:(master) git tag
version1

推送到远程

将本地tag推送到远程参考上：

  testGit git:(master) git push origin version0
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:xuyisheng/testGit.git
 * [new tag]         version0 -> version0

或者：

  testGit git:(master) git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:xuyisheng/testGit.git
 * [new tag]         version1 -> version1

来push所有的tag。

删除远程Tag

当Tag已经push到远程仓库后，我们要删除这个Tag，首先需要先删除本地Tag：

  testGit git:(master) git tag -d version0
Deleted tag 'version0' (was b687b06)

再push到远程，带指令有所不同：

  testGit git:(master) git push origin :refs/tags/version0
To git@github.com:xuyisheng/testGit.git
 - [deleted]         version0

以上。

学完这些，对付基本的Git使用，就没什么问题了，后面会再出一篇Git workflow plus，介绍一下Git的高级 操作。

weixin_34358092
关注
Git Workflow工作流程
ahxieqi的博客
03-02 317
2019 March 02 git,workflow Git Workflow工作流程 1. Gitflow分支 分支 名称 作用 master 主分支 存储正式发布的历史 hotfix 上线分支 bug情急修复分支 release 发布分支 发布上线的时候用 develop 开发分支 功能的集成分支 feature 功能分支 开发新功能都会有对应的fea...
Git三大特色之WorkFlow(工作流)
热门推荐
浅浅同学的开发笔记
12-26 4万+
开篇 Git 三大特色，分支，暂存区，工作流，今天终于要写到 WorkFlow 了，我彷佛已经看到胜利的曙光，走起。 何谓工作流 WorkFlow 的字面意思，工作流，即工作流程。在分支篇里，有说过这样的话：因为有分支的存在，才构成了多工作流的特色。事实的确如此，因为项目开发中，多人协作，分支很多，虽然各自在分支上互不干扰，但是我们总归需要把分支合并到一起，而且真实项目中涉及到很多问题，...
Git Workflow简介
Mantou的博客
01-07 240
1. Git WorkFlow介绍 Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。 2010年5月，在一篇名为“一种成功的Git分支模型”的博文中，@nvie介绍了一种在Git之上的软件开发模型。通过利用Git创建和管理分支的能力，为每个分...
Git Workflow最佳实践
Ricky
09-12 2142
Git Flow最佳实践
GitFlow Workflow
MyException Blog
12-18 167
介绍 Gitflow是Git工作流的一个抽象概念，它定义一系列的规则，简历什么样的分支，怎么merge不同的分支。 Gitflow适合定期更新发布的项目。它将不同分支（branch）赋予不同的角色，规定好不同分支间如何相互作用。 如何使用 develop和master Gitflow使用这2个分支，记录项目的提交历史。master存放正式对外发布历史，develop用来整合不同的功能（featu...
git workflow
最新发布
07-29
Git workflow 是指在使用 Git 版本控制时，团队协作开发时所采用的工作流程。常见的 Git workflow 包括集中式工作流、功能分支工作流、Gitflow 工作流、Forking 工作流等。 1. 集中式工作流（Centralized Workflow...
深入理解学习Git工作流（git-workflow-tutorial）
02-25
工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定，不仅是Git或SVN等VCS或SCM工具的使用。这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进...
Git Workflow：Centralized Workflow详解
Git Workflow是一种团队协作开发的方法论，它规范了如何使用Git版本控制系统进行代码管理和协作。通过Git Workflow，团队成员可以清晰地知道自己在项目中的角色和职责，并且能够更好地协作开发、追踪问题和管理代码...
git-workflow
c++基础
05-03 341
git workflow 1、master：（每一次变动都是一个版本；来源release和hotfix；服务hotfix；为第一个develop提供服务） 2、hotfix：（master某个版本发现问题后，可能需要多次提交验证，为减少master的版本号多次变化；来源master；服务master） 3、release：（测试对即将发布的版本做回归验证，开发做bug修复，无新功能提交；...
三菱PLC高速计数实例
01-15
三菱PLC高速计数器实例，非常适合新手学习参考用。
哈希表的建立及其构造
12-28
较优，程序简短，较易懂，实现时很方便，短炼
微信小程序java后台代码(服务端)demo
11-09
代码包含会话服务，信道服务等以及sdk服务器所用到的代码，以及微信客服端网络请求controller登录处理方式，以及sdk.json文件的配置
SecureCRT登陆
10-16
SecureCRT 免注册，直接可以使用
Git_WorkFlow
qq_53318060的博客
07-11 302
git
Git Workflow 详谈
Docker的专栏
09-30 273
作为一名工程师，Git 在日常开发中是不可或缺的工具。这里详细介绍几种比较常用的基于 Git 的工作流模型, 以便于团队协作的规范化和效率提升。中心化工作流使用过 SVN...
实用 Git Workflow
WangSai.coo的专栏
06-15 589
创建分支分支是 Git 的核心概念，同时 Git Workflow 也是基于分支进行操作.当你新增功能或修复 bug 时候，新建一个分支是一个不错的选择，这将不会影响主分支 master. 所以你可以放心地尝试和提交更改，直到代码审查和运行通过，才会被合并到 master 分支.细微的 bug，可以在原分支进行修改，不必新建分支.一般新增功能而建立的分支，称为「特性分支或功能分支」此外，分支的命名...
Git之GitFlow工作流 | Gitflow Workflow（万字整理，已是最详）
青春木鱼的博客
05-17 3万+
git 作为一个代码管理系统，不可避免的会涉及到多人合作。Git flow是基于git之上的一种软件开发迭代模型。Git flow是使用git进行源代码管理的一套行为规范。简单来说就是通过规范化的流程，使得产品、开发与测试等各个部门更高效的协同工作。Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题，提高开发效率。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值