gitの使い方チュートリアル

Git とは

# 公式用語: Git は、以下のようなさまざまなタスクを迅速かつ効率的に処理するように設計された、無料のオープンソースの分散バージョン管理システムです。小規模から大規模まで大規模プロジェクトまで。

すべてのファイル変更を自動的に記録できるほか、同僚と共同で編集できるため、大量の類似ファイルを自分で管理する必要がなく、ファイルをやり取りする必要もありません。 。特定の変更を確認したい場合は、ソフトウェアを確認するだけで済みます。

Git を学ぶべき理由

面接で聞かれることがあります。面接にも対応できる。

多くの企業は、開発中に Git を使用してプロジェクトを処理しています。今学ばなければ、必ず後で学ばなければなりません。

私の意見では、Git は今日のすべてのプログラマーが習得しなければならないものであり、将来同僚とプロジェクトを開発するためにも Git を使用する必要があります。Git コマンドに習熟すると開発効率が向上します。

関連提案:
1.Git の使い方(グラフィック、テキスト、ビデオ)
2.Git と Github の違い(グラフィック、テキスト、ビデオ) video)

Git のインストール

Windows

公式 Web サイトから直接ダウンロードします。ダウンロードが完了したら、ファイルを右クリックし、Git Bash Here があればインストールは成功です。インストール後、コマンド ラインで次のように入力する必要もあります:

$git config --global user.name"你的名字"
$git config --global user.email"你的邮箱"

global はグローバルを意味します。このマシン上のすべての Git リポジトリはこの構成を使用します。個々のリポジトリが他の名前と電子メール アドレスを使用できるようにします。

Mac

Mac も上記の手順に従って Windows と同様にインストールできます。

Xcode を AppStore から直接インストールすることもできます。Xcode は Git を統合しますが、デフォルトではインストールされません。Xcode を実行し、メニュー「Xcode」->「Preferences」を選択し、「Downloads」を見つける必要があります。ポップアップウィンドウで「コマンドラインツール」を選択し、「インストール」をクリックするとインストールが完了します。

倉庫

ローカル倉庫はリモート倉庫用です。ローカルウェアハウス = ワークスペースバージョンエリア。

ワークスペースは、ディスク上のファイルのコレクションです。

バージョン領域 (バージョン ライブラリ) は .git ファイルです。

リポジトリ = ステージング領域 (ステージ) ブランチ (マスター) ポインター 先頭。

私が最も頻繁に使用する git コマンド (github への送信) を例として取り上げます。

git init 当初、ローカル ウェアハウスには、最も一般的な動作状態であるワークスペースのみが含まれていました。このとき、git init とは、ローカル領域に .git ファイルが作成され、バージョン領域が確立されることを意味します。

git add . は、ワークスペース内のすべてのファイルをバージョン領域の一時記憶領域に送信することを意味します。

もちろん、 git add ./xxx/ を使用して、ステージング領域に 1 つずつ追加することもできます。

git commit -m "xxx" 一時記憶領域内のすべてのファイルをウェアハウス領域に送信します。一時記憶領域は空になります。

git リモート追加オリジン https://github.com/name/name_cangku.git は、ローカル ウェアハウスとリモート ウェアハウスを接続します。

git Push -u Origin master ウェアハウスエリアのファイルをリモートウェアハウスに送信します。

送信後、ワークスペースに何も変更を加えなければ、ワークスペースは「クリーン」な状態になります。 「コミットするものは何もありません。作業ツリーはクリーンです」というメッセージが表示されます。

GitHub に送信する

以前、git コマンドに詳しくなかったときは、プロジェクトを GitHub に送信するときに、Web ページからファイルを直接取得して、それらを提出してください。ちょっと恥ずかしい。

git init. 初期化とは、このファイルを Git で管理できるウェアハウスに変えることを意味します。初期化後、隠しファイルを開くと、.git ファイルがあることがわかります。

git add . その後のドットは、すべてのファイルが一時記憶領域に送信されることを示します。

git add ./readme.md/ は、このファイルの下にある readme.md ファイルを一時記憶領域に送信することを意味します。

git commit -m 「何かコメントしますか?」 git commit は、一時保存領域にあるすべてのファイルをローカル ウェアハウスに送信することを意味します。 -m の後にコメントが続きます。

git リモート追加オリジン https://github.com/name/name_cangku.git は、ローカル ウェアハウスを GitHub 上のリモート ウェアハウスに接続することを意味します。接続する必要があるのは一度だけであり、今後送信するときにこのコマンドを使用する必要はありません。 name は Github 名、name_cangku はウェアハウス名です。最後の .git を見逃さないように注意してください。だって、私はこうしてやって来て、たくさん回り道をしてきました。 GitHub 上に新しいウェアハウスを作成する方法については、インターネット上に多くのチュートリアルがあるため、ここでは詳しく説明しません。

git push -u origin master 把本地仓库提交到远程仓库。(最后一步)在你的远程仓库上刷新一下就可以看到你提交的文件了。

最后提到的是，在git commit -m ""之前，可以重复git add到暂存区。但是git commit会把你之前存放在暂存区的全部文件一次性全部提交到本地仓库。

版本的回溯与前进

提交一个文件，有时候我们会提交很多次，在提交历史中，这样就产生了不同的版本。每次提交，Git会把他们串成一条时间线。如何回溯到我们提交的上一个版本，用git reset --hard + 版本号即可。版本号可以用git log来查看，每一次的版本都会产生不一样的版本号。

回溯之后，git log查看一下发现离我们最近的那个版本已经不见了。但是我还想要前进到最近的版本应该如何？只要git reset --hard + 版本号就行。退一步来讲，虽然我们可以通过git reset --hard + 版本号,靠记住版本号来可以在不同的版本之间来回穿梭。

但是,有时候把版本号弄丢了怎么办？git reflog帮你记录了每一次的命令，这样就可以找到版本号了，这样你又可以通过git reset来版本穿梭了。

撤销

场景1：在工作区时，你修改了一个东西，你想撤销修改，git checkout -- file。廖雪峰老师指出撤销修改就回到和版本库一模一样的状态，即用版本库里的版本替换工作区的版本。

场景2：你修改了一个内容，并且已经git add到暂存区了。想撤销怎么办？回溯版本，git reset --hard + 版本号,再git checkout -- file,替换工作区的版本。

场景3：你修改了一个内容，并且已经git commit到了master。跟场景2一样，版本回溯，再进行撤销。

删除

如果你git add一个文件到暂存区，然后在工作区又把文件删除了，Git会知道你删除了文件。如果你要把版本库里的文件删除，git rm 并且git commit -m "xxx".

如果你误删了工作区的文件，怎么办？使用撤销命令，git checkout --就可以。这再次证明了撤销命令其实就是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

分支

分支，就像平行宇宙，你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。用 Git 和 Github 提高效率的 10 个技巧！这篇也推荐看下。

创建与合并分支

在没有其他分支插进来时，只有一个master主分支。每次你git push -u origin master 提交就是增加一条时间轴，master也会跟着移动。

创建一个other的分支，通过other提交，虽然时间轴向前走了，但是主分支master还在原来的位置。

理论分析完，看一下命令怎么写。

创建分支other,切换到other分支。

gitbranch other
gitcheckout other

查看当前所有分支

gitbranch
* othermaster

当前的分支会有一个*

用other提交

gitadd ./xxx/
git commit -m"xxx"

other分支完成，切换回master

git checkoutmaster

此时，master分支上并没有other的文件，因为分支还没有合并。

合并分支

gitmergeother

合并完成之后，就可以在master分支上查看到文件了。

删除other分支

gitbranch -d other

我由此想到，在以后工作中，应该是一个开放小组共同开发一个项目，组长会创建很多分支，每一个分支可以交给一个人去开发某一个功能，一个小组共同开发而且不会相互干扰。谁的功能完成了，可以由组长合并一下完成了的分支。哦，完美！

解决合并分支问题

このような状況があったとします。other ブランチはコミットされていますが、この時点ではポインターはマスターに戻っており、マスターはマージされていませんが、 git add/commitが提出されます。このようにして競合が発生し、メインブランチのマスターファイルの内容が他のブランチの内容と異なってしまいます。合併できない！したがって、ファイルの内容を変更して一貫性を持たせます。

git add git commit コミット。

ブランチがマージされます。

git log --graph ブランチ マージ グラフの表示

git Branch -d other ブランチを削除するとタスクは終了します。

ブランチ管理戦略

git merge --no-ff other 早送りモードを無効にします。早送りモードを使用すると、ブランチを削除するとブランチ履歴情報が失われるためです。 。バカでも一目でわかる超詳しいGit実践チュートリアル！

バグ ブランチ

作業内のすべてのバグは、新しい一時ブランチを通じて修正できます。修復後、ブランチをマージし、一時ブランチを削除します。しかし、職場に支店がある場合、上司は別の支店のバグを修正するように依頼するでしょう。

現在作業中のブランチを保存し、git stash を使用して現在の作業サイトを「保存」し、後で復元してから作業を続ける必要があります。バグを解決したら、git checkout other を実行し、自分のブランチに戻ります。 git stash list を使用して、「隠した」作業がどこに消えたかを確認します。

この時点で、作業を再開する必要があります:

git stash apply は復元しますが、stash コンテンツは削除しません。git stash Drop は stash コンテンツを削除します。

git stash Pop が復元されると、stash コンテンツも削除されます。

現時点では、git stash list を使用して表示すると、stash コンテンツは表示されません。

要約: バグを修正するときは、新しいバグ ブランチを作成して修正し、それをマージし、最後に削除します。作業が完了していない場合は、最初に作業を git stash します。バグを修正したら、git stash Pop を実行して作業サイトに戻ります。

ブランチの削除

git ブランチ -d ブランチは、Git がマージされていないブランチを保護するため、削除に失敗する可能性があります。

git ブランチ -D ブランチは、マージされていないブランチを強制的に削除して破棄します。

複数のコラボレーション

git remote リモート ライブラリの情報を表示します。オリジンが表示されます。リモート ウェアハウスのデフォルト名はoriginです。

git remote -v は詳細を表示します。詳細情報

git Push -u Origin Master は、マスター ブランチをオリジン リモート ウェアハウスにプッシュします。

git Push -uorigin other other をオリジンのリモート ウェアハウスにプッシュします。

ブランチの取得

上の図の競合が発生した場合、

git pull は最新のものをプルします。 commit from リモート ウェアハウスから取得し、ローカルでマージし、競合を解決します。 git pull を実行するとき

#git pull も失敗する場合は、ブランチ間のリンクも指定する必要があります。Git は、この手順で何をすべきかを通知します。次に、もう一度 git pull します。

複数人によるコラボレーションの作業モードは、通常次のとおりです:

まず、git Pushorigin

を使用して独自の変更をプッシュしてみます。

Rebase

タグ管理

git tag タグ、デフォルトは HEAD です。たとえば、 git tag v1.0

デフォルトのタグは最新のコミットに配置されます。以前のコミットにタグを付けたい場合は、git log を使用して履歴コミットのコミット ID を見つけます。

コミット ID が du2n2d9 の場合は、git tag v1.0 du2n2d9 を実行して、このバージョンを v1.0 としてマークします。ラベル。

git tag すべてのタグを表示すると、tag

タグの過去のバージョンが時系列順ではなく、アルファベット順にリストされていることがわかります。

git show タグ情報を表示します。

git tag -a -m ""、説明付きのタグを作成します。 -a はラベル名を指定し、-m は説明テキストを指定します。 show を使用して手順を表示します。

操作タグ

git tag -d v1.0 タグを削除します。作成されたタグはローカルにのみ保存され、リモートに自動的にプッシュされないためです。したがって、タイプを間違えたタグはローカルで安全に削除できます。

git Push Origin タグをリモートにプッシュします

git Push Origin --tags リモートにプッシュされていないすべてのローカル タグを一度にプッシュします

タグがリモートにプッシュされた場合。 git tag -d v1.0 は、まずローカル タグ v1.0 を削除します。 git Push Origin :refs/tags/v1.0リモート タグ v1.0

#Git をカスタマイズして、Git config --global color.ui true を表示させます。色を指定すると、コマンド出力がより目を引くようになります。特殊ファイルを無視する .gitignore ファイルを作成し、無視する必要があるファイル名を入力します。 Git はこれらのファイルを自動的に無視します。私も研究中にこのような問題に遭遇したことがありますが、たとえば、node_modules ファイルは無視できます。

ファイルの原則を無視: オペレーティング システムによって自動的に生成されたサムネイルなどのファイルを無視し、コンパイルによって生成された中間ファイルや実行可能ファイルなどを無視します。つまり、ファイルが別のファイルによって自動的に生成された場合です。 Java コンパイルによって生成された .class ファイルなど、自動的に生成されたファイルをリポジトリに置く必要はありません。パスワードを保存する構成ファイルなど、機密情報を含む独自の構成ファイルは無視してください。

無視されたファイルを強制的に送信します。 git add -f

git check-ignore -v Git がファイルを無視する理由を確認します。

Git コマンドにエイリアスを割り当てます。これは少し面倒です。将来 git rebase に入りたいときは、「ニックネーム」を付けて、git nb と呼びます。将来的には、git rebase の代わりに git nb を使用できるようになります。

git config --global user.name "your name" を使用すると、すべての Git リポジトリがあなたの名前をバインドできます# git config --global user.email "あなたの電子メール" すべての Git リポジトリに電子メールをバインドさせます

以上がgitの使い方チュートリアルの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。