Git バージョン管理学習ガイドを要約して整理する

この記事では、Git に関する関連知識を提供します。主にバージョン管理の知識ポイントがまとめられています。Git バージョン管理スタディ ガイドを見てみましょう。皆様のお役に立てれば幸いです。 。

# 推奨学習: 「

Git 学習チュートリアル 」
#バージョン管理の起源

今日のソフトウェア プロジェクトは通常、研究開発チームによって分析、設計、コーディング、保守、テストが行​​われます。

• チーム開発では次の問題を解決する必要があります:
• 複数のバージョンのバックアップはスペースを消費します時間がかかります。
  • 以前の正しいバージョンに戻すのが困難です。
  • コードの競合を解決するのが困難です。
  • 問題のあるコードの変更時刻を追跡するのが困難です。 code
  • 権限を実行できない
  • プロジェクトのバージョンリリースの管理が難しい
  上記の問題を解決するためにソースコード管理ツールが登場しました
• リビジョン管理 (リビジョン管理)

は、プロジェクト ブループリントを管理するための標準的な方法であり、プロジェクト ブループリントの誕生から完成までのプロセスを追跡できます。これは、将来特定のバージョンのリビジョンを確認できるように、複数のファイルの内容の変更を記録するシステムです。

• チーム開発の場合、バージョン管理の使用は必須です。
  • 単独で開発している場合は、今すぐバージョン管理の使用を開始することを強くお勧めします!

バージョン管理を使用できます:

• 既存の作業にダメージを与えません
  • 作業負荷は増加しません
  ##新しい機能拡張を追加する際の作業が容易になります
  ##一般的なバージョン管理ツール
#CVS はバージョン管理への扉を開きます

#CVS は 1990 年に誕生し、古くはソース コード管理ツールの主流でした

---

SVN 集中型バージョン管理の王様
• SVN: Subversion とも呼ばれる、CVS の後継であり、
  • 集中型
  ソース コード管理ツールです。以前はほとんどのオープンソース ソフトウェアのコード管理ツール (Google コード) でしたが、ここ数年では国内のソフトウェア会社で最もよく使用されています
• GIT の素晴らしい成果分散バージョン管理
  • GIT: 分散型
  ソースコード管理ツール 現在、ほぼすべての国内企業が SVN から GIT
• への移行を完了しています。
  • ##集中ソース コード管理

---

分散ソース コード管理

• 
  ##分散型と集中型の最大の違いは次のとおりです。

• 集中型では、開発者はコードをサーバーにのみ送信できますが、分散型では、開発者はローカルで送信できます

  
  集中モードでは、リモート サーバーにコード データベースのみが存在します。分散モードでは、各開発者のマシンにコード データベースが存在します。

• SVN (集中フォーミュラ)

  • GIT (分散)

Git と SVN の単純な比較

• 速度
  • 多くの場合、git は SVN
  ## よりもはるかに高速です。
#構造
• SVNは集中管理、gitは分散管理
その他
• SVNはブランチを使うのが不器用ですが、gitは簡単にできますブランチは無制限です。
  • SVN が正しく動作するにはインターネットに接続する必要があります。git はローカル バージョン管理をサポートしています。
  • 古いバージョンの SVN は各ディレクトリに .svn を配置しますが、git は .svn のみを配置します。各ディレクトリに .svn があり、ルート ディレクトリには .git があります

##GIT の概要

---

GIT は無料のオープン ソース

distributed
• 大小を問わずあらゆるプロジェクトを処理するためのバージョン管理システム 機敏かつ効率的に ##世界中のすべての分散バージョン管理ツールの中で、git は最も速く、最もシンプルです。最も人気のある
は、Linux の父である Linus の 2 番目の偉大な作品です。2005 年に、BitKeeper ソフトウェア会社は、Linux コミュニティへの無償使用権を停止しました。
• Linux カーネルの開発 (ソース コードの管理) を支援するために、Linus は分散バージョン管理ツールを自分で開発する必要があり、Git が誕生しました。
• ##GIT の動作原理

GIT をよく学びたい場合は、まず GIT の動作原理を理解する必要があります

---

作業ディレクトリ:

ウェアハウスフォルダー内
• .git ディレクトリ以外の内容
• #Repository (リポジトリ):.git ディレクトリ、バージョン情報の保存と記録に使用 Repository リポジトリ内の
staga:
• リポジトリ内の
  ブランチ (マスター):
  • git によって自動的に作成された最初のブランチ バージョン * *ライブラリ内の HEAD ポインタ:** は、現在のブランチを指すために使用されます
  • git add および git commit の名前付け効果
git add: ファイルの変更をバッファー領域に追加します

---

• ##git commit: バッファー領域のすべての内容を現在の HEAD ポインターが指すブランチに送信します
  • 
  • GIT 利用環境
  複数人開発で
共有バージョンライブラリが必要な場合

、一人開発のための初期化

---

ローカル ライブラリ

が使用できます

共有バージョン ライブラリの形式:
• ローカル共有ライブラリ:フォルダー/U ディスク/ハードディスクリモート共有ライブラリ: 独自の git サーバーを構築するか、サードパーティのプラットフォーム (github/oschina など) でホストします。
• 一人で開発するかどうかまたは複数人による開発の場合、クライアントはコマンド ラインまたはグラフィカル インターフェイス git
  • #GIT Command-Personal Development
• # を使用して使用できます。 #git help
: git コマンド ヘルプ マニュアル

---

他の手順を表示: git help 他の手順

• git init

  : ウェアハウスの初期化 (個人ウェアハウス)
  • ウェアハウス ファイル ディレクトリ

HEAD:	指向当前分支的一个提交
description:	项目的描述信息
config:	项目的配置信息
info/:	里面有一个exclude文件，指定本项目要忽略的文件
objects/:	Git对象库(commit/tree/blob/tag)
refs/:	标识每个分支指向哪个提交
hooks/:	默认的hook脚本

GIT 設定構成情報

Configureユーザー名:
• git config user.name "Username"
(変更記録の追跡用)

電子メールの設定:

git config user.email "Email"

(間の通信用)複数の開発者)

• git config -l: 構成情報の表示
#git config -e
• : 構成情報の編集
• git status: ファイルのステータスを確認します
• 特定のファイルのステータスを確認します:git status ファイル名

現在のパスにあるすべてのファイルのステータスを確認します:

git status

• #git add: ファイルを次の場所に保存します。ワークスペースをバッファ領域に保存します
• 特定のファイルをバッファ領域に保存します: git add file name

現在のパスにあるすべてのファイルをバッファに保存しますエリア:

git add .

(最後にドットがあることに注意してください。)

• git commit: ファイルを送信します。現在のブランチのバッファ領域にある
• ファイルをブランチに送信します: git commit -m "Comment" file name

すべてのファイルを次のブランチに保存します。ブランチへの現在のパス:

git commit -m "Comment"

• git log: ファイルの変更ログを表示します。
• 特定のファイルの変更ログを表示します:git ログ ファイル名

現在のパスにあるすべてのファイルの変更ログを表示します:

git log

単純なログ情報を 1 行で表示: git log ––pretty=oneline

• 最新 N 個の変更を表示: git log –N (N は整数)
• git diff : ファイルへの最新の変更を表示します
• Viewファイルへの最新の変更:git diff ファイル名

現在のパスにあるすべてのファイルを表示します。最新の変更:

git diff

##git reflog
• : ブランチ参照レコードを表示します (すべてのバージョン番号を表示できます)
• git rm:ファイル (リポジトリと同期するには、削除後にコミット操作が必要です)

gitリセット: バージョンのロールバック (--hard パラメーター、git を追加することをお勧めします)無制限の後悔をサポートします)

• 回退到上一个版本：git reset ––hard HEAD^
• 回退到上上一个版本：git reset ––hard HEAD^^
• 回退到上N个版本：git reset ––hard HEAD~N（N是一个整数）
• 回退到任意一个版本：git reset ––hard 版本号（版本号用7位即可）

Git忽略提交规则 - .gitignore配置

• 别看了, 你想要的都在这企业开发专用链接

#               表示此为注释,将被Git忽略*.a             表示忽略所有 .a 结尾的文件!lib.a          表示但lib.a除外/TODO           表示仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
build/          表示忽略 build/目录下的所有文件，过滤整个build文件夹；
doc/*.txt       表示会忽略doc/notes.txt但不包括 doc/server/arch.txt
 
bin/:           表示忽略当前路径下的bin文件夹，该文件夹下的所有内容都会被忽略，不忽略 bin 文件
/bin:           表示忽略根目录下的bin文件
/*.c:           表示忽略cat.c，不忽略 build/cat.c
debug/*.obj:    表示忽略debug/io.obj，不忽略 debug/common/io.obj和tools/debug/io.obj
**/foo:         表示忽略/foo,a/foo,a/b/foo等
a/**/b:         表示忽略a/b, a/x/b,a/x/y/b等!/bin/run.sh    表示不忽略bin目录下的run.sh文件*.log:          表示忽略所有 .log 文件
config.php:     表示忽略当前路径的 config.php 文件 
/mtk/           表示过滤整个文件夹*.zip           表示过滤所有.zip文件/mtk/do.c       表示过滤某个具体文件
 
被过滤掉的文件就不会出现在git仓库中（gitlab或github）了，当然本地库中还有，只是push的时候不会上传。
 
需要注意的是，gitignore还可以指定要将哪些文件添加到版本管理中，如下：!*.zip!/mtk/one.txt
 
唯一的区别就是规则开头多了一个感叹号，Git会将满足这类规则的文件添加到版本管理中。为什么要有两种规则呢？
想象一个场景：假如我们只需要管理/mtk/目录中的one.txt文件，这个目录中的其他文件都不需要管理，那么.gitignore规则应写为：：/mtk/*
!/mtk/one.txt
 
假设我们只有过滤规则，而没有添加规则，那么我们就需要把/mtk/目录下除了one.txt以外的所有文件都写出来！
注意上面的/mtk/*不能写为/mtk/，否则父目录被前面的规则排除掉了，one.txt文件虽然加了!过滤规则，也不会生效！
 
----------------------------------------------------------------------------------
还有一些规则如下：
fd1/*
说明：忽略目录 fd1 下的全部内容；注意，不管是根目录下的 /fd1/ 目录，还是某个子目录 /child/fd1/ 目录，都会被忽略；
 
/fd1/*
说明：忽略根目录下的 /fd1/ 目录的全部内容；
 
/*
!.gitignore
!/fw/ 
/fw/*
!/fw/bin/
!/fw/sf/
说明：忽略全部内容，但是不忽略 .gitignore 文件、根目录下的 /fw/bin/ 和 /fw/sf/ 目录；注意要先对bin/的父目录使用!规则，使其不被排除。

---

GIT命令-团队开发

• git init --bare : 仓库初始化(共享仓库)
  • 注意: 不要直接在共享仓库中编写代码
• git clone：下载远程仓库到本地
  • 下载远程仓库到当前路径：git clone 仓库的URL
  • 下载远程仓库到特定路径：git clone 仓库的URL 存放仓库的路径
• git pull：下载远程仓库的最新信息到本地仓库
• git push：将本地的仓库信息推送到远程仓库
  • 提交时如果远程仓库有其它人提交的最新代码, 必须先pull, 再提交
• 冲突解决:
  • 当多个人同时修改了同一个文件时, 后提交的需要先从服务器pull代码到问题, 手动解决完冲突之后再push到远程服务器

<<<<<<< HEAD
	你本地的新增的代码=======
	服务器上和你冲突的代码>>>>>>> e9609de28b65bf97539f94c6458cdebdf2711c9f

---

GIT经典协同模型

• 中心仓库：包含master和develop两个分支

• 分支分类

  • 主要分支：master和develop分支
  • 支持性分支：特性分支，发布分支，热补丁分支

• 对于商业级项目，真正开发过程中都是基于develop分支进行的，develop分支是开发主线！

• master分支中，只存放相对稳定的分支，例如：0.1版本, 0.2版本

• 在实际产品开发中，需要“规划版本”，例如：将100个功能规划到5个不同的版本上

• 发现bug，要基于“上一个最稳定的版本”进行修复，这是热补丁分支存在的意义！

• 理解清楚版本管理分支的特性，是迭代式开发的重要基础！
  

• git branch : 查看所有分支

• git branch 分支名称 : 创建分支

• 新创建的分支中的内容和master分支中的内容一样

• git checkout 分支名称 : 切换到指定分支
• git merge 分支名称 : 合并分支
  • 将当前所在分支和指定名称分支进行合并
• git branch -d 分支名称 : 删除指定分支

• 不能在当前分支中删除自己

---

使用GIT我们应该

• 经常更新：降低冲突的可能性
• 提交前需在本机测试通过：降低将问题代码传到版本库
• 提交时一定写备注：方便其他员工查看和自己以后回顾
• 对于不需要提交的文件不要提交到版本库

提示:

• 各提出前に更新する
• 毎日退社前にその日にコンパイルしたコードを提出する
• 毎日職場で最初に行うことは、次のコードを更新することです。前日

---

GITHUB USING

• 1. GitHub アカウントを登録します
  • 
##2.GitHub にログインします
• • 
3. ウェアハウス
• • をクリックします
4. 新しいウェアハウスを作成します
• • 
5. 新しいウェアハウスはダウンロードできますが、送信するにはアカウントが必要です
• 6. SSH キーの設定
• 6.1 git コマンド ライン ツールを開きます
  • コマンドを入力します
  • ssh-keygen -t rsa -b 4096 -C " your_email@example.com"
  • 
  6.2 生成された公開キーをコピーします
  • 
  • 
  6.3 生成された SSH キーを GitHub に追加します。
  • 
  • 
  • ##6.4 かどうかをテストします。構成は成功しましたssh -T git@github.com
  • 後で表示される場合: こんにちは ****! 認証は成功しましたが、GitHub はシェル アクセスを提供しません。成功の証明
  • #7. SSH キー操作を使用する GitHub
• • 
  oschina use

---

方法はGitHubと同じです

推奨学習:「
• Git Tutorial
」

以上がGit バージョン管理学習ガイドを要約して整理するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。