（今のところ）唯一の開発者として、Gitをどのように使用すればよいですか？
私はGitに複数のプロジェクトを持っていますが、最終的に他のプロジェクトを取り入れたいと考えています。ただし、現在は私だけで、GitとGitHubを非常に単純に使用しています。ブランチはなく、基本的にはローカルファイルのバックアップとしてコミットを使用しています。以前のバージョンのファイルに戻って参照することもありますが、この時点までロールバックする必要はありませんでしたが、将来必要になった場合のオプションに感謝します。
唯一の開発者として、GitまたはGitHubのどの機能を利用すれば、今すぐにメリットがありますか？私のワークフローはどのようにすべきですか？
また、将来的にプロジェクトに他の人を追加することを見込んで開始する必要がある特定のプラクティスはありますか？
また、将来的にプロジェクトに他の人を追加することを見込んで、始める必要がある特定のプラクティスはありますか？
もちろん。現在チームがなくても使用できる単純な良い習慣があります。開発用に別のブランチを作成します。アイデアは、masterブランチにはリリースされたコードバージョンまたは主要な変更のみが含まれるということです。これは、プロジェクトに参加する新しい開発者が簡単に採用できます。
また、一人で作業している場合でも分岐は便利です。たとえば、新しい機能のコーディング中にバグを見つけたとします。ブランチを使用しない場合は、両方を行う必要があります。新機能を追加し、同じブランチでバグを修正します。これは良くありません：P一方、新しい機能を作成するために新しいブランチを作成した場合は、開発ブランチをチェックアウトしてバグを修正し、新しい機能ブランチをチェックアウトして戻すことができます。
これは、唯一のプログラマーとしてできることの簡単な例です。もっと良い習慣があるに違いない。
私はこの記事を強くお勧めします： 成功したGit分岐モデル
私はまさにこの状況にありますが、Gitを使用したワークフローは必ずしも複雑ではありませんが、多少複雑であることにしました。
最初の目的はgitの方法を学ぶことだったので、ある程度の調査を行いました。その後、あなたが説明したワークフローのほとんどに戻りました。
しばらくすると、いくつかの状況が発生し、チームに参加したときに壊れるのが難しい悪い習慣を身につけたため、これは扱いにくくなりました。
だから私は次のことに決着しました：
- 作業用のローカルリポジトリ。
- アプリケーションの安定したトランクとしてのマスターブランチ
- 各機能/リファクタリングごとに1つのブランチ。基本的に、行われる大幅な変更ごとに1つのブランチ。
- ブランチが安定し、すべてのテストに合格したら、トランクにマージして戻します。
トランクを同期するgitハブアカウントもセットアップしました。これにより、さまざまなコンピューターで簡単に作業を開始できました。それは必然でしたが、他のコンピュータでは利用できなかった自分がいる環境に関連するバグを見つけることができました。だから今は、少なくとも一度は別の「未使用」システムでプロジェクトを試す習慣をつけています。顧客に導入する際に多くの頭痛の種を救います。
- 私はそれをgithubに入れるすべてのバージョンをリリース可能なバージョンとしてタグ付けします。
- お客様にリリースされた場合は、このバージョンから分岐して、お客様が宣言したバグ修正用の2番目の安定したトランクを作成します。
最初は複数のブランチが過剰に見えましたが、本当に役に立ちました。私はブランチでアイデアを始めてしばらくそれで作業することができ、サークルを実行し始めたとき、私はあきらめて別のブランチを開始して別の作業をしました。後で、半分焼きたての枝に戻ってこのアイデアを探検するというアイデアが出ました。これにより、フラッシュやアイデアを非常に迅速に処理し、それが機能するかどうかを確認できるため、全体的に生産性が大幅に向上しました。 GITを使用してブランチを切り替えるコストは非常に低く、コードベースを非常に機敏に使用できます。とはいえ、自分の歴史を片付けるには、リベースのコンセプトを習得する必要があります。 「学ぶのがいい」としてそれを押した。
すべての分岐が複雑になったとき、変更のツリーを描画して、どの分岐がどこにあるかを確認するために、ログオプションを調べました。
要するに、gitはSVN、CVS、（brrr）TFSとは異なります。分岐は非常に安く、作業を一掃するような間違いをすることは実際にはかなり困難です。仕事を失うのは1度だけです。これは、コミットを大きくしすぎたためです（上記の悪い習慣を参照）。頻繁にコミットする場合、小さなチャンクによってgitは間違いなくあなたの最高の味方になります。
私にとってgitは、ソース管理が本当に何であるかということに心を開きました。以前は、それを取得しようとしただけでした。gitが最初で、私の頭の中でそれを取得しました。そうは言っても、私は他のDVCSを試したわけではありません。おそらくこの声明が家族全員に広げられる可能性があります。
最後に、コマンドラインはあなたの友達です。グラフィカルツールが良くないということは言うまでもありませんが、コマンドラインにドロップダウンして実際に試してみたところ、Gitを本当に理解しました。それは実際には非常によくできており、非常に包括的なヘルプシステムで従うのは簡単です。私の最大の問題は、別の方法を見つけるまで、Windowsの醜いコンソールに縛られていました。
EclipseとGitの統合の両方を使用して、リアルタイムで何が行われているのかを確認し、差分のようないくつかの操作、ファイルの履歴の調査などを行います。さらに、ブランチ、マージ、プッシュ、取得、およびより複雑なログツリーのコマンドライン。いくつかの基本的なスクリプティングがあり、私はソース管理に関してこれほど生産的でなかったし、自分のソースをそれほど制御することもありませんでした。
幸運を祈ります。これが役に立てば幸いです。
私はいくつかの洗練された分岐モデルに精通しており、いくつかを仕事で使用しています。しかし、私がプロジェクトで一人で作業するとき、私はあなたが今やっていることをほぼ正確に行います。必要な場合は、事後にブランチを作成できますが、作成することはほとんどありません。一人で作業しているときに、現在のタスクが完了するまで待てないバグ修正はめったにありません。私のアドバイスは、いくつかの分岐モデルに精通することですが、必要になるまで複雑なことはありません。
より単純なモデルについては、GitHubの機能を確認できます。 「GitHubフロー」は非常にシンプルで、優れたガイドがここにあります： https://guides.github.com/introduction/flow/index.html
概要（ Scott Chaconのブログ から）：
では、GitHub Flowとは何ですか？
- マスターブランチのすべてがデプロイ可能
- 何か新しいことに取り組むには、マスターからわかりやすい名前のブランチを作成します（例：new-oauth2-scopes）
- ローカルでそのブランチにコミットし、定期的にサーバー上の同じ名前のブランチに作業をプッシュします
- フィードバックやヘルプが必要な場合、またはブランチをマージする準備ができていると思われる場合は、プルリクエストを開きます
- 他の誰かが機能をレビューしてサインオフした後、それをマスターにマージできます
- マージされて「マスター」にプッシュされると、すぐにデプロイできます。