0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

GitHub pushまでの流れ

Posted at

4月からエンジニアとして働いています。
現在は研修中で、研修内容ではAWScodecommitというものを使っています。

メンターに何度も指摘を受けているのに、プルリクエストで修正が入るため自己学習としてGitHubpushまでの流れをまとめます。

プログラミング初学者と自分の成長につながればと思います。

ファイルに変更を加えたら、、

まずは変更内容を確認します。
理由は変更した内容以外に、意図していない変更が起きていないか確認するためです。
私の場合は身に覚えのないのに、ファイルが削除されていたり、タスクと関係のないファイルに編集した痕跡があり、メンターに指導されました。

自分の変更内容を確認するコマンドは以下です

git status

このコマンドはワーキングツリーの状態と、ステージングの状態を表示するコマンドです。
ワーキングツリーというのは現在作業している領域です。
ステージングとはコミットを待っている一時保存領域のような場所です。

git statusをたたき、作業したファイルと表示されているファイルに相違がないこと確認できたら以下のコマンドを入力しましょう。

git add .

このコマンドは先ほどお伝えした、ワーキングツリーからステージングエリアへ編集内容を一時保存(コミットを待機)するコマンドです。一番最後の.(conma)は全てのファイルを指名しています。

ここでさらに

変更内容をステージングエリアへ加えたら、やっとここでローカルリポジトリへ保存するコマンドを叩きます。

git commit -m "変更内容を誰が見ても分かるようにかつ、コンパクトに記載する"

これを何度か繰り返し機能などを記述していきましょう。

そして前回のコミットとの差をみておきましょう。正しい変更内容か確認するためです。
時々、必要なファイルが作成されていなかったり、よくわからないファイルが作成されていることがあるからです。
前回のコミットとの差を確認するコマンドは以下です。

git diff

ローカルリポジトリの内容をリモートリポジトリへ送りたいところですが、まだです。

私が良くあったミス、というか反省はプッシュした後のコンフリクトです。
これが起こると、複数人規模の開発ではどえらいことになるそうです。
なのでまずはリモートリポジトリにある最新の状態を今の自分の変更内容へ引っ張ってきて、コンフリクトを解消しておきましょう。

git pull origin ブランチ名

これで自分のパソコンである程度小規模のコンフリクトを発生・解消します。

そして、ようやくpushします。

すごく面倒で手間だと最初は感じますが、だんだんとこの作業のおかげでタイムロスを防げることを実感できてきます。一緒に頑張っていきましょう。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?