Gitプロジェクト管理研究ノート（Qianfeng教育ビデオコース）

ほとんどの情報はQianfengEducationからのものであり、個人がいくつかの変更を加えています。
侵入と削除。
対応するビデオ情報：https：//www.bilibili.com/video/BV1Mf4y117f3？p = 1＆spm_id_from = pageDriver

I.はじめに

一人の開発プロセスでは、開発の進捗状況を管理しやすくするためにバージョン管理が必要です。

複数人の開発プロセスでは、バージョン管理だけでなく、複数人の共同管理も必要です。

2.はじめに

Gitは、小規模または大規模なプロジェクトをアジャイルで効率的に処理するためのオープンソースの分散バージョン管理システムです。

Gitは、Linuxカーネルの開発管理を支援するためにLinusTorvaldsによって開発されたオープンソースのバージョン管理ソフトウェアです。

公式サイト：https：//git-scm.com/

3、Gitのインストール

3.1Gitをダウンロードする

Gitをダウンロードhttps://git-scm.com/downloads

3.2インストール

インストール、インストール場所に加えて、他は次のステップになることができます

3.3基本構成（グローバル変数の設定）

インストール後、gitのcmdウィンドウを開き、自宅を報告します

以下の情報は、コードを送信するときに使用され、各送信に記録されます。後で、誰がどの提出をしたかがわかります。

git config --global user.name "Your Name"  #用户名
git config --global user.email "[email protected]"  #邮箱
# 查看信息
git config -l

3.4テスト

テスト：cmdで実行し、gitバージョンを確認します

git version

四、建築

リポジトリ：あり隠されたディレクトリ .git内の作業領域には、このディレクトリは、作業領域が、gitのに属していない版本库、それはすべてのgitで管理するコンテンツです

一時ストレージ領域：バージョンライブラリには、次のステップで送信するファイルを保存するための一時領域が含まれています

ブランチ：リポジトリにはいくつかのブランチが含まれており、送信されたファイルはブランチに保存されます

アーキテクチャ図

ファイブ、倉庫

対応するのはディレクトリで、このディレクトリ内のすべてのファイルはgitによって管理されます。

将来的には、プロジェクトのルートディレクトリがウェアハウスとして使用される予定です。

リポジトリ内のすべてのファイルへの変更は、gitによって追跡されます。

5.1新しい倉庫

ディレクトリを選択して、次のコマンドを実行します：git init

新しい倉庫	倉庫カタログ
[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-37TmA3Vh-1613493411419）（/ Users / xwj / Library / Application Support / typora- user-images / image-20210216205341427 .png）]

5.2作業エリア

上記の例のように、git initが実行されるディレクトリが作業領域です。D：\ repo1ディレクトリが作業領域です[ .gitディレクトリは含まれません]

すべてのファイルは最初に作業領域で作成され、次にバージョン管理のためにウェアハウス（バージョンライブラリ）に保存できます。

5.3一時保管場所

一時ストレージ領域も.gitディレクトリにあります。作業領域のファイルがウェアハウスに入るときは、最初に一時ストレージ領域に入る必要があります。

5.4ブランチ

バージョン管理は、簡単に言えば、ファイルの多くのバージョンを記録することであり、ブランチはこれらのバージョンの最終的な記録場所です。

6、基本的な操作

6.1倉庫のステータスを確認する

git statusを実行して、ワークスペース内のファイルのステータスを確認します

記録されていないファイルは追跡されません
[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-ju4HiAcL-1613493411420）（http://xwjpics.gumptlu.work/qinniu_uPic/ xO3NjM.png）]

6.2一時ファイル

gitaddを実行します。ワークスペース内のすべてのファイルを一時ストレージ領域に保存します

作業領域のファイルを一時記憶領域に保存します

6.3書類の提出

git commit -m "送信の説明をここに書き込んでください"を実行します。一時ストレージ領域にあるすべてのファイルをブランチに保存します、新しいバージョンを作成する

バージョンを形成するためにドキュメントを送信する

セブン、リモート倉庫

第5章の倉庫は、実際にはローカル倉庫です。

複数の人が共同で開発する場合、全員が自分のローカル倉庫でバージョンを維持します。

ただし、重要な点は、複数の人がコードを共有してコードをマージする必要があるということです。現時点では、リモートウェアハウスが必要です。

7.1リモートウェアハウスの作業モード

リモート倉庫作業モード

7.2リモートウェアハウスの選択

github（https://github.com/）、コードクラウド（https://gitee.com/）など、選択できるリモートウェアハウスは多数あります。githubまたはコードクラウドはリモートウェアハウスではなく、gitサーバーであることに注意してください。その上にリモートウェアハウスを構築します;

これらの2つのタイプに登録して独自のテストを行うことができますが、商用プロジェクトの場合は、追加のサポートに料金を支払う必要があります。

会社は、リモートウェアハウスを独自に構築することもできます（http://qianfeng.qfjava.cn:8087/users/sign_in）。

7.3基本操作

すべての開発者は、リモートウェアハウスに直面すると、いくつかの基本的な操作に直面します。

7.3.1gitサーバーアカウントを登録する

では、コードのクラウドアカウントを登録し、ログインします。

入社後は、自社で構築したgitサーバーを利用する可能性が高いので、リーダーにアカウントを依頼することができます。

7.3.2新しいリモートウェアハウスを作成する

5kSA5g

7.3.3リモートウェアハウスをローカルに関連付ける

このドキュメントでは、ウェアハウスのhttpsプロトコルアドレスが選択されており、このアドレスはローカルgitに関連付けられています

git remote add origin [https地址\ssh地址]リモートアドレスを追加する

git remote -vローカル倉庫に現在関連付けられているアドレスを表示する

この後、ローカルの「オリジン」を使用して、リモートウェアハウスを参照できます。

ファイルをリモートウェアハウスにプッシュする

ローカルウェアハウスのコミットされたコンテンツをリモートウェアハウスにプッシュして、独自のコードを共有します。

押す
[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-RJBCBvGj-1613493411423）（http://xwjpics.gumptlu.work/qinniu_uPic/ bRdmkS.png）]

githubサーバーで表示

7.3.5リモートウェアハウスのクローンを作成する

ウェアハウスが他の誰かによって作成されており、コンテンツが必要な場合は、gitcloneを介してローカルにコピーできます。

新しいディレクトリ「repo2」を作成し、その中でgitcloneを実行します

7.3.6コードシェアリング

複数の人が共同で開発する場合、記述されたコードのgit pushはリモートウェアハウスにアップロードされます。コードをプルするには、コードのgitpullが必要です。

セーブ：誰かがローカルファイルをリモートウェアハウスにプッシュします：git push origin master

取る：重要：この時点で、相手がアップデートを取得したい場合は、プルを実行する必要があります git pull origin master

WkOGvK

7.3.7コマンドの概要

コマンド	説明
git remote add識別名（マスター）リモートアドレス	ローカルに関連付けられたリモートウェアハウス
gitプッシュ識別名マスター	ローカルウェアハウスのコンテンツをリモートウェアハウスにアップロードします
gitpull識別名マスター	リモートウェアハウスからローカルウェアハウスにコンテンツをダウンロードする
gitcloneリモートアドレス	リモートウェアハウスをローカルにコピーし、自動的にローカルウェアハウスを形成します

gitcloneとgitpullの違いは、ローカル領域が空の場合、git cloneが初めて使用され、その後の更新ごとにgitpullが使用されることです。

八、枝

8.1ブランチの概要

ブランチは、各バージョンが最終的に保存される場所です。

ブランチはタイムラインです。各gitcommitはバージョンを形成し、バージョンはブランチのコミットポイントに順番に保存されます。

ブランチは複数のコミットポイントで構成されており、ブランチには常に最新のコミットポイントを指すポインタがあります。

毎回送信される新しいバージョンの廃止されたコンテンツ/変更されていないコンテンツは、コピーするのではなく、新しいバージョンのリンクの1つのみを保持します。これは最適化方法です。

8.2支店運営

8.2.1ブランチを表示

現在のウェアハウスgitブランチのブランチを表示する

デフォルトでは、ウェアハウスにはマスターブランチのみがあります

実行する場合はgitのコミット、デフォルトはmasterブランチにバージョンを保存することです。

デフォルトではマスターブランチのみ

8.2.2ブランチを作成する

商業プロジェクトの開発中、私たちはマスターブランチでは簡単に操作できません。

私達新しい開発ブランチが作成され、このブランチにバージョンレコードが作成されます。

コードに問題がなければ、開発ブランチの成熟したコードバージョンがマスターブランチに追加されます。

開発プロセス中にバージョンを時間内に記録できること、およびマスターブランチの各コミットポイントが安定したバージョンであることを確認してください。

git branch 新分支名

*が前に付いているブランチは、現在使用されているブランチを表し、デフォルトはメインブランチです。

ブランチを作成する

8.2.3スイッチブランチ

デフォルトでは、現在使用されているブランチはマスターブランチです。

devブランチに切り替えることができ、後続のgit commitはdevブランチに新しいバージョンを作成します（コミットポイント）

git checkout 分支名

スイッチブランチ

ブランチの状況をもう一度確認してください

8.3新しいブランチの詳細

新しいブランチを作成するとき、新しいブランチにはデフォルトでどのようなコンテンツがありますか？ブランチにはどのようなコミットが含まれていますか？

8.3.1新しいブランチの初期コンテンツ

各ブランチにはポインタがあり、新しいブランチを作成するには、最初に新しいポインタを作成します。

而且新分支的指针会和当前分支指向同一个提交点。

新分支包含的提交点就是从第一个提交点到分支指针指向的提交点。

每个分支都有一个指针，新建一个分支，首先是新建一个指针

8.3.2 多分支走向

在master分支和新分支，分别进行 git add 和 git commit

分支情况如下图：

master分支未动，在dev分支增加一次commit
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bCUoDN95-1613493411426)(http://xwjpics.gumptlu.work/qinniu_uPic/JvXtbD.png)]

master分支增加一个commit，dev分支再增加一个commit

8.3.3 分支提交日志

查看分支的提交日志，进而看到当前分支中提交点的详细情况。

简略的查看 git log --oneline

详细的查看：git log

查看当前分支的提交日志

8.4 分支合并

两个分支内容的合并

git merge 分支a 当前分支合并到分支a

合并的方式有两种：快速合并和三方合并。

8.4.1 快速合并

如果分支A当前的修改，是完全基于分支B的修改而来，则B分支合并A分支，就是==移动指针即可==。

要求：主分支不动，其他分支一直更新

合并前分支状态

快速合并效果（master 合并 dev）

8.4.2 三方合并

在下图的情况下直接移动指针是不可以的，master会丢失自己原本的状态，所以需要三方合并

在不具备快速合并的条件下，会采用三方合并。

这个合并是git帮忙做的，其实我们是不用担心的

合并前，分支状态

三方合并，将`2`和`3`的更改都累加在`1`上，形成新的提交点

三方合并,它是把两个分支的最新快照（2 和 3）以及二者最近的共同祖先（1）进行三方合并，合并的结果是生成一个新的快照（并提交）

8.4.3 合并冲突

两个分支进行合并，但它们含有对同一个文件的修改，则在合并时出现冲突，git无法决断该保留改文件哪个分支的修改。

8.4.3.1 冲突演示

场景模拟如下：

master分支修改hig.txt文件

dev分支修改hig.txt

对同一个文件做了不同的修改

然后在master分支合并 dev分支

合并dev分支

此时，打开hig.txt 文件：

冲突后，git会将两个分支的内容都展示在文件中

8.4.3.2 冲突解决

出现冲突后，如要由两个开发人员当面协商，该如何取舍，为冲突文件定义最终内容。

解决方案：

保留某一方的，删除另一方的

保留双方的

但无论如何，要记得删除 <<<< ==== >>>> 这些

本质是两人协商为冲突的内容，定制出合理的内容。

根据协商，再次编辑文件

提交再次编辑后的文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-byBj3jKu-1613493411429)(http://xwjpics.gumptlu.work/qinniu_uPic/8Thl31.png)]

九、IDE关联Git（以goland为例）

9.1 关联Git

File > Settings 关联过程是自动的

此处关联是Idea可以自动完成的

9.2 创建仓库

新建项目后，将项目目录创建为git仓库

注意：要在建仓库前，设置忽略文件 “.gitignore”

作用：被忽略的文件会被版本记录忽略，版本中不包含它们。

范围：不需要和其他开发共享的文件，具体见下图。

创建仓库前，先添加忽略文件

9.3 提交-commit

创建好仓库后，做第一次提交。

sj1Kqh

9.4 创建分支

新建开发分支

点击右下角链接

9.5 上传到远程仓库(push)

请首先参照第7章，创建一个远程仓库。

要求是裸库，且建议库名和项目名同名。

9.6 复制到本地仓库(clone)

如果有建好的远程仓库，比如公司内已经在用的仓库，或者github，码云上的一些公开仓库，

可以将远程仓库的项目复制到本地使用。

9.7 更新本地项目

如果远程仓库有更新，则你的本地项目也需要一起更新。

9.8 冲突解决

合并分支时，如果出现冲突，则需要解决冲突。

当远端的文件与本地尚未上传远端的文件不同时，在本地拉取更新时就会造成冲突。

冲突出现，弹窗中可以选择如下

两人协商保留什么代码然后修改即可

也可以直接修改冲突文件，然后commit即可

十、多人协同开发

多人开发协同，git操作

10.1 项目管理员( 项目经理 )

1> 由管理员负责创建一个远程库，初始的库中什么也没有，为裸库。库的名称建议和项目同名

2> 管理员会在idea中创建一个初始项目,其中包含.gitignore文件。

并在项目根目录下建立本地库。并建立 dev分支。

3> 管理员将本地库上传到远程库

4> 将其他开发人员拉入远程库的开发成员列表中，使得其他开发人员可以访问该远程库。

10.2 开发人员

初始化：在idea中clone 远程库，获得项目。会建立本地库

その後の開発は、devブランチで実行する必要があります。関数を開発してテストに合格したら、それをローカルのdevブランチにコミットしてから、リモートのdevブランチにアップロードします。

プロジェクトのコンテンツを更新する必要がある場合は、プルを使用してリモートウェアハウスからコンテンツをプルします。

注意：複数人のコラボレーションの場合、リモートライブラリにプッシュする前に、最初にプルを実行します、1つは、最新のリモートコンテンツをローカルにマージすることであり、もう1つは、ローカルコンテンツがリモートコンテンツと競合するかどうかを確認することです。

その後の開発では、機能的なタスクを1つずつ受け取り、往復操作2>、3>、4>は単なる操作です。

11、古典的な問題

プッシュにhttpsプロトコルを使用している場合、Code Cloudを使用したがパスワードが変更されていると、この時点でエラーが報告されます

以前のアカウント資格情報は新しいgitアカウント資格情報と互換性がないため、次の問題が発生します。

httpsプロトコルを使用してエラーを報告する

解決策：コントロールパネルの「資格情報マネージャー」対応する資格情報を削除すると、パスワードを再度使用するときにパスワードを再入力するように求められます。

以前のコードクラウド証明書を削除してから、もう一度プッシュします