はじめに
今回は下記の記事の続きです。
ブランチの作成までやってみようと思います。
Githubでのプログラム修正の流れ その1
3/25更新 Githubでのプログラム修正の流れその3を書きました。
今回の記事に出てくる言葉
| 用語 | 意味 |
|---|---|
| リポジトリ | ファイルやディレクトリの 変更履歴を保管しておくもの |
| ローカルリポジトリ | 自分のPC上にあるリポジトリ |
| リモートリポジトリ | インターネット上に存在するリポジトリ GitHubやbitbucket等 |
| コミット | ファイルの修正や追加をローカルリポジトリに 変更履歴として記録すること |
| プッシュ | ファイルの修正や追加をリモートリポジトリに 変更履歴として記録すること |
| ブランチ | 変更履歴の流れを分岐して記録していく物。 masterブランチという大元があり、そこからブランチ（枝）が分かれている、、、というイメージ。修正する機能ごとにブランチを作り、プログラム修正が完了したらmasterブランチに反映する。 |
リモートリポジトリにファイルを反映する
下記の画像の①、②を実行してみましょう。今回はファイルを新規作成したためコメントを「Initial commit」としています。ファイルを修正した場合は、「Fix ~」と書いたり、機能を新規作成した場合は「Add ~」と書いたりします。
上記の手順で作業を行えば、「Publish reposiitory」を押下することで、GitHub(リモートリポジトリ)に新規作成したファイルがアップされます。
集団で開発する際には、リポジトリを公開する必要があるためkeep this codeのチェックは外しておきましょう。
GitHubでの確認
GitHubにアクセスして、リポジトリを確認してみましょう。→GitHub
ページの左側に先ほど反映したリポジトリが表示されていると思います。
新規のプロジェクトを立ち上げる際は、こういった手順でディレクトリ、ファイルをプッシュしましょう。
ファイル修正の事前作業
ファイルを修正する際には、事前にブランチを切っておきましょう。今回は適当にブランチ名をつけましたが、実際に開発に携わる場合は「fix 機能名」とか「add 機能名」とかにした方がいいです。
今回はここまで
次回は実装編です。
・更新
↓実践編を書きました
https://qiita.com/ysda/items/b08098aa55db7e2d0fae