唯一の開発者として（今のところ）、Gitをどのように使用すべきですか？[閉まっている]

Gitには複数のプロジェクトがあり、それらを最終的に他の人に紹介したいと思っています。ただし、現在は私だけで、GitとGitHubを非常に単純に使用しています。ブランチはなく、基本的にコミットをローカルファイルのバックアップとして使用しています。時々、以前のバージョンのファイルを参照して参照することもありますが、この時点までロールバックする必要はありませんが、将来必要になる場合はオプションを高く評価します。

唯一の開発者として、現在利用できるGitまたはGitHubの機能は何ですか？私のワークフローはどのようなものですか？

また、今後プロジェクトに他の人を追加することを見越して、始める必要がある特定のプラクティスはありますか？

また、今後プロジェクトに他の人を追加することを見越して、始める必要がある特定のプラクティスはありますか？

もちろん。現在チームを持っていない場合でも使用できる簡単なグッドプラクティスがあります。開発用に別のブランチを作成します。マスターブランチには、リリースされたコードバージョンまたは主要な変更のみが含まれるという考え方です。これは、プロジェクトに参加する新しい開発者が簡単に採用できます。

また、分岐は、単独で作業している場合でも便利です。たとえば、新しい機能のコーディング中にバグを見つけます。ブランチを使用しない場合は、両方を実行する必要があります。同じブランチで新しい機能を追加し、バグを修正します。これは良くありません：P一方、新しい機能を作成するために新しいブランチを作成した場合、開発ブランチをチェックアウトし、バグを修正し、新しい機能ブランチをチェックアウトすることができます。

これは、唯一のプログラマーとしてできることのほんの一例です。もっと良い習慣がなければならないと確信しています。

この記事をお勧めします：成功したGit分岐モデル

私はまさにこの状況にいますが、Gitでのワークフローは必ずしも複雑ではありませんが、やや複雑になりました。

最初の目的はgitの方法を学ぶことだったので、ある程度の調査を行いました。その後、説明したワークフローにほぼ戻りました。

しばらくすると、状況によっては作業が難しくなりました。また、チームに参加すると壊れにくいという悪い習慣もありました。

だから私は次のことを決めました：

• 作業用のローカルリポジトリ。
• アプリケーションの安定したトランクとしてのマスターブランチ
• 機能/リファクタリングごとに1つのブランチ。基本的に、行われる大規模な変更ごとに1つのブランチ。
• ブランチが安定し、すべてのテストに合格したら、トランクにマージし直します。

また、トランクを同期するgitハブアカウントをセットアップします。これにより、さまざまなコンピューターで簡単に作業を開始できました。それは必然でしたが、他のコンピューターでは利用できなかった環境に関連するバグを見つけることができました。だから今は、少なくとも一度は異なる「処女」システムでプロジェクトを試すのを習慣にしています。顧客に展開する時が来たとき、私は多くの頭痛の種を救います。

• リリースするすべてのバージョンをリリース可能なバージョンとしてgithubにタグ付けします。
• 顧客にリリースされた場合、このバージョンから分岐して、顧客が宣言したバグ修正用の2番目の安定したトランクを作成します。

最初は複数のブランチはやり過ぎのように見えましたが、本当に大いに役立ちました。ブランチでアイデアを開始し、しばらくの間作業し、サークルを実行し始めたら、あきらめて別のブランチを開始して他の作業を行いました。その後、私は半分焼いたブランチに戻ってこのアイデアを探求するアイデアが生まれました。これにより、フラッシュやアイデアを非常に迅速に実行し、それが機能するかどうかを確認できるため、生産性が大幅に向上しました。GITを使用してブランチを切り替えるコストは非常に低いため、コードベースで非常に機敏です。それは私の歴史をきれいにするためにリベースの概念を習得しなければならないということですが、私は一人でいるので、本当にする必要があるとは思いません。「学ぶにはいい」としてそれを押した。

すべての分岐が複雑になったとき、ログオプションを調べて変更のツリーを描画し、どの分岐がどこにあるかを確認しました。

要するに、gitはSVN、CVS、または（brrr）TFSとは異なります。分岐は非常に安価であり、作業を一掃する間違いを犯すことは実際にはかなり困難です。一度だけ仕事を失ったのは、コミットを大きくしすぎたためです（上記の悪い習慣を参照）。頻繁にコミットする場合、小さなチャンクでgitは間違いなくあなたの最高の味方になります。

私にとってgitは、ソース管理の本当の意味に心を開きました。以前はそれを取得しようとしていましたが、gitが最初であり、私の頭の中ではそれを取得しました。とはいえ、私は他のDVCSを試しませんでした。おそらくこの声明は家族全員に広げることができます。

最後のアドバイスとして、コマンドラインはあなたの友人です。グラフィカルツールが良くないというわけではなく、まったく逆ですが、コマンドラインにドロップダウンして自分で試してみたときに、本当にgitを使いました。実際、非常によくできており、非常に包括的なヘルプシステムで簡単にフォローできます。私の最大の問題は、代替手段が見つかるまで、Windowsのbutいコンソールに縛られていたことでした。

現在、EclipseとGitの両方を使用して、リアルタイムで何が起こっているかを確認し、差分、ファイルの履歴を調べるなどの操作を行います。さらに、ブランチ、マージ、プッシュ、取得、およびより複雑なログツリーのコマンドライン。いくつかの基本的なスクリプト作成と、ソース管理に関してこれまでにないほど生産的であり、ソースをあまり管理していません。

幸運を祈ります。これが役に立てば幸いです。

私はいくつかの洗練された分岐モデルに精通しており、仕事でいくつかを使用しています。しかし、私がプロジェクトで一人で仕事をするとき、私はあなたが今していることとほぼ同じことをします。必要に応じて、事後にブランチをいつでも作成できますが、ほとんど作成しません。単独で作業している場合、現在のタスクが完了するまで待てないバグ修正はほとんどありません。私のアドバイスは、いくつかの分岐モデルに精通することですが、必要になるまで物事を複雑にする意味はありません。

より単純なモデルの場合、GitHubの機能を確認できます。「GitHubフロー」は非常にシンプルで、ここに優れたガイドがあります：https : //guides.github.com/introduction/flow/index.html

要約（Scott Chaconのブログより）：

GitHub Flowとは何ですか？

• masterブランチのすべてがデプロイ可能です
• 新しい何かに取り組むには、マスターから説明的な名前のブランチを作成します（例：new-oauth2-scopes）
• そのブランチにローカルでコミットし、定期的にサーバー上の同じ名前のブランチに作業をプッシュします
• フィードバックやヘルプが必要な場合、またはブランチのマージの準備ができていると思われる場合は、プルリクエストを開きます
• 他の誰かが機能を確認してサインオフしたら、マスターにマージできます
• マージされて「マスター」にプッシュされると、すぐにデプロイできます。