高度なGitチュートリアル

リモートリポジトリを介してプロジェクトをデプロイすると、プロジェクトのあらゆる部分を柔軟に管理できます。バグ修正、機能の更新、ファイルの削除、チームワーク、オープンソースの貢献、コードのデプロイなどが、Gitに関する深い知識を持ってすぐに利用できるようになりました。

それで、あなたはGitを使っていますが、もっと知りたいですか?プロジェクトのバージョン管理を簡単にする、より高度なGitのヒントをいくつか紹介します。

Gitブランチ

Gitブランチは、マスターブランチに直接プッシュすることを防ぎます。開発者のチームでプロジェクトを管理する場合に役立ちます。必要な数のGitブランチを作成し、後でそれらをマスターブランチにマージできます。

Gitブランチを作成する

Gitブランチを作成するには、次を使用します。

 git branch branch_name

Gitブランチに切り替えます

チェックアウトを使用してGitブランチに切り替えます。

 git checkout branch_name

ブランチに切り替えた後、 git add–allを使用して変更をステージングできます。次に、 git commit -m "commitname"コマンドを使用してそれらをコミットします。

ブランチとマスターを比較する

gitdiffコマンドを使用します。

 git diff master..branch_name

特定のファイルを比較するには:

 git diff master..testb -- main.html

2つのブランチを比較することは、ブランチをマスターと比較する方法に似ています。

 git diff branch1..branch2

2つのブランチ間の特定のファイルの違いを確認するには:

 git diff branch1..branch2 -- main.html

変更をリモートブランチにプッシュする

別の開発者に、ローカルブランチのファイルに加えた変更を、ライブにプッシュする前に確認してもらいたい場合があります。ローカルのGitブランチをリモートレプリカに移動して、外観を確認できるようにすることをお勧めします。

以前にchangesという名前のローカルブランチを作成したと仮定しましょう。そのローカルブランチに切り替えて、必要なすべてのファイルを調整してから、それらをステージングしてそのブランチにコミットすることができます。

次に、これらの変更をリモートバージョンのブランチにプッシュできます。

 git push origin changes

プルリクエストを使用してリモートブランチをマスターとマージする

そのため、別のプログラマーがリモートブランチの変更を監査しました( changes )。しかし、それをマスターブランチとマージして、ライブでプッシュしたいとします。

リモートブランチはローカルGitブランチの名前を継承することに注意してください(変更)。変更をマージする方法は次のとおりです。

マスターブランチに切り替えます。

 git checkout master

ブランチの原点またはHEADをプルして(変更)、マスターブランチとマージします。

 git pull origin changes

このマージをライブでマスターブランチにプッシュします。

 git push origin master

代わりにGitマージを使用する

mergeコマンドを使用してブランチをマスターとマージするには:

マスターブランチに移行します。

 git checkout master

それをブランチとマージします変更):

 git merge changes

次に、マージをライブでマスターブランチにプッシュします。

 git push origin master

変更をブランチの名前に置き換えるようにしてください。

マージが成功したら、ブランチが不要になった場合は、ローカルおよびリモートでブランチを削除できます。

関連: Gitでブランチの名前を変更する方法

Git Rebase

コミットが古いブランチが複数ある場合は、それらのブランチのヘッド/参照をリベースまたはリフォーカスして、更新されたブランチのヘッド/参照を継承できます。

したがって、リベースは、一部のブランチを現在のブランチのベースで更新する必要がある場合に役立ちます。

ただし、リベースはワークフロー全体を混乱させる可能性があるため、特にチームで作業している場合は、頻繁に行う必要はありません。しかし、一人で作業していて、ワークフローとブランチに精通している場合、リベースをどこでどのように使用するかを知っていれば、リベースが大混乱を引き起こすことはありません。

たとえば、2つのブランチがあるとします。 branch1とbranch2。これで、しばらくの間、branch1に変更を加えていません。ただし、最近を含め、常にbranch2に変更をコミットします。

そこで、フローと一緒にbranch1を実行することにしました。したがって、branch1をbranch2にリベースするということは、branch1に、以前のコミットを無視し、branch2に対して行われた最近のコミットを継承するように指示していることを意味します。

これを行う方法は次のとおりです。

放棄されたブランチ(branch1)に切り替えます。

 git checkout branch1

次に、branch1を更新されたbranch2にリベースします。

 git rebase branch2

Gitスカッシュ

Gitスカッシュを使用すると、複数のコミットを1つにマージできます。 1回の更新でgitcommitを何度も実行する場合に役立ちます。実用的な例は、単一の機能の各バグ修正またはコードリファクタリングに個別のコミットがある場合です。

しかし、それらはすべて同じ目的を持っているので、付随するものと一緒にHEADコミットをプッシュしたくないかもしれません。推奨されるアプローチは、コミットを追跡するときの混乱を避けるために、それらを1つに押しつぶすことです。

コミットを潰す最良の方法は、インタラクティブなリベースモードを使用することです。これをよりよく理解するには、以下の例を見てください。

この例では、5つのバグ修正があると想定しています。そして、それらのそれぞれにコミットがあります。これらの5つのコミットを1つにまとめる方法は次のとおりです。

git reflogを実行して、コミットのハッシュコードを表示します。

 git reflog

この場合の結果は次のとおりです。

今、あなたの目的は、最初の修正から5番目の修正まで、最後の5つのコミットを潰すことです。

これを行うには、最初の修正0a83962 )のすぐ下にあるコミットのハッシュコードをコピーします。次に、 Qを押してreflogを終了します

次に、そのハッシュでgit rebase–interactiveを実行します。

 git rebase --interactive 0a83962

次に、Gitは次のようなインタラクティブなリベースファイルを開きます。

最初の修正を除いてコミットを潰すには、他の各コミットpicksに置き換えます

このファイルを保存して閉じます。

次に、押しつぶされたコミットの名前を変更するための別のファイルが開きます。

それらをクリーンアップし、押しつぶされたコミットの優先名を​​入力します。

そのファイルを保存します。次にそれを閉じると、ターミナルに成功メッセージが表示されます。

注:対話型ファイルは端末内で開く場合があります。ただし、Windowsを使用している場合は、押しつぶしを簡単にするために、ターミナルでファイルをお気に入りのテキストエディタでグローバルに開くように強制することをお勧めします。

これを行うには、コマンドラインを開いて次のコマンドを実行します。

 git config --global core.editor "'path to choice text editor' -n -w"

GitフォークとGitクローン

フォークとクローン作成は、Gitの2つの異なる用語です。リポジトリはすでに存在しているため、フォークすることはできません。ただし、他の人のリポジトリをフォークして、後でクローンを作成することはできます。

リポジトリをフォークするということは、誰かのリポジトリのコピーを取得して自分のものにすることを意味します。そのリポジトリのコピーを取得したら、ローカル変更用のgitリポジトリと同じようにクローンを作成できます。

GitHubでリモートリポジトリのクローン作成し、ローカルディレクトリへのダウンロードを開始する方法は次のとおりです。

 git clone https://github.com/username/repository_name.git/

ファイルをデフォルトの状態に復元する

最後のコミット後にファイル内の変更をクリアしたい場合は、 gitrestoreコマンドを使用できます。

 git restore filename

コミットを修正する

ステージング中に一部のファイルに変更を加えるのを忘れた場合は、前のコミットにフォールバックできます。

忘れたファイルに変更を加えます。次に、 git amendを使用してコミットを確認します。

 git add file_forgotten
git commit --amend

ファイルのステージングを解除する

git rmコマンドを使用して、コミット用にステージングした特定のファイルを削除できます。

 git rm --cached filename

一度に複数のファイルを削除することもできます。

 git rm --cached file1 file2 file3 file4

免除するファイルには、関連するファイル拡張子を忘れずに追加してください。たとえば、プレーンテキストファイルはfilename.txtである必要があります

関連: Gitをクリーンアップして追跡されていないファイルを削除する方法

Gitリセット

コミットのためにステージングしたすべてのファイルを一度に削除する場合は、 gitresetを使用すると便利です。

 git reset

ただし、Git reset HEADは、ブランチのHEADを作業ツリー内の特定のコミットにポイントします。たとえば、現在のコミットをまだプッシュしていない場合は、最近プッシュされたコミットにフォールバックできます。

 git reset --soft HEAD~1

現在のコミットをすでにプッシュしている場合は、 -soft–hardに置き換えます。

 git reset --hard HEAD~1

Git Revert

resetコマンドとは異なり、 gitrevertはコミット履歴の整合性を維持します。エラーやバグのためにコミットを修正したい場合に便利です。

ターゲットのコミットを放棄したり、新しいコミットを作成したりすることはありません。代わりに、そのようなコミットを削除したり名前を変更したりせずに、最近行った変更に戻ります。これは、コミットをクリーンに保つための優れた方法であるだけでなく、常にリセットするよりも安全です。

コミットに戻すには:

 git revert HEAD~1

どこ特定のHEAD〜1つのポイントは、作業ツリーにコミット。

追跡ファイルまたはディレクトリを削除する

git rm -fを使用して、作業ツリー内の追跡されたファイルを削除できます。ただし、Gitは追跡されていないファイルをキャッシュしないため、削除できないことに注意してください。

ステージングされたファイルを削除するには:

 git rm -f filename

ステージングされたフォルダーを削除するには:

 git rm -r -f foldername

Gitロギング

Gitでコミットログと履歴を表示するには:

 git log

特定のブランチのアクティビティをログに記録するには:

 git log branch_name

関連: gitlogを使用してプロジェクトの履歴を検査する方法

場合によっては、放棄されたコミットに戻したいことがあります。したがって、関連するコミットを含め、放棄されたコミットを表示するには、次のようにします。

 git reflog

特定のブランチの参照ログを表示するには:

 git reflog branch_name

Gitを使用してプロのようにプロジェクトバージョンを管理する

Gitには多くの利点があり、メインブランチのオンプレミスでファイルやフォルダーを乱用することなく、プロジェクトのリリースをリモートで管理できます。さらに、チームでプロジェクトを簡単に実行できます。

これまで見てきたように、Gitには探索できる多くの機能があります。ただし、これらの機能を意図的に使用するように注意してください。そうしないと、物事を壊してしまう可能性があります。そうは言っても、デモのリモートリポジトリを起動して、これらの機能を試してみることができます。