タグ付けされた質問 「git」

私のコードベースが時間とともにどのように成長したかを見てみたい。GitHubには、+/-チェックインのリストに沿って、この感覚を示す素晴らしい表示があります。Google Codeでホストされているレポまたはオフラインで使用できる類似のものはありますか？

47 git 

私は専門職のプログラマーではありませんが、いくつかのコーディングを行い、githubを使用しています。私は驚くべき状況だと思うことに出くわしました。私はgitに精通しています。 私に影響を与えている（小さな）バグを見つけたプロジェクトがあります。午後はそれを見つけて修正しました。リポジトリをフォークし、変更をコミットし、プルリクエストを発行しました。「開発ブランチにマージされた」として閉じられているのを見て、すべてがうまくいったと思いました。 今日、ブランチを削除する準備をしてレポジトリを参照していましたが、メンテナのレポジトリにコミットがマージされた場所がまったく見つかりません。しばらくして、コミットとして追加されたことに気付きましたが、作成者は私ではありません。 私ができる限り、それを行う唯一の方法は、元の著者を削除するためにリベース、修正、またはその他の履歴書き換えを具体的に使用することです。 これは私には非常に間違っているようです。せいぜい紛らわしいです。最悪の場合、このレポの作成者は全員のコミットを信用しているため、元の貢献者の履歴は失われます。繰り返しますが、これは小さなバグです。プロの履歴書には使用していません。不正直に思えます。 これは正常ですか？私はそれについて何か言うべきですか？ 編集：一般的な感じは私が尋ねに行くべきだと思われるので、私は今朝ちょうどそれをします。 以下のリクエストに従って。私はチェックし、コードが存在し、私が書いたとおりに正確に適用されました（コメントを含む）。コミッターと著者の両方が変更されたことを確認しました。私の変更と同時に追加された変更も1つありました。これは1行で、パッチとそれ以前のその他のコードに影響します。IEの1行の追加は、修正していたバグとは関係ありません。 更新 答えは、作成者が開発ブランチを維持しており、マスターブランチからそこにマージしたくないということでした。彼はマージを回避するために私のコミットを再作成しました。元のブランチb / c gitは、必要に応じてコミットをチェリーピック、リベース、およびマージするのに強力です。 これはgithubでは一般的ですか？ どのブランチにパッチを適用するかを尋ねるためにプロジェクトのメンテナーに連絡する必要がありますか？

44 git  github 

私はSVNのユーザーであり、現在Gitを学んでいます。 SVNでは、通常、ローカルマシンでレポジトリをチェックアウトします。レポジトリには、プロジェクトのすべてのブランチが含まれており、興味のあるブランチのフォルダーを選択してそこで作業していました。 Gitを使用すると違いがわかります。 現在、私はリポジトリをクローンし、gitkを使用して特定のブランチをクローンしています。 プロジェクトフォルダーにはそのブランチのコンテンツのみが含まれており、SVNのようにすべてのブランチを表示することはできません。 Gitを使用してローカルリポジトリ内のすべてのブランチを表示する簡単な方法が見つかりません。 私が説明したGitプロセスが「標準」であるかどうか、そしてある程度正確であるか、何か不足しているのかを知りたいです。 また、たとえば、マスターで修正プログラムを作成する必要があるが、別のブランチのコンテンツも保持する必要がある場合に備えて、2つのブランチで同時に作業する必要があるプロセスの処理方法を知りたいと思います。 Gitのリポジトリからクローンされたブランチを含むフォルダーを作成するための推奨される名前の規則は何myproject-branchnameですか？

44 git  github 

私の同僚は、ビルドに失敗したコミットを元に戻すためにCIサーバーを作成することを考えていると言ったので、（少なくともビルドを渡す場合のようHEADにmaster）常に安定しています。 これはベストプラクティスmasterですか、それとも開発者が修正するまで壊れたままにしておくよりも問題がある可能性がありますか？ 私の考えでは、コミットを元に戻すと、コミットと修正を読み直すタスクがより複雑になります（開発者は元に戻して修正をコミットする必要がありますが、これも混乱しますgit log）。修正。master安定していることにはいくつかの利点がありますが、失敗したコミットを元に戻すことは私を納得させません。 編集：それがmaster他の開発ブランチであるかどうかは関係ありませんが、質問は同じままです：ビルドに失敗したコミットをCIシステムが元に戻す必要がありますか？ 別の（長い）編集：わかりgitました、奇妙な方法で使用しています。ブランチにコミットすると他の開発者とその変更から隔離され、ブランチを再統合して競合の可能性に対処する必要があるため、ブランチの概念は実際のCIに反すると信じています。全員がmasterこの競合にコミットすると、最小限に抑えられ、すべてのコミットがすべてのテストに合格します。 もちろん、これにより、安定性のみをプッシュする（またはビルドを中断する）ことを強制し、後方互換性を壊さないように、または新しい機能を導入するときに機能を切り替えないように、より慎重にプログラムします。 CIをこのように、またはそのように行う場合、トレードオフがありますが、それは質問の範囲外です（これに関する関連する質問を参照）。ご希望であれば、質問を言い換えることができます。開発者の小さなチームが機能ブランチで協力しています。1人の開発者がそのブランチのビルドを中断する何かをコミットした場合、CIシステムはコミットを元に戻すべきですか？

44 git  continuous-integration 

通常のgitとgithubを使用して、マスターブランチに取り組んでいる機能ブランチのプルリクエストを作成するだけで、コードレビューを行うことができます。git-flowでコードレビューを行うにはどうすればよいですか？「git flow feature finish`」のようなワークフローでは、コードレビューが実際に行われる場所と、git-flowまたはgitがそのレビューを容易にする方法について混乱しています。

43 code-quality  git  code-reviews  github  gitflow 

現在、残念ながらソフトウェア品質ガイドラインが常に守られているわけではないファイルを含む、より大きなプロジェクトに取り組んでいます。これには、明らかに複数の異なる機能を含む大きなファイル（2000〜4000行を読む）が含まれます。 次に、これらの大きなファイルを複数の小さなファイルにリファクタリングします。問題は、彼らがとても大きいので、異なるブランチの複数の人々（私を含む）がこれらのファイルで作業していることです。ですから、これらのリファクタリングを他の人々の変更とマージすることが難しくなるので、私は実際に開発とリファクタリングから分岐することはできません。 もちろん、全員がマージしてファイルを開発し、ファイルを「フリーズ」し（つまり、誰もファイルを編集できないようにする）、リファクタリングしてから「フリーズ解除」する必要があります。しかし、リファクタリングが完了するまでこれらのファイルに対する作業を基本的にすべて停止する必要があるため、これもあまり良くありません。 だから、リファクタリングする方法がありますか、他の誰かに作業を停止することを要求しないでください（長い間）、または開発のために機能ブランチをマージして戻しますか？

41 git  refactoring  code-quality 

動作するコードのみをコミットすることを要求するのは良い考えですか？ このコミットでは、リポジトリを次のように動作状態のままにする必要はありません。 ...設計の初期段階にありますが、コードはまだ安定していません。 ...あなたはプロジェクトの唯一の開発者です。物事がうまくいかない理由を知っています。さらに、壊れたコードをコミットして誰かの作業を停止することはありません。 ...現在、コードは機能しません。これに大きな変更を加えます。物事がugくなる場合に戻るポイントを得るために、コミットしましょう。 ...チェーンが長く、壊れたコードがローカルブランチに存在する場合は問題ありません。すなわち ローカルファイル ステージングエリア ローカルブランチでコミット リモートの個人機能ブランチでのコミット リモートdevelopブランチとマージ リモートmasterブランチとマージ リモートreleaseブランチとマージ ...早くコミットし、頻繁にコミットします。 したがって、上記のリンクされた質問では、回答の大半は、コンパイルできないコードをコミットしても、ローカルおよび機能ブランチでは問題ないと述べています。どうして？壊れたコミットの価値は何ですか？ 追加：ローカルブランチでは、好きなことは何でもできると言っている、非常に投票されたコメントがいくつかあります。ただし、質問の技術的な側面には興味がありません。むしろ、ベストプラクティス-業界で長年働いてきた人々が最も生産性を高めてきた習慣-を学びたいと思います。 膨大な量の素晴らしい答えに驚いています！彼らは、コードを整理するためにブランチを使用するのが十分ではないという結論に至ります。

40 version-control  git  branching 

私はソーシャルコーディングコミュニティの初心者であり、このような状況で適切に進める方法がわかりません。 数週間前にGitHubリポジトリを作成しました。誰かがプロジェクトをフォークして作った私に、やるにされているいくつかの小さな変更を。誰かが私のプロジェクトを分岐させて、それを追加するのに時間をかけたことに興奮しています。変更を自分のコードに取り込みたいのですが、いくつかの懸念があります。 1）フォークされたレポジトリからgit経由で変更を取り込む方法がわかりません。 私の理解では、プルリクエストを介して変更をマージする簡単な方法がありますが、フォーカーはそのリクエストを発行する必要があるように見えますか？ 2）プルリクエストなしで変更をプルすることは可能ですか？これは最初のものに関連しています。私は数週間コードを脇に置いて、次の作業は他の誰かによって行われていることを知り、何らかの方法でクレジットを与えずにコードをコピーしたくないことを知りました。変更を明示的に要求していない場合でも、変更を取り込む必要はありませんか？ここのエチケットは何ですか 私はこれを考えすぎるかもしれませんが、事前にご意見をお寄せいただきありがとうございます。私はハッカーのコミュニティにはかなり慣れていませんが、貢献できるようにしたいです！

40 git  github  etiquette 

Gitでは、適切なコミットテンプレートを設定および実施できます。 会社で実施する適切なコミットテンプレート/ガイドラインを（できれば議論を伴って）推奨できますか？

38 version-control  git  dvcs 

2012年です！MercurialとGitは両方ともまだ強力です。 私は両方のトレードオフを理解しています。また、誰もが何らかの好みを持っていることを理解しています。それはいいです。 両方の使用レベルに関する情報を探しています。例えば、上のstackoverflow.com、探しGitのは、あなたに12000本のヒットを取得し、Mercurialはあなたを取得3000 Googleトレンドでは、それは1.9だと言う：Gitのための1.0。 両方のツールの相対的な使用を推定するために、他にどのような経験的情報が利用できますか？

37 git  mercurial 

現在、アプリケーションに新しい機能を追加するたびに新しいブランチを作成していました。 機能が完成して機能するようになったら、それをmasterブランチにマージします。 しかし、後で、この機能を更新する必要がある場合（改善など）、新しいブランチを作成する方が良いですか、マスターで以前のものをリベースする必要がありますか？更新してから再度マージしますか？ たとえば、Ruby on Railsアプリケーションにmodeling-memberというブランチがあります。後で、メンバーモデル（このブランチで作成された）にいくつかの属性を追加する必要があります。私は何をすべきか？このブランチをマスターでリベースし、モデルを更新して再度マージするか、単に新しいブランチを作成しますか？

36 git  branching 

一般的なベストプラクティスが何であるかを知りたいです。プロジェクトが動作状態（適切にビルド、すべてのテストに合格など）になるようにgitコミットを強制するか、壊れたコードをコミットしても問題ありませんか？ たとえば、この要件を放棄した場合、コミットにより柔軟に対応できます（アプリが動作状態にない場合でも、論理チャンクとして使用します）。ただし、それを強制すると、特定のコミットを後で選択できる柔軟性が得られます...

36 git 

チームでは、ソース管理としてGitを使用しています。ほとんど独立しているが重複するコード領域がいくつかあります。最近、ソース管理を使用するためのワークフローとアプローチについて議論してきました。機能ブランチワークフローの使用を促進するときに出てくる不満の1つは、人々がしばしば複雑なマージ競合に遭遇し、それが誤って解決されることです。複雑なことで、私は「解決方法については明らかではない」という意味です。これを踏まえて、「プルリベース」ベースのワークフローなど、他のワークフローがより積極的に使用されています。 機能分岐アプローチの支持者として、私は実際に苦情を受け取っていません。はい、ローカルの機能ブランチをマスターまたはどこからでも最新の状態に維持する必要がありますが、それが唯一の本当の問題です。マージが常に複雑で、二次的な影響がある場合、それはGitの問題ではなく、チームワークの問題であると考えています。 これを考えるのは正しいですか？複雑なマージの競合は、良いものか悪いものかの兆候ですか？

35 version-control  git  teamwork 

私は小さなプロジェクトを始めることを考えており、gitでバージョン管理をしたいと思っています。 Bitbucketは無料プランで私にとって良い選択肢のようです。ウェブインターフェース、Mac OSクライアントなどの優れたツールがあるため、gitを操作するためのメインツールとして使用したいと思います。しかし、サードパーティのサービスを使用することによって引き起こされる可能性のある偶発的な損害からより高い保護を得るために、リポジトリの2番目のバックアップコピーとしてNASにgitをインストールしたいです。 ここで私の質問は、2つの異なるホストでリポジトリを作成し、それらを同期させることが可能かどうかです。たとえば、週に1回、Bitbucketのリポジトリと一致するようにNASのリポジトリを更新するとします。その後、Bitbucketで何かが発生した場合でも、ローカルNASストレージでの開発の完全な履歴を備えた完全なリポジトリを保持します。 また、完全な履歴を持つ既存のリポジトリを別のgit-serviceにインポートする方法はありますか？ ミラーリングが必要だと思います。この記事は、私が必要とするものを正確に説明しているようです。そして、この1としても。 完全な履歴で完全なコピーを作成し、両方のホストのリポジトリに新しいバージョンを自動的にコミットすることさえできると信じています。 私は正しいですか？

34 git 

10人のアジャイル開発者のチームがあるとします。毎日、彼らはボードからタスクを選び、そのタスクに対していくつかの変更をコミットします（1日の終わりまでに）。すべての開発者は、トランクに対して直接チェックインします（Googleスタイル、すべてのコミットはリリース候補であり、機能の切り替えなどを使用します）。 SVNのような集中型CVSを使用している場合、1人がコミットするたびに、ビルドサーバーは変更を統合し、他の9人の開発者の作業に対してテストします。ビルドサーバーはほぼ1日中継続的に実行されます。 しかし、gitのようなDCVSを使用している場合、開発者はタスクを完了するまで待ってから、ローカルコミットをすべて中央リポジトリにプッシュすることができます。それらの変更は、一日の終わりまで統合されません。 このシナリオでは、SVNチームはより頻繁に継続的に統合し、gitチームよりもはるかに迅速に統合の問題を発見しています。 これは、DVCSが従来の集中型ツールよりも継続的なチームに適していないということですか？この遅延プッシュの問題をどのように回避しますか？

34 git  svn  continuous-integration  dvcs  branching