マイレージと戦略は、ワークフローによって異なる場合があります。以下で説明することは、現在の会社で私たちのために働いていますが、自由に試して、あなたに合ったものを見つけてください.
私たちの Git リポジトリには、「マスター」ブランチがあります。すべての新規開発と主要なバグ修正は、「マスター」ブランチから離れたブランチで行われます。準備ができたら、それらはマスターにマージされます。ここでの考え方は、未完成の機能や故意にバグのあるコードがマスターになることは決してないということです (理論的には…)。
新しい「リリース」 (Web サイトのコードの新しいバージョン) を作成したい場合、他の開発者に連絡して、彼らが取り組んでいた作業が master にマージされ、GitHub にプッシュされていることを確認します。レポ。master の変更をプルしてローカル リポジトリにマージし、必要なデータベース更新スクリプトを実行して、ローカルでテストすることにより、リポジトリのローカル コピーが最新であることを確認します。修正が必要な場合は、自分で修正するか、担当の開発者に修正を依頼します。問題がなければ、ステージング サーバー (実際にはライブ サーバー上にありますが、別のデータベースと公開されていない URL を使用します) にログインし、コードを GitHub リポジトリからそこのリポジトリにプルします。 、データベースを更新し、そこで再度テストします。そうすれば、
問題が解決しない場合は、リポジトリ内の関連するコミットに、BETA-4
または などの適切なタグv1.8
を付けて、ローカルの開発リポジトリでタグをプッシュします。次に、ライブ サーバーにログインし、データベースをバックアップし、 GitHub から master ブランチをプルして、git checkout
作成したばかりのタグを を使用してチェックアウトします。それがトリックです。タグ ( 以外HEAD
) をチェックアウトした場合、Git は、別のタグをチェックアウトするまで、そのタグが指すコミットの時点でのファイルに対するリポジトリの状態を保持します。次に、ライブ サーバーで更新スクリプトを実行します。
Git は強力なツールであり、Git は使いやすいと主張する人は皆、当然のことながら嘘つきです。あなたが初心者なら、それについての良い本を入手することを強くお勧めします。地獄、私はそれをほぼ2年間ほぼ毎日使用していますが、それでも時々驚かされます. O'Reilly の本は相変わらずまともで、SourceTreeは優れた OS X GUI アプリだと思います (もちろん、CLI インターフェイスの使い方を学ぶ必要があります。特に、リモート サーバーにログインして、SSH 経由でプルなどを実行できるようにする必要がありますが、優れた GUI を使用すると、リポジトリ内の変更されたファイルの一部のみをコミットするコミットなどのタスクをより快適に行うことができます)。