GitおよびGitHubユーザー向けの27の重要なヒント

Gitユーザーには数十の入門ガイドがあり、GitHubには独自のガイドが多数用意されていますが、GitとGitHubをよりスマートに操作したい開発者にとって役立つヒントのコレクションを見つけるのは簡単ではありません。それを修正しましょう。

GitまたはGitHubに慣れていない方のために、次のいくつかの段落では、ヒントを理解するのに十分な背景を説明します。この記事の最後に、約12の役立つリソースをリストします。

Gitは分散バージョン管理システムであり、もともとはLinuxカーネルコミュニティのために、そしてLinuxカーネルコミュニティの助けを借りて、2005年にLinusTorvaldsによって作成されました。私はGitであなたを販売するためにここにいるわけではないので、それがどれほど速く、小さく、柔軟性があり、人気があるかについては割愛しますが、Gitリポジトリ(略して「リポジトリ」)のクローンを作成するときは知っておく必要があります。 、一度に1つのブランチからのスナップショットだけでなく、自分のコンピューターでバージョン履歴全体を取得します。

Gitはコマンドラインツールとして始まり、Linuxカーネルコミュニティでの起源にふさわしいものでした。必要に応じて、Gitコマンドラインを引き続き使用できますが、使用する必要はありません。特に、ホストとしてGitHubを使用している場合は、WindowsまたはMacで無料のGitHubデスクトップクライアントを使用できます。一方、Gitコマンドラインはどのホストでも機能し、ほとんどのMacおよびLinuxシステムにプリインストールされています。

コマンドラインを使用するのが最も快適か、グラフィカルユーザーインターフェイスを備えたネイティブクライアントを使用するのが最も快適かを判断できるのはあなただけです。GUIが好きな場合は、GitHubクライアント(WindowsとMac)に加えて、SourceTree(WindowsとMac、無料)、TortoiseGit(Windowsのみ、無料)、Gitbox(Macのみ、$ 14.99)を検討することをお勧めします。または、Gitを内部でサポートするエディターまたはIDEを使用することもできます(ヒントNo. 11を参照)。

Git / GitHubのヒント1:ほとんどすべてのクローンを作成する

GitHubやその他の公開Gitリポジトリから入手できる興味深いプロジェクトがたくさんあり、自分のコンピューターに自由に複製できます。なぜあなたはそれをしたいのですか?理由の1つは、コミットログのコメントスタイルなど、関心のある言語でのコーディングスタイル、実践、およびツールについて何かを学ぶことです(ヒント4を参照)。2番目の理由は、特定のプロジェクトがその目標をどのように達成するかを学ぶことです。3番目の理由は、ライセンスが許可し、目的に合っている場合、プロジェクトを自分の取り組みや製品に組み込むことです。ちなみに、後でコンプライアンスの問題が発生しないように、ライセンスを再確認してください。

git cloneマニュアルページからの定義:

リポジトリを新しく作成されたディレクトリに複製し、複製されたリポジトリ内の各ブランチのリモート追跡ブランチを作成し(を使用して表示git branch -r)、複製されたリポジトリの現在アクティブなブランチからフォークされた初期ブランチを作成してチェックアウトします。

クローン作成後、git fetch引数のないプレーンはすべてのリモートトラッキングブランチを更新し、引数のないプレーンgit pullはさらに、リモートマスターブランチを現在のマスターブランチにマージします(存在する場合)。

Git / GitHubのヒント2:頻繁に引っ張る

Gitを使って(そして実際、バージョン管理システムを使って)自分で混乱させる最も簡単な方法の1つは、ファイルの同期を解除することです。git pull頻繁に使用する場合は、リポジトリのコピーを最新の状態に保ち、変更したコードを他のユーザーの変更とマージする機会があります。マージは理解しやすく、実行も簡単です。理想的には、簡単に実行できる場合です。自動的に行われます。このヒントの当然の結果は、プロジェクトのステータスを監視することです。多くのGitクライアントは、最新の状態に保つために更新する必要があるときに自動的に表示します。

Git / GitHubのヒント3:早期に頻繁にコミットする

コミットは、プロジェクトに対するきめ細かい更新であり、1つ以上のファイルに対する1つ以上の変更が含まれます。これは、完了した作業単位の記録と考えてください。これは、論理的な全体としてプロジェクトに適用したり、プロジェクトから削除したりできます。テストする前であっても、完了したすべての論理変更をコミットしてください。コミットはローカルリポジトリにのみ適用されます。このヒントの結果については、ヒントNo.4および5を参照してください。

git commitマニュアルページからの定義:

インデックスの現在の内容を、変更を説明するユーザーからのログメッセージとともに新しいコミットに格納します。

Git / GitHubのヒント4:他の人にコメントしてもらうように、コミットにコメントします

コーダーには10種類あります。コミットにコメントする人とコメントしない人です。(古い冗談。ヒント:私はどのベースを使用していますか?)

私は、良いコミットログメッセージの執着者であることを自由に認めます。コミットごとにメッセージを要求するようにリポジトリを設定しました。コミットが「xx」のオーダーのログで着地すると、イライラする深夜のメッセージを送信することが知られています。(1)コードがそれ自体を語るべきであり、(2)インラインコメントが変更ログよりもはるかに重要であると考える開発者の場合は、これまでに見たことのないリポジトリのクローンを作成して、すべてのコードを読まずに投稿された最新の問題を引き起こした可能性のある最近のコミット。ご覧のとおり、正確なコミットログは2倍以上に優れています。

Git / GitHubのヒントNo.5:変更をテストするときにプッシュする

アウトソーシング会社がSubversionから切り替えたが、分散ソース管理と集中ソース管理の違いについて開発者をトレーニングしなかったときに、私が知ることができなかった最悪のGit関連のバグが発生しました。約1か月後、プロジェクトは、誰も追跡できないような奇妙なバグを開発しました。毎日のスタンドアップミーティングで、誤動作していたアプリケーションの領域を担当する開発者は、「2週間前に修正しました!」と抗議しました。または、別の開発者が慎重にチェックインした変更をわざわざプルしないと非難します。

最終的に、誰かが問題を特定し、すべての開発者にpushコミットの方法とタイミングを教えました。つまり、コミットがローカルビルドで正常にテストされるときはいつでも。その後、同社は2日間のマージフェストを行った後、更新された統合製品を構築して展開できるようになりました。

Git / GitHubのヒントNo.6:自由に分岐する

Gitが他のバージョン管理システムよりも優れている最大の利点の1つは、マージに使用するのに最適な共通の祖先をGitが自動的に選択するため、マージが通常はうまく機能することです。ほとんどのソフトウェア開発者は、プロジェクトでブランチの作成をより頻繁に開始する必要があります。それは、苦しんでいる全員参加の戦略会議の主題ではなく、日常的な日常の出来事であるべきです。ブランチプロジェクトが完了し、承認され、メインプロジェクトに移行する準備ができた場合、マージによって克服できない問題が発生する可能性はありません。

特にCVSでソースコード管理を行っている会社で立ち往生している場合は、調整が必要です。しかし、それを試してみてください。バグが壊れているためにトランクプロジェクトを公開する必要があるときに、顧客に未完成の実験コードを誤って表示させるよりもはるかに優れています。(この記事では、基本的な分岐とマージについて詳しく説明します。)

Git / GitHubのヒントNo.7:慎重にマージする

通常、Gitとのマージはうまく機能しますが、考えずにマージを行うと、問題が発生する場合があります。ステップ1は、コミットされていない変更がないことを確認することです。git mergeマニュアルページから:

外部の変更を適用する前に、自分の作業を適切な状態にしてローカルでコミットする必要があります。これにより、競合が発生した場合に作業が中断されることはありません。も参照してくださいgit-stash

ヒント8も参照してください。

の間にすべてが南に行ったgit mergeとしても、あなたは馬鹿にされていません:

複雑な競合が発生したマージを試みて、最初からやり直したい場合は、で回復できますgit merge —abort

マージにGUIを使用する場合git mergeは、通常git mergetool、後続のコマンドはです。昔ながらの方法を好む場合は、お気に入りのプログラミングエディタと競合するファイルを編集し、、、、および行を完全に削除し<<<<<<<、改訂されたファイルと修正した各ファイルを保存できます。=======>>>>>>>git add

Git / GitHubのヒントNo.8:ブランチを切り替える前に隠しておく

ソフトウェア開発者のワークフローが直線的であることはめったにありません。ユーザーはバグを報告する勇気があり、マネージャーはあなたが取り組むために選んだチケット以外のチケットを優先する大胆さを持っています、そしてあなた自身があなたがやりたいことについてあなた自身が考えを変えるかもしれません。

これで、リリース用にコミットされた3つのファイルと、変更されたが機能していない状態の4番目のファイルがあります。(git status自分がどこにいたか覚えていない場合、コマンドはこれらすべてを教えてくれます。)突然、製品版のバグ修正に取り組む必要があります。ブランチをプロントに切り替える必要がありますが、切り替えることはできません。作業ディレクトリが汚れていて、失いたくない2時間の作業があります。

を入力しgit stashます。Voilà!これで、すべての変更がWIP(作業中)ブランチに保存され、クリーンディレクトリから本番ブランチに切り替えることができます。それが終わったら、元の場所に戻りますgit stash apply

Git / GitHubのヒントNo.9:要点を使用してスニペットとペーストを共有する

GitHubの「要点」(共有コードスニペット)はGit機能ではありませんが、Gitを使用します。すべての要点はGitリポジトリであり、GitHubGistを使用すると簡単に共有できます。Gistで、トピック、プログラミング言語、フォークステータス、スター付きステータスで公開の要点を検索できます。秘密の要点を作成し、URLで共有することもできます。

Git / GitHubのヒントNo.10:GitHubを探索する

多くの興味深いオープンソースプロジェクトには、GitHubにリポジトリがあります。Explore GitHubは、それらのいくつかを見つけるためのブラウジングインターフェイスを提供しますが、ほとんどの場合、検索ボックスにプロジェクト名の数文字を入力してリポジトリを見つける方が簡単です。例えば、入力するjqか、backまたはang主要なオープンソースのJavaScriptフレームワークの3を見つけること。

Git / GitHubのヒントNo.11:オープンソースプロジェクトに貢献する

オープンソースプロジェクトを閲覧している限り、それらに貢献してみませんか?思ったほど難しくはなく、たくさんのことを学ぶことができます。たとえば、jquery / jquery(jQuery Core)プロジェクトのクローンを作成し、README.MDを参照できます。上部の近くに表示されます:

オープンソースソフトウェア開発の精神で、jQueryは常にコミュニティコードの貢献を奨励しています。始めるのを助け、コードを書く前に、これらの重要な貢献ガイドラインを完全に読んでください...

その後に3つのリンクが続きます。3つのうちの最初のものは、かなり早く始めることができます。すべてのオープンソースプロジェクトが計画をそれほど明確に示しているわけではありませんが、すべてが試みています。

寄稿者とコミッターの違いを理解します。寄稿者は必要な契約に署名し、プロジェクトで寄稿を利用できるようにしました。コミッターは、提供された貢献をプロジェクトリポジトリに実際にコミットする権限を与えられています。コミッターがコントリビューションをテストしている間は遅延が発生し、マスターブランチを拘束したくないため、プルリクエストを送信する前に別のブランチ(ヒント6を参照)で変更を加える必要があります(ヒントNoを参照)。 。16)。