Gitのバージョン管理機能を利用(1)

Intro

オープンソースプロジェクトがGitによって管理され、誰でも参加できるようになった場合、どのように参加すればいいのでしょうか.
まず、Githubの全体的な青写真を見てみましょう.

リモートの別のRepository Forkからリモートの私のRepositoryへ.

また、このコードを変更するには、私のコンピュータにインポートする必要があります.私のパソコンで働くためにクローンを作成します.

で、コンピュータ上のワークスペース(ワークスペース)のファイルをGitの管理状態にアップグレードできます.この領域をstaging areaと呼びます.すなわち、staging領域に入っていないファイルをタグ付けされていないファイルまたは追跡されていないファイルと呼び、staging領域のファイルを階層ファイルと呼ぶ.

staging領域に入ったファイルはコミットできます.コミット後、コミット履歴をリモート・リポジトリにプッシュし、リモートに残すことができます.

のプッシュが完了すると、変更したコードをリモートRepositoryにアップロードし、リモートの元のリポジトリにリクエストを送信できます.

各段階で具体的に何が起こっているのかを見てみましょう.

Contribution Step

Fork

ignite-projectというプロジェクトがGitとして管理されていると仮定します.
このレポートに貢献したい場合は、まずこのリモートレポートを私のアカウントとしてインポートする必要があります.
このとき使用する機能はForkです.フォークで挟んでコピーすればいいです

git clone

git clone <프로젝트명>
ex> git clone igNIte-project

リモート・レポートのファイルを処理するには、コンピュータにコピーする必要があります.このとき使用できるコマンドはcloneです.
Git cloneコマンドの後にRepositoryアドレスを入力すると、「マイローカルRepository」(ローカルRepository)にインポートできます.

git status

ignite-project Forkは機能を実現しました.変更の保存履歴をcommitで保持することをお勧めします.コミットするには、まず、現在のローカルレポートで変更されたファイルを確認します.
Git statusコマンドは、staging areaと追跡されていないファイルのリストにどのような内容があるかを決定するために使用できます.

git status <프로젝트명>
ex> git status igNIte-project

対応するコマンドを入力すると、端末は状況に応じて使用可能なコマンドを使用するように導きます.
[add]:addはファイルをコミット可能な状態にします.詳しい内容は後から見ましょう
≪リカバリ｜Recovery｜emdw≫:変更を破棄するコマンド.Git statusでは、どのファイルがどのような状態にあるか、およびこれらのファイルの動作を知ることができます.
しかし、コードに深刻な問題やエラーが突然発見され、処理されたコードをすべて削除して再処理する必要がある場合があります.クローンを最初の状態に戻す方法はありますか?

git restore

上記のGit Restoreコマンドを使用すると、コミットされていないローカルレポートの変更を破棄できます.

git restore <파일명>
ex> git restore igNIte_index.js

git add

コードが正常に動作していることを確認すると、最終的にコミットされます.

コミットするには、まずGitが管理するstaging領域にファイルを移動する必要があります.この操作を実行できるコマンドはgit addです.
コマンドは、Gitによって追跡されていないファイルからGit管理下のstaging領域にファイルを追加します.

git add <파일이름> 

.
ただし、場合によっては、大量のファイルを同時に追加する必要がある場合があります.こんな時.

git add .

保存されていないすべてのファイルをコマンドとしてstaging areaに一度に追加できます.ただし、このコマンドを使用すると、アップロードすべきでないすべてのファイルが追加される可能性があります.

git commit

これでaddでstaging areaにファイルをアップロードするため、ファイルをコミットできます.

git commit -m <commit_message>

commitメッセージの作成方法については、さまざまな基準と会議があります.そのため、良いcommitメッセージを作成するために多くの基準を探すことができます.下のリンクを参照してください.
commitメッセージを作成する条件
staging areaに疑問を抱くかもしれません.staging areaのファイルだけが提出できるそうですが、簡単な例で理解してみましょう.

もし皆さんが引っ越しのためにスーツケースに荷物を入れる必要があるとしたら
冷蔵庫に入れてもいいし、出してもいいです.台所やリビング、寝室のものを同じ箱に混ぜておくと、後で出すのが不便になるので、同じ用途のものを一つの箱に入れたほうがいいです.箱に物を入れて、密封してラベルを貼って、それぞれの用途を書いておけば、後で箱を開けるときに便利になります.
ここでは、このmovingboxがcommitを作成できるstaging areaであることを理解し、boxに簡単なコメントを書き、commitとマークします.
GitのローカルRepositoryにはGitが管理していない領域、
トレース領域には、次の3つの状態があります.
これら3つの状態はそれぞれUnmodified,Modified,Stagedである.
Unmodified:既存のCommitファイルは変更されていません.
Modified:既存のCommitファイルを変更しました.
Staged:コミット可能.変更したファイルをコミットするには、階層領域に追加する必要があります.
したがって、addコマンドでトレース領域に入ったファイルを変更すると、ファイルは変更された状態に戻ります.そのため、操作を再追加することでファイルを階層化する必要があります.

git push

commit履歴の作成が完了しました.Pull Requestというプロシージャを実行してファイルを渡す必要があります.

Pull Requestを実行するには、現在ローカルレポートに保存されているコミットレコードをリモートレポートにアップロードする必要があります.ローカルレポートのコミット履歴をリモートレポートにアップロードします.

git push <origin> <branch>

コマンドを使用できます.

「Push要求」とは、リモート・レポートにプッシュした変更について、私と一緒に作業している他の人に通知することです.現在の業界はPRと略称している.
Pull Requestの後、プッシュした内容を簡単にまとめて通知することで、他の開発者がコードを表示することなく簡単に理解することができます.これにより、私が提出したタスクを既存のコードに統合し、より簡単な開発を導くことができます.

Outro

この節ではGitの寄与過程を紹介する.次のプレゼンテーションでは、複数の人がワークフローを実行するときの違いを見てみましょう.また,この授業では触れていないGitコマンドが非常に多いため,欠けている部分を徐々に学習する.