@CodenlynDamilola Ale
ソフトウェア開発プロセスにおいてバージョンコントロールが重要となってきている。 バージョン管理は、後で特定のバージョンを呼び出すことができるように、時間の経過とともにプロジェクトに対する変更を記録するのに役立ちます。 今回はGitHubについてお話します。
私が開発者になったとき、開発者が自分のコードをオンラインで持つことが必要だと誰もが言ったので、GitHubを使い始めました。 それを念頭に置いて、システムがクラッシュしたときにダウンロードできるように、自分のプロジェクトをすべて保存しておく場所として捉えました。
その後、GitHubはそれだけでなく、プロジェクトやソフトウェアを構築する各ステップでの進捗をすべて見ることができる場所であることに気づきました。
マイクロバースに入社した年の半ば頃、GitHub Flowに出会いました。 GitHub Flowは、ソフトウェアの機能ごとにフィーチャーブランチを作成することを推奨しています。
そして、自分のソフトウェアやプロジェクトが公開できる状態になったら、プルリクエストを作成し、masterブランチにマージするのです。
cdinto the repository
check the branch you are currently on
新規作成
feature branch
機能の作業を始め、終了したら、終了します。
add,
commitと
pushを feature ブランチへ
GitHub 上のリモートリポジトリに移動し pull リクエストを作成します。 このように、各フェーズで作成した機能、追加した機能をすべて確認することができます。 また、プルリクエストをマージした時点で、その機能は誰でも使用または閲覧する準備ができたと言えるのです。
そのとき、GitHub flowは小規模なプロジェクトでは完璧に機能しますが、複数の重要な機能を持つプロジェクトでGitHub flowを使うと、masterブランチにマージされたすべての機能が本番環境の準備ができていると間接的に言っていることになりますが、よく考えてみると、そうでしょうか?
多くの機能を持つプロジェクトで1つの機能をリリースすることは意味がなく、そこでGit Flowの出番となるわけです。 GitHub Flow と非常によく似ていますが、バージョン管理のよりよい方法を導入しています。
Git Flow では、開発ブランチを作成し、本番の準備ができるまでは、開発ブランチをデフォルトのブランチとします。 こうすることで、すべてのフィーチャーブランチは開発ブランチから作成され、完了したら開発ブランチにマージされます。
理にかなっているでしょ？ これで、自分のソフトウェアがすべての機能を追加して製品化する準備ができたと確信したときだけ、master ブランチにマージすることができます。
リポジトリをクローンした後、
developmentブランチを作成します
現在作業中のブランチを確認します
ファイル、おそらく HTML ファイルを追加してみて、開発ブランチでリモート レポジトリを更新できるようにします。
GitHub のリモート リポジトリに移動し、設定に進みます。 branches をクリックし、development をデフォルトブランチにします
さて、これで。 ブランチからプルリクエストを作成し、
developmentブランチにマージすることができます。
すべての機能の準備ができたら、次のようにします。 上記と同じ手順で、マスターを再びデフォルトにし、開発からマスターへのプルリクエストを作成し、本番用にマージしてください。
長くなりましたが、GitHub Flow と Git Flow のどちらを使うべきか、もうお分かりいただけたと思います。
Tags
無料アカウントを作成し、カスタムリーディングエクスペリエンスを解放することができます。