Gitウェアハウスの構築とブランチ管理を完全マスター

WBOY
リリース: 2022-03-24 19:19:18
転載
3963 人が閲覧しました

この記事では、Git に関する関連知識を提供します。プライベート Git ウェアハウスの構築からコマンドの使用、ブランチ管理まで、関連する問題を主に紹介します。以下では例を使用して見ていきます。詳細に説明しますので、皆様のお役に立てれば幸いです。

Gitウェアハウスの構築とブランチ管理を完全マスター

推奨学習: 「Git チュートリアル

1. Git とは何ですか?

Git は、小規模なプロジェクトから非常に大規模なプロジェクトまで、プロジェクトのバージョン管理を効果的かつ迅速に処理できるオープンソースの分散バージョン管理システムです。 Git は C 言語によって開発および実装されます。

2. Git と SVN の比較

Git と SVN は、まったく異なる 2 つのバージョン管理システムであり、Git は分散型バージョン管理システムであるのに対し、SVN は集中型バージョン管理システムです。 Git と SVN の違いを比較するには、まず分散バージョン管理システムと集中バージョン管理システムの基本概念を理解する必要があります。
集中バージョン管理システム: バージョンライブラリが中央サーバーに格納され、プロジェクトのバージョン情報やブランチ情報が中央サーバーで一元管理されることが特徴です。チームの各メンバーは、作業を開始する前に中央サーバーから最新のコードを取得する必要があります。作業が完了したら、コードを中央サーバーに送信します。集中バージョンのサーバーには 2 つの欠点があります:

    サーバーが動作するにはインターネットに接続する必要があり、ネットワークがない場合、またはネットワークが非常に悪い場合、チームのメンバーは一緒に作業できません。
  1. バージョン ライブラリは中央サーバーに保存されているためセキュリティが悪く、中央サーバーが破損するとバージョン ライブラリが失われ、すべてのメンバーが作業できなくなります。
集中バージョン管理システムのネットワーク トポロジを以下に示します。


Gitウェアハウスの構築とブランチ管理を完全マスター チームのすべてのメンバーの作業用コンピュータが中央のバージョン管理システムのみを処理していることがわかります。サーバ。バージョン ライブラリを書籍ライブラリに喩えると、全員 (各コンピュータ) がまず図書館から本を借りて (最新のコードを取得し)、読んでから図書館に返す (変更後に中央サーバーに送信する) 必要があります。 )

分散バージョン管理システム: 集中バージョン管理システムとの最大の違いは、

チームのメンバー全員が職場のコンピューター上に完全なバージョン ライブラリを持っており、中央サーバーがないことです。 , これは、チームの各メンバーが自分の小さなライブラリ (バージョン ライブラリ) を持つことに相当し、メンバーは自分のライブラリ内の本を互いに交換できます (変更を相互に送信できます)。中央サーバーで管理や調整を行う必要はありません。 実際に分散バージョン管理システムを使用する場合、同じ LAN 内にいない場合や同僚のコンピュータがシャットダウンしている場合があるため、2 人の間でコンピュータ上のバージョン ライブラリをプッシュすることはほとんどありません。したがって、分散バージョン管理システムには、通常、「中央サーバー」として機能するコンピューターもありますが、このサーバーの役割は、全員の変更を「交換」することだけを目的としています。サーバーなしでも、全員が作業できますが、交換には不便です。修正です。
「中央サーバー」として機能するこのコンピューター上のバージョン ライブラリはリモート バージョン ライブラリと呼ばれ、他のメンバー コンピューター上のバージョン ライブラリはローカル バージョン ライブラリと呼ばれます。これについては後で詳しく説明します。

分散バージョン管理システムのネットワーク トポロジを次の図に示します。

Gitウェアハウスの構築とブランチ管理を完全マスター 分散バージョン管理システムでは、中央サーバーが不要となり、システムのコアが完全に反映されます。分散 概念は分散化です。これには 2 つの利点があります:

    ネットワークなしで作業できる: ローカルに完全なバージョンのライブラリがあるため、チームのメンバー全員がネットワークなしで作業でき、データ損失を心配する必要はありません。
  1. データの安全性が向上: メンバーのコンピューターが壊れても問題ありません。他のメンバーのコンピューターからコピーを作成するだけで済みます。しかし、集中バージョン管理システムの中央サーバーに問題が発生すると、バージョン ライブラリが失われ、全員が作業できなくなる可能性があります。
3. システム環境

システムバージョンWindowsWindows10LinuxUbuntu16.04

4. Git クライアントのインストール

Git の基本概念について説明した後、Git クライアントをインストールして遊んでみましょう。ここでは、さまざまなオペレーティング システムに基づいた Git クライアントのインストールについて簡単に紹介します。

Linux システムの場合

まず、git --version コマンドを使用して、Git クライアントがコンピューターにインストールされているかどうかを確認します。
Gitウェアハウスの構築とブランチ管理を完全マスター
すでにインストールしている場合は、この章をスキップしてください。インストールされていない場合は、以下を読み続けてください:
Linux システムにはさまざまなディストリビューション バージョンがあります。cat /proc/version コマンドを使用して Linux バージョンを確認できます。

  1. Debian または Ubuntu での Git のインストール
    Debian または Ubuntu では、apt パッケージ管理ツールを使用して Git をインストールできます。コマンドは次のとおりです:
sudo apt-get install git
ログイン後にコピー
  1. Red Hat または CentOS での Git のインストール
    Red Hat または CentOS では、yum パッケージ管理ツールを使用して Git をインストールできます。コマンドは次のとおりです:
yum install git -y
ログイン後にコピー

yum コマンドが見つからない場合、最初に yum ツールをインストールする必要があります。次のコマンドを参照できます。

#删除yum.repos.d目录下所有文件rm -f /etc/yum.repos.d/*#然后重新下载阿里的yum源wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo#清理缓存yun clean all
ログイン後にコピー

Windows システムの場合

Git の公式ダウンロード アドレスは次のとおりです。 Git ダウンロード アドレス
Gitウェアハウスの構築とブランチ管理を完全マスター
インストール パッケージをダウンロードした後、 「次へ」をクリックしてインストールの準備ができました。繰り返しになりますが、詳細には触れません。

5. ローカル リポジトリの操作

Windows に Git をインストールすると、Git のコマンド ライン ツールである Git Bash と Git GUI という 2 つのアプリケーションが表示されます。 Git の視覚化ツールです (通常はほとんど使用されません)。

ローカル リポジトリの作成

ローカル リポジトリの作成は 2 つの手順に分かれています:
最初の手順では、git_learn という名前の空のフォルダーを作成します。
2 番目のステップは、フォルダー内で git init コマンドを実行して、フォルダーを git で管理できるリポジトリに変えることです。
2 番目の手順を実行すると、.git という名前の隠しフォルダーが git_learn ディレクトリに表示されます。これは git バージョン ライブラリです。 ローカル バージョン ライブラリが使用できなくなることを避けるため、.git フォルダー内のコンテンツを手動で変更しないでください。

ローカル バージョン ライブラリが構築されたら、テスト用に git_learn フォルダーにファイルを作成できます。ここで readme.txt という名前のファイルが作成されます。

ステージング領域に追加する
readme.txt ファイルは、
git add readme.txt コマンドを使用してステージング領域に送信できます (ステージング領域の概念については後で詳しく説明します) )。追加するファイルが複数ある場合は、git add . コマンドを実行できます。 リポジトリに送信する
git には完全なローカル リポジトリがあるため、以前に作成した readme.txt ファイルをローカル リポジトリの現在のブランチに送信する必要もあります。デフォルトは master です。コマンドの形式は
git commit -m '' で、ここに送信のコメントが記述されます。

ワークスペースとステージング領域

ここには 2 つの非常に重要な概念があります。1 つはワークスペース、もう 1 つはステージング領域 (Git に固有の概念) です。

ワークスペース
ワークスペースは、コンピューター上で表示できるディレクトリです (隠しファイルを除く)。例: git_learn ディレクトリはワークスペースです。

ステージング領域

ワークスペースには隠しディレクトリ .git があります。これはワークスペースではなく、Git リポジトリです。最も重要なのはステージです。

Git が自動的に作成する master と呼ばれる最初のブランチと、HEAD と呼ばれるマスターへのポインタもあります。

ワークスペース、ステージング領域、

git add コマンド、および git comit コマンドについては前述しました。それで、それらの間にはどのような関係があるのでしょうか?以下のフローチャートを使用して示してみましょう。
Gitウェアハウスの構築とブランチ管理を完全マスター add コマンドを使用してワークスペース内の ABC フォルダーを一時記憶領域ステージに送信し、commit コマンドを使用して ABC フォルダーを一時記憶域ステージに送信します。ステージから現在のステージへ ブランチマスター。

変更の管理

Git はファイルではなく変更を管理します。ここでの変更とは、ファイルの追加、削除、ファイルの変更など、ワークスペース上のあらゆる操作を指します。ファイル内の文を追加したり、文字を削除したりすることも変更とみなされます。以下は例ですが、引き続き readme.txt ファイルを例にしています:

  1. 第一次在readme.txt文件中增加一个词语 gittest。然后执行git add readme.txt,并通过命令git status查看状态。
    hello world
    gittest

    Gitウェアハウスの構築とブランチ管理を完全マスター
  2. 第二次再在readme.txt文件上添加一行内容git tracks changes
    hello world
    gittest
    git tracks changes

直接执行git commit -m 'git tracks changes'命令。然后通过 git status,可以发现第二次的修改没有提交。这是因为第二次的修改没有先提交到暂存区中。
Gitウェアハウスの構築とブランチ管理を完全マスター
我们的操作过程是第一次修改 -> git add -> 第二次修改 -> git commit。当使用git add 命令后,在工作区中的第一次修改被放入暂存区中,准备提交,在工作区中的第二次修改没有被放入暂存区中,所以,git commit只负责把暂存区中的修改提交到当前分支。所以第二次的修改没有提交。
也就是说,所有的修改必须先通过git add 提交到暂存区,然后通过git commit 提交到当前分支。。在实际开发中一般是将所有修改合并起来add,然后在一起commit。

删除文件

当前分支上有一个已经废弃不用的文件,该如何删除呢?比如要删除一个名为test1.txt文件。只需要两行命令。

git rm test1.txtgit commit -m "remove test.txt"
ログイン後にコピー

5.Ubuntu搭建私有的git仓库

前面介绍了在实际开发中,一般会拿一台电脑作为“中央仓库”,充当中央仓库的电脑需要安装一个代码仓库软件,这里选用开源软件GitLab,它是基于git实现的在线代码仓库软件,提供web可视化管理界面,可以在本地部署。通常用于企业团队内部协作开发。当然,如果你不想搭建私人的git仓库,那么也可以直接使用最大的同性交友网站Github(使用与GitLab类似)。
那么该如何在Ubuntu上安装GitLab软件,搭建私有的Git仓库呢?

  1. 安装必须的一些服务
#更新apt源sudo apt-get update#安装依赖包,运行命令sudo apt-get install curl openssh-server ca-certificates postfixsudo apt-get install -y postfix
ログイン後にコピー
  1. 接着信任 GitLab 的 GPG 公钥:
curl https://packages.gitlab.com/gpg.key 2> /dev/null | sudo apt-key add - &>/dev/null
ログイン後にコピー
  1. 配置镜像路径
    由于国外的下载速度过慢,所以配置清华大学镜像的路径。
sudo vi /etc/apt/sources.list.d/gitlab-ce.list
ログイン後にコピー

在该文件中写入如下代码

deb https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu xenial main
ログイン後にコピー
  1. 安装gitlab-ce
sudo apt-get updatesudo apt-get install gitlab-ce
ログイン後にコピー

安装gitlab-ce成功之后。
5. 修改外部url
在gitlab配置文件/etc/gitlab/gitlab.rb中修改外部url,改为自己的ip地址或者域名。

sudo vi /etc/gitlab/gitlab.rb
ログイン後にコピー

找到external_url,修改其默认的地址,这里改成了我本机局域网IP:192.168.40.138

external_url 'http://192.168.40.138/'  ## 本机的局域网ip地址为192.168.41.128
ログイン後にコピー
  1. 执行配置
    前面步骤顺利的话就可以执行配置了,该过程可能需要较长的时间。
sudo gitlab-ctl reconfigure
ログイン後にコピー
  1. 启动GitLab
sudo gitlab-ctl start
ログイン後にコピー

可以通过ps -ef|grep gitlab 命令查看GitLab是否启动成功。
8. 进行浏览器访问
GitLab成功启动之后就可以通过浏览器访问GitLab的主页了。在浏览器上输入http://192.168.40.138/;
Gitウェアハウスの構築とブランチ管理を完全マスター
默认输入的用户名是root用户,输入的密码是root的账户密码。
至此GitLab的安装就全部结束,我们也成功的搭建了属于自己的Git仓库。

GitLab的使用

添加用户

点击设置按钮,进入设置栏,选中Users->New User 进入添加用户页面。
Gitウェアハウスの構築とブランチ管理を完全マスター
Gitウェアハウスの構築とブランチ管理を完全マスター
输入姓名,用户名,和邮箱即可注册添加新用户。

添加团队

用户添加好之后,就是将用户添加到团队中,GitLab中默认会有一个名为GitLab Instance的团队,你也可以添加自己的团队,这里我添加了一个名为ai_edu的团队。并在团队中添加了两个成员。
Gitウェアハウスの構築とブランチ管理を完全マスター
选中要添加成员的团队,在右侧会出现一个添加Add user(s) to the group的栏目。再此栏目中所有用户并添加到团队中。用户的角色有游客,测试人员,开发人员,管理者,拥有者等几个不同的角色。
Gitウェアハウスの構築とブランチ管理を完全マスター

新建远程仓库

说完了用户和团队的设置后,现在就进入了重点了,如何新建一个远程仓库。同样也是比较方便。操作步骤是:Project->Your projects->New project
Gitウェアハウスの構築とブランチ管理を完全マスター
Gitウェアハウスの構築とブランチ管理を完全マスター
这里新建了一个名为git_test的远程仓库,仓库的所有这是属于ai_edu团队。
Gitウェアハウスの構築とブランチ管理を完全マスター

这里仓库的权限等级有三个等级,分别是:Private(只有你团队的人才能拉取和推送代码),Internal(除了黑名单之外的用户可以拉取和推送代码)。Public (所有的用户都可以拉取)。

SSH key的配置(生成公钥和私钥)

为啥要配置SSH key呢?这是因为GitLab与你的电脑是通过SSH协议来通信的。说白了,如果你没有配置SSH key的话,则你不能推送代码到远程库。这里首先在你本地生成公钥和私钥文件,然后把公钥文件的内容复制到GitLab上。

  1. 配置用户名
git config --global user.name “username”
ログイン後にコピー
  1. 配置邮箱
 git config --global user.email  jayxiang31@gmail.com
ログイン後にコピー

jayxiang31@gmail.com替换成你实际的邮箱地址。不需要加单引号。
4. 生成公钥和私钥

ssh-keygen -C 'you email jayxiang31@gmail.com' -t rsa
ログイン後にコピー

如果简单些的话可以直接填写ssh-keygen 命令。邮箱地址填写前面设置的邮箱地址。有提示的话一直按Enter键。正确执行后会输入如下信息
Gitウェアハウスの構築とブランチ管理を完全マスター

2 找到公钥文件id_rsa.pub,复制公钥内容到GitLab
Gitウェアハウスの構築とブランチ管理を完全マスター

6. 分支管理

创建与合并分支

分支的概念:分支就是每次提交创建的点所连接成的时间线。这条时间线就是一个分支,默认的话只有一个主分支master分支。HEAD严格来说不是指向提交,而是指向master,master才是指向提交,HEAD指向的就是当前分支。
一开始的时候,master分支就是一条线,Git用master指向最新的提交,再用HEAD指向master,就能够确定当前的分支以及当前分支的提交点。
每次提交,master分支都会向前进移动一步,这样随着你不断提交,master分支的线也会越来越长。其结构如下图所示:
Gitウェアハウスの構築とブランチ管理を完全マスター

1. 创建dev分支

当我们新创建一个分支dev时,Git会创建一个指针dev指向master分支当前的提交点。当切换到dev分支后,HEAD指针会指向dev。也就是说HEAD始终是指向当前分支的

git checkout -b dev
ログイン後にコピー

git checkout 加上-b参数表示创建并切换到dev分支上,相当于下面两条命令。

$ git branch dev
$ git checkout dev
ログイン後にコピー

执行该上面的命令之后的git的提交时间线如下图所示:
Gitウェアハウスの構築とブランチ管理を完全マスター
当在dev分支上提交代码(未改变master分支)之后,dev分支会不断的向后推进。而master指针的指向则不会变。
Gitウェアハウスの構築とブランチ管理を完全マスター
git checkout命令是一个比较特殊的命令,传入不同的参数会有截然不同的效果。例如:git checkout -- file 命令,表示的意思是撤销file文件中所有的修改。所以Git还提供了git switch命令用于创建和切换分支。

## 创建并切换到新的dev分支git switch -c dev## 切换到已有的master分支git switch master
ログイン後にコピー

2. 查看所有分支

分支创建好之后,可以通过git branch命令进行查看。

3. 分支合并

当团队成员在dev分支上开发完毕之后,就可以将dev分支上的内容合并到master分支上,合并分支的原理就是将master指针指向dev的当前提交。Git合并分支只是改了下指针,工作区的内容没有改变。
Gitウェアハウスの構築とブランチ管理を完全マスター

其合并的命令分两步,第一步是切换到master分支,第二步是合并dev分支

#切换到master分支git checkout master#合并dev分支git merge dev
ログイン後にコピー
  1. 删除dev分支
    现在dev分支的内容也合并到了master分支上了,可以将dev分支删除了。Git删除dev分支其实就是删除dev指针。删除之后又只剩下master分支了。需要注意的是必须要先切换到master分支上再进行删除dev分支的操作。删除dev分支的命令如下:
git branch -d dev
ログイン後にコピー

解决冲突

在团队协作过程中,难免会碰到各种修改冲突。那么该如何解决这些冲突呢? 例如:你和你同事分别修改了readme.txt文件,那么当你们同时提交时就会出现冲突。又或者在你在master分支和feature1分支上分别修改了readme.txt文件。那么当你合并feature1分支到master分支时就会出现冲突。举个栗子吧:

  1. 在feature1分支上给readme.txt文件中加上了文本处理冲突。然后提交到feature1分支。
  2. 切换到master分支,给readme.txt文件中加上文本
冲突处理
master有冲突
ログイン後にコピー

然后提交到master分支上。
3. 将feature1分支合并到master分支,此时就会出现合并冲突。如下图所示:

冲突之后,Git用>>>>>>标记出不同分支的内容。如下图所示:
处理冲突的方式就是编辑冲突内容。然后重新提交。

$ git add README.md
$ git commit -m "解决冲突"
ログイン後にコピー

比较差异

  1. 比较两个提交之间的差异 git diff 36e4fd7 b55da38
    Gitウェアハウスの構築とブランチ管理を完全マスター
  2. 比较工作区与仓库区的不同,HEAD表示最新的那次提交 git diff HEAD

分支管理策略

通常情况下,Git在合并分支时,会使用Fast forward模式。但是,这种模式下,删除分支后,会丢掉分支信息。如下图所示,删除dev分支之后,分支的信息也就就丢失了

Gitウェアハウスの構築とブランチ管理を完全マスター
如果要强制禁用Fast forward模式,Git会在merge时生成一个新的commit。当删除分支时就不会丢失分支信息。其命令是
git merge --no-ff -m "merge with no-ff" dev
准备合并dev分支,其中--no-ff参数,表示禁用Fast forward,因为本次合并要创建一个新的commit,所以加上-m参数。把commit描述写进去。

Bug分支

当你接到一个修复代号为01的bug的任务时,很自然地,你会创建一个分支issue-01来修复它,但是,如果这是你正在dev分支上进行的工作还没有提交,提交吧,可是你在dev上的工作只进行了一般,还没法提交,预计完成还需1天的时间。但是,现在必须要在两个小时内修复代号01的bug。这时候该怎么办呢?你不是期望有一个功能可以隐藏你当前在dev上未提交的工作,然后,切换到issue-01分支修改bug呢。
通过stash功能可以满足你的愿望,将当前工作现场隐藏起来。如下图所示:执行git stash命令之后,新建的hello.html文件就从工作区中消失了。
Gitウェアハウスの構築とブランチ管理を完全マスター

保存工作现场

git stash
ログイン後にコピー

git stash命令可以将当前未提交的工作隐藏起来。让你的工作区变的干净清爽。

查看工作现场

git stash list 可以查看当前仓库所有已经保存的工作现场。

git stash list
ログイン後にコピー

恢复工作现场

现在代号为01的bug已经修复好了,你可以继续切换到dev分支上进行开发了。那么这时候你需要做的第一件事就是恢复之前保存的工作现场。恢复工作现场的命令是:

git stash apply
ログイン後にコピー

删除工作现场

通过git stash apply 命令可以恢复工作现场。但是,恢复之后工作现场还在。那么这时候我们还需要一个命令来删除工作现场。其命令是:

git stash drop
ログイン後にコピー

恢复并删除工作现场

恢复工作现场一条命令,删除工作现场又是一条命令。未免有点繁琐了吧。有没有将两者合二为一的命令呢?答案是有的:通过下面的命令就可以实现:

git stash pop
ログイン後にコピー

在master分支上修复了bug后,我们想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug?重复操作一次,提交不就行了?这种方法也不是不行,如果该BUG涉及的修改过多,这样的方式就显得有点捉襟见肘了。那么我们能不能把修改BUG做的提交复制到当前的dev分支呢?答案是有的:

合并某一次的提交

git cherry-pick  821ea4d
ログイン後にコピー

通过git cherry-pick 命令可以将单个的提交复制到当前分支。可以通过 git log 查看提交的提交的版本号。

feature分支

添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
前面介绍可以通过git branch -d branchname 命令删除分支。但是,如果被删除的分支还没有合并到主分支的话,用该命令删除的话分支的话,Git会抛出一个错误提示并不能删除该分支。如下:要删除一个名为feature-01的分支。但是该分支还没有被merge。这时候就需要强制删除分支的命令了。

git branch -D feature-01
ログイン後にコピー

其中feature-01为待删除的分支名。其实就是将-d参数换成-D参数。

远程仓库(多人协作)

前面说了那么多,好像都是一个人在本地操作,没有涉及到多人协作的情况。这在团队开发中肯定是不可能的啦,因为我们是一个team。那么多人协作的情况涉及哪些操作呢?

本地仓库关联远程仓库

git remote add origin http://192.168.40.138/ai-edu/git-demo.git
ログイン後にコピー

或者,推荐使用下面这种,因为前面配置了SSH公钥和私钥

git remote add origin git@gitee.com:jayxiang31/python_learn.git
ログイン後にコピー

第一次先拉取远程库中的README.md和.gitignore等文件

git pull --rebase origin master
ログイン後にコピー

克隆远程仓库

前面第三章已经搭好了私有的Git仓库管理器GitLab。同时也创建了一个名为git_test的仓库。现在要做的就是将远程仓库克隆下来。克隆的命令是git clone

git clone http://192.168.40.138/ai-edu/git_test.git
ログイン後にコピー

其中http://192.168.40.138/ai-edu/git_test.git 是远程仓库的地址。
当然也可以在IDEA上直接通过图形界面操作,还省去了导入项目的过程。其操作步骤是:

  1. 选中File->New->Project from Version Control->Git。如下图所示:
    Gitウェアハウスの構築とブランチ管理を完全マスター
  2. 在URL中填入远程仓库的地址,点击Clone按钮。如下图所示:
    Gitウェアハウスの構築とブランチ管理を完全マスター
    需要注意的是默认情况下只会克隆master分支,其他的分支不会被克隆下来。其他的分支需要通过git pull命令拉取,后面会详细介绍。

删除远程Git仓库

 git remote rm origin
ログイン後にコピー

查看远程分支

通过git remote命令可以查看远程仓库,origin表示远程主机。
通过git remote -v 命令可以查看远程仓库详细的信息,包括远程仓库的地址。

$ git remote -v
origin  http://192.168.40.138/ai-edu/git_test.git (fetch)origin  http://192.168.40.138/ai-edu/git_test.git (push)
ログイン後にコピー

上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。

推送分支

现在将远程仓库克隆下来了,那么该如何将当前分支上所有的本地提交推送到远程库呢?答案是通过git push命令,其语法结构是git push <remote branch> <local branch></local></remote> 其中<remote branch></remote>表示远程分支名,<local branch></local>表示本地分支名。

git push origin master
ログイン後にコピー

该语句表示将本地的master分支推送到远程的origin分支上。在实际应用中会在git push命令后面加上-u参数,就像git push -u origin master这样。这是因为如果当前分支与多个主机存在追踪关系,则可以使用 -u 参数指定一个默认主机,这样后面就可以不加任何参数使用git push。那么哪些分支该与远程分支保持一致呢?一般认为:

  1. master 分支是主分支,需要时时与远程同步
  2. dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步
  3. bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
  4. feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
    说白了就是需要团队协作的分支一定要推送到远程库,否则则不需要

创建远程分支

通过git push命令还能创建远程分支。

git push origin dev
ログイン後にコピー

假设你本地已经有了dev分支。通过上面的命令可以将dev分支推送到远程库,并创建远程的dev分支。

拉取分支

通过git pull命令可以拉取远程仓库的数据和分支信息。假设如下这个场景:你同事在他本地创建了一个dev分支,并提交到了远程库。同时你也在本地创建了一个dev库,当你push时会推送失败。结果如下图所示:

因为你同事的最新提交和你试图推送的的提交有冲突。解决的办法就是根据Git的提示,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突后,在推送。

$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.    git pull <remote> <branch>If you wish to set tracking information for this branch you can do so with:    git branch --set-upstream-to=origin/<branch> dev</branch></branch></remote>
ログイン後にコピー

git pull也失败了。原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:

关联本地分支和远程分支

$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
ログイン後にコピー

关联好本地分支和远程分支之后,在pull就能成功了。这回git pull成功,但是合并有冲突,需要手动解决,解决的方式也是在本地手动处理冲突文件,解决后,提交,在push。

删除远程分支

通过

git push origin :dev
ログイン後にコピー

命令可以删除远程dev分支。但是这时候本地的dev分支还是存在的。所以还需要通过git branch -d dev删除本地的dev分支。

查看分支

通过git branch可以查看本地分支
通过git branch -a 可以查看本地分支和远程分支。
Gitウェアハウスの構築とブランチ管理を完全マスター

版本回退

在实际开发中我们经常会碰到这样一个场景,比如:你误提交了一段有问题的代码,导致其他同事更新代码之后项目启动不了,这时候该怎么办呢?我们首先想到的就是将版本回退。回退到之前那个没有问题的版本。

  1. 通过git log 命令找到当前的仓库所有的提交日志。然后,找到你需要回退到的版本。如下图所示:
  2. 回退到上一个版本:git reset HEAD
  3. 回退到指定版本:git reset commitId 其中commitId是指定版本的版本号,比如这里将版本信息回退到b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602 这个版本。那么命令就是:
git reset b50c9bdcbf9641d33e4b531bd96dc1f27d4bf602
ログイン後にコピー

回退之后,再次通过git log查看,则最新的提交日志已经变成了hello 提交这个版本了。
当然,通过IDEA来回退则更加的简单。直接在Version Control->Log 在待回退到的版本上右键,选中Reset Current Branch to Here 即可。
Gitウェアハウスの構築とブランチ管理を完全マスター

其实回退操作的本质,就是将HEAD指针的指向要回退的那个版本上。

分支重命名

git branch -m oldname newname
ログイン後にコピー

7. 标签管理

标签管理比较简单,再此只是简单描述一下。

#创建标签 v1.0git tag v1.0#查看标签git tag#删除标签v1.0git tag -d v0.1#推送标签git push origin --tags#删除远程标签git push origin :refs/tags/v1.0
ログイン後にコピー

下面就用一张图来做一个总结吧。

Gitウェアハウスの構築とブランチ管理を完全マスター
这张图清晰的表明了Git的基本流程。

推荐学习:《Git教程

以上がGitウェアハウスの構築とブランチ管理を完全マスターの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
git
ソース:csdn.net
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート
私たちについて 免責事項 Sitemap
PHP中国語ウェブサイト:福祉オンライン PHP トレーニング,PHP 学習者の迅速な成長を支援します!