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

gitブランチモデルに関する多くのアドバイスを見てきましたが、最も一般的な意見は、masterブランチで直接変更を加えることは悪い考えだと思われます。 同僚の1人がmasterブランチ上で直接変更を行うことを非常に喜んでおり、いくつかの会話にもかかわらず、彼らはこれを変更する可能性は低いようです。 現時点では、マスターに直接取り組むのは悪い習慣である同僚を納得させることはできませんが、私は彼の働き方と矛盾することを理解し、いつ再訪する必要があるかを知りたいですこの問題。

25 version-control  git  svn  branching 

ここに取引があります。私は新しい会社に入社し、ほとんど一年間触れられていないブランチの仕事を終えるように頼まれました。一方、マスターブランチは安定したペースで成長しています。masterブランチからのすべての変更をfeatureブランチにマージして、そこから作業を継続したいのが理想ですが、どのようにこれにアプローチするのかはよくわかりません。 ブランチの両側で重要な変更を保持しながら、このマージを安全に実行するにはどうすればよいですか？

25 version-control  git  gitflow 

最近、私と私のチームがGitをどのように使用し、ワークフローがどのように機能するかを調べてきました。現在、機能ブランチワークフローを使用していますが、うまく機能しているようです。 また、私たちのチームの何人かの個人がgit stashに基づくワークフローを使用しているのを見ました。ワークフローは次のようになります。 メインブランチで作業する（などmaster） 進行中にコミットする 変更を取得するか、ブランチを切り替える必要がある場合は、コミットされていない変更をスタッシュにプッシュします 更新が完了したら、変更をスタッシュからポップします。 このワークフローは、機能ブランチワークフローの代わりに使用されることに言及する必要があります。ここでの開発者は、ブランチを取得して作業する代わりに、単一のブランチでのみ作業し、適切と思われるスタックからプッシュ/ポップします。 実際、これは素晴らしいワークフローではないと思うので、この方法でgit stashを使用するよりも分岐が適切です。git stashの価値は緊急操作として見ることができますが、毎日の通常のワークフローで使用することはできません。 git stashを定期的に使用することはアンチパターンと見なされますか？その場合、発生する可能性のある特定の問題は何ですか？そうでない場合、利点は何ですか？

25 git  teamwork  workflows 

私は最近、gitで2つのブランチをマージするときに、2つの隣接する行に変更がある場合、gitがこれを競合と宣言することを学びました。たとえば、ファイルtest.txtに次のコンテンツがある場合： Line 1: A Line 2: B Line 3: C Line 4: D ブランチでmasterはこれを Line 1: A Line 2: B1 Line 3: C Line 4: D ブランチでtestingはこれを Line 1: A Line 2: B Line 3: C1 Line 4: D その後、マージしようとするとtestingにmaster、Gitはマージ競合を宣言します。私の素朴な期待は、マージが競合せずに発生し、これをもたらすことでした： Line 1: A Line 2: B1 Line 3: C1 Line …

25 git  merging 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 ちょっとした文脈：私は大学3年生です。学生は4人のチームに分かれています。ほとんどの人はWindowsで作業しています（Linuxを使用している私のような少数の人を除く）。学校のカリキュラムの一環として、まもなく本物のクライアント向けのプロジェクトに取り掛かりますが、私と別のチームは、コードを相互に共有するのにどの方法が最適か疑問に思っています。 私は3年間パートタイムで働いており、さまざまなプロジェクトでgitとmercurialの両方を使用した経験が豊富なので、どちらのシステムを使用しても問題はありません。しかし、私のチームメートは誰もバージョン管理システムを使用したことがありません。SVNを使用しようとしたが、大きな問題があり、他の何かを試してみたいと思う別のチームもいるので、彼らは私の意見を求めました。 私の考え：Mercurial + TortoiseHgはWindowsの下でより良く統合されていると聞いたことがありますが、匿名の頭の概念が説明しても混乱させるのではないかと思っています。一方で、初心者にとってはgitブランチの方が理解しやすい（各プログラマーの作業が明確に分離されている）が、Windowsではうまく機能しないことがわかりました。

25 version-control  git  mercurial 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 今まで、Git / Githubの基本的な概念のほとんどを理解していましたが、全体像を理解するのはまだ困難です。 これらは私がこれまでに何とか作業を始めたものです。 コミットをプッシュする ブランチで作業する Githubを継続的な統合システムであるTravis CIと統合する Travis CIを介して、マスターへのコミットごとに自動的にビルドし、リリースをGithubのリリースとしてZIPとしてリリースします。 しかし、私はこれまでにプロジェクトのアルファ版またはベータ版にしか取り組んでいなかったため、実際にバージョン付きリリースを見たことはありません。 したがって、バージョン管理、個別のバージョンの維持、バージョンの修正プログラムなどについて詳しく知りたいと思います。 次のことが起こるようにするにはどうすればよいですか： 私のプロジェクトの異なるバージョン、たとえばバージョン1.1.0と2.0.0を持っている バージョンの修正プログラムをプッシュしたり、バージョンを1.1.1や2.0.1に変更したりすることができます。 継続的統合システムがコミット時にそのバージョンを自動的にビルドし、成功した場合は、その特定のバージョンのリリースを公開します。 私は次のオプションの間で疑っています： バージョンごとにタグを使用する必要がありますか？もしそうなら、継続的インテグレーションシステムはどのようにしてリリースを自動的にビルドできますか？ バージョンごとにブランチを作成する必要がありますか？もしそうなら、それはたくさんのブランチを作成しませんか（1.1や2.0ブランチのように、もちろんホットフィックスはそのブランチに行きます） バージョン番号はどのように指定しますか？バージョン番号を指定する構成ファイルを用意しても大丈夫ですか、それとももっと賢い方法がありますか？この場合、それが重要であれば、Javaプロジェクトになります。

24 version-control  git  github  continuous-integration 

ある日、私はGitを使用しており（まだ使用しています）、コミット中に電気が切れました。 私（実際には電気）が戻ったとき、gitリポジトリは破損していました。正確な名前は覚えていませんが、「無効なref」などのようなものでした。 操作の途中でコミットが中断されたと推測するのは簡単です（インデックスの追加を自動的に行うIntelliJを使用してコミットしていました）。また、実際には、「commit」は同じ名前のDBMS操作ほどACIDではないことを推測するのは簡単でした。 Q：レポ変更操作が原子性を尊重するようにする方法はありますか？すなわち、電気が再び落ちて、私がコミットしている場合、ファイルシステムが破損した状態にならないようにしたいです。

24 git 

私は最近、自分のコードをバージョン管理下に置き始めました（私が働いているラボではSVNで、自分のコードはgithubで（明らかにgitで））。バージョン管理を使用する前に、私はこのようなことをしていました。バージョン番号の付いた多くのフォルダーの中に、ライブラリーの名前のフォルダーがありました。新しいバージョンで作業を開始するたびに、最後のバージョンのコピーを作成し、名前を新しいバージョンに変更して実装を開始します。 ただし、フォルダがバージョン管理下に置かれている場合、これはかなり冗長に思えます。冗長性は別として、誰かが最新バージョンを入手したい場合、彼import/ 彼女たちがちょうどあればすべてのバージョンをダウンロードするでしょうclone。 現在、バージョン管理を使用してこれを行う多くの方法を見ていますが、私はそれが初めてなので、どちらがより保守可能かはわかりません。 方法1：タグを使用する 私がタグを正しく理解していれば、メインブランチがあります。取得した変更をコミットし、バージョンでタグ付けします。次に、作業コピーを取得したい場合は、特定のタグが付いたコピーを取得します。（間違っている場合は修正してください） 方法2：分岐バージョン この方法では、メインブランチは開発ブランチになります。時々、安定したバージョンがv1.2.0作成されるとしましょう（たとえば）、そのバージョンのブランチを作成し、コミットしません。そうすれば、特定のバージョンをダウンロードする場合、そのブランチからコードを取得できます。私はあなたがそれにコミットすることは決してないと言ったが、バグ修正を行い、古いバージョンのブランチにコミットして古いバージョンを実行し続けることが可能かもしれない。現在のバージョンがある場合たとえばv2.0、しかし、使用したい人がいるv1.2、あなたはから別のブランチを取得することができv1.2、すなわち、v1.2.1およびバグ修正をコミット、またはちょうど同じバージョンを保持v1.2し、単にバグ修正をコミットします。 したがって、ブランチは次のようになります。 v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / -------------------------------------- dev このようにして、マイナーバージョンアップデートごとにブランチを作成できます。（上のグラフでは、v1.2.1とv1.2.2、またはv2.0.0のリリース後に作成されたため、v1.2.0とv2.0.0の間の開発の一部ではないことに注意してください。古いバージョンのサポートと考えてください） 方法3：分岐開発 この方法は前の方法の反対です。メインブランチは最新の安定バージョンです。新しいバージョンで作業しているときは常に、（開発用の）ブランチを作成し、コードで作業し、安定しているときにメインブランチとマージします。 この場合、ブランチは次のようになります。 ________ ____ ________________ _____ dev / \/ \/ \/ ---------------------------------- latest_version おそらくこれはタグと組み合わせて行う必要がありますか？ 質問！ とにかく、私の質問はあなたの経験に基づいて、これらの方法のどれがより実用的であると証明しますか？そこに知られている最良の方法はありますか（おそらく私は自分自身を理解していなかった）？これらのことは一般的にどのように行われますか？

24 version-control  git  svn  branching  release-management 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 Gitは優れたバージョン管理システムです。優れたGUIサポートがないという事実を除外すると、本当に優れた高速です。しかし、Clearcaseのようなソース管理は、企業顧客を大規模にサポートしています。企業は、ソース管理サーバーとライセンス認証に多額の投資をしています。 最近、Googleのような大企業のほとんどは、他のバージョン管理システムよりもGitを採用しています。しかし、この会社には強力なオープンソースグループがあり、ツールの開発とサポートを一貫して提供しています（独自のGitのカスタムバージョンを持っている場合もあります）。同時に、大企業はオープンソースプロジェクトを採用し、それらに関連性を持たせることを本当に気にしていません。 Gitはエンタープライズ環境、特にWindowsプラットフォームで本当に信頼できるツールですか？ Gitはオープンソース製品であるため、Gitのサポートは問題です。 ソリューションとサポートを提供する会社はありますか？サーバーのコストは、クリアケースなどの他のバージョン管理と比較してどうですか？

24 open-source  version-control  git  clearcase 

修正または機能の作業をしているとき、数秒でその場で改善できる他の小さな問題に出くわすことがあります。すぐにそれらを行い、完成した機能/修正をコミットすると、コミットには複数のことが含まれます。たとえば"add feature X and code clean up"または"fix bug X and improved logging"。これを2つのコミットに分割することをお勧めします。同じファイルで2つの変更が発生した場合、1つのファイルを追加してコミットし、もう1つのファイルを追加してから再度コミットすることはできません。したがって、次の3つのオプションが表示されます。 何かに取り組んでいる間、無関係なものを故意に見落とします。 2つの変更を加えてファイルをコピーし、元に戻し、1つの変更を含めてコミットし、もう1つの変更を含めて再度コミットします。 関係のない小さなことは変更せずに、todoリストに追加して後で実行します。 次の理由により、3つのオプションのすべてが本当に好きではありません。 小さな問題を解決しないと、コードの品質が低下する可能性があります。そして、多くの努力をせずに何かを改善する機会を意識的に逃した場合、私は気分が悪いです。 これにより、手作業が増え、エラーが発生しやすくなります。 これはあまり手間がかからないTodoには問題ありませんが、ToDoリストに小さなアイテムを追加して後で再訪することは、すぐに修正するよりもはるかに時間がかかります。 そのような状況にどのように対処しますか？

23 version-control  git 

私はSOで読んだことだけを続けるので、許してくれますが、Subversionに対するGitの主な利点の1つは、Gitがすべてのソースコードをローカルで開発者に提供することであり、サーバー。 SVNとTortoiseSVNの使用が制限されているため、すべてのソースコードを入手できました。たとえば、私はウェブサイトを持っています。SVNにアップロードします。私はまだ自分のウェブサイトをローカルで実行していますよね？誰かが変更を送信し、接続していない場合は、サーバーに再接続するまで、Gitを使用しているかどうかは関係ありません。 わかりません。この1つの点を除いて、一方と他方の再ハッシュを要求していません。

23 git  svn 

それで、私はこの大きなプロジェクトを持っています。それは私によってリファクタリングされるプロセスにあります。私は多くのものを変更しているので、すぐにコンパイルする機会はありません。私は名前を付けた特別なgitブランチに住んでいますcleanup（masterもちろん、最終的にはマージされます）。 問題は、非コンパイルコードをコミットしないというポリシーがあることです（理想的には動作するはずですが、少なくともコンパイルしてリンクする必要があります）。そのため、この巨大なタスクを完了するまで、何もコミットできません（レビューまたは簿記のため）。 これは私が仕事をするのが好きな方法ではありません（ほとんどの人が少なくとも1日に1回程度コミットしていると思います）。 どう思いますか？私が見落としている解決策はありますか？ 後でコミットなどを集約するようにgitに指示できますか？ブランチに留まっている限り、コンパイルしないコミットで生きることができcleanupます。 編集 プッシュ/コミットの件名：私はそれが大きな違いであることを知っていますが、後で、私のものをにマージすると壊れたリビジョンがありますmaster。したがって、履歴を参照する（またはgit bisect...）場合、「ローカル」リビジョンは世界中からアクセス可能になります。したがって、ローカルでコミットするだけでプッシュするのは最善の解決策ではありません。それは後で問題が発生するからです（サブジェクトが閉じられ、しばらく忘れられた場合）。 要するに、ローカルコミットは最終的にプッシュされます。グローバル履歴には、コンパイルされていないコミットは表示されません。

23 git  refactoring 

編集は、次のようないくつかの類似した質問とは異なり、GitリポジトリへのマルチGBのSVNリポジトリの移動 や /programming/540535/managing-large-binary-files-with-gitを 私のシナリオでは、といういくつかのサブプロジェクトを含みません簡単にgitサブモジュールに変換することも、git-annexに適した非常に大きなバイナリファイルに変換することもできます。バイナリが、グラフィックなどのコンパイル時のアセットであるかのように、同じリビジョンのメインソースコードに密結合したテストスイートである単一のリポジトリです。 私は、svnから古い中/大サイズ（50ユーザー、60kリビジョン、80Gb履歴、2Gb作業コピー）のコードリポジトリの切り替えを調査しています。ユーザーの数が増えると、トランクに大量のチャーンが発生し、多くの場合、機能が複数のコミットに分散し、コードのレビューが困難になります。また、分岐せずに不良コードを「ゲート」する方法はありません。レビューはトランクにコミットされた後にのみ実行できます。私は代替案を調査しています。gitに移行できることを望んでいましたが、いくつか問題があります。 gitに関する限り、現在のリポジトリの問題はサイズです。そこには多くの古いクラフがあり、gitに変換するときに--filter-branchでクリーニングすると、サイズが1桁、つまり5〜10 GBに削減されます。これはまだ大きすぎます。リポジトリサイズが大きい最大の理由は、テストへの入力であるバイナリドキュメントが多数あることです。これらのファイルは.5mbと30mbの間で異なり、数百があります。また、非常に多くの変更があります。私はサブモジュールやgit-annexなどを見てきましたが、完全な履歴が必要な多くのファイルの別館があるのと同様に、サブモジュールでのテストが間違っていると感じています。 したがって、gitの分散された性質は、実際にGitを採用することを妨げるものです。分散についてはあまり気にしません。安価な分岐機能と強力なマージ機能が欲しいだけです。私がgitユーザーの99.9％がそうするように、私たちは祝福された裸の中央リポジトリを使用します。 gitを使用するときに各ユーザーが完全なローカル履歴を保持する必要がある理由を理解できませんか？ワークフローが分散化されていない場合、そのデータはユーザーのディスク上で何をしているのでしょうか？gitの最近のバージョンでは、最近の履歴のみを持つ浅いクローンを使用できることを知っています。私の質問は、これをチーム全体の標準操作モードとして実行することは可能ですか？gitを常に浅く設定して、完全な履歴のみを中央に持つことができますが、デフォルトではユーザーは履歴の1000回転しか持つことができませんか？もちろん、そのオプションは1000回転をgitに変換し、考古学のためにsvnリポジトリを保持することです。ただし、このシナリオでは、テストドキュメントの次の数千の改訂後に同じ問題が再び発生します。 あなたがいることを多くのバイナリファイルを含む大規模なレポでのgitを使用するための優れたベストプラクティスは何であるかの履歴をしたいの？ほとんどのベストプラクティスとチュートリアルは、このケースを回避するようです。少数の巨大なバイナリの問題を解決するか、バイナリを完全に削除することを提案します。 浅いクローニングは通常の操作モードとして使用できますか、それとも「ハック」ですか？ メインソースリビジョンとサブモジュールリビジョンの間に強い依存関係があるコードにサブモジュールを使用できますか（コンパイル時のバイナリ依存関係、ユニットテストスイートなど）。 gitリポジトリ（オンプレミス）の「大きすぎる」とはどのくらいですか？4GBまで下げることができたら、切り替えを避けるべきですか？2GB？

23 git  svn 

私たちは、同じgitリポジトリで複数のプロジェクトに取り組んでいる大きなチーム（10〜12人の開発者と4人のqa）です。そのスプリングブートベースのバックエンドWebサービス。優れたgit分岐および展開戦略を探しています。また、機能が期待どおりに機能することを保証するqaチームもあります（ある程度のバグはありません）。 いくつかの記事を読んだ後、Gitflowモデルは私たちにとってうまく機能するだろうと感じました。ここに私の質問が来ます。 QAチームはどこで機能をテストする必要がありますか？ 彼らが機能ブランチでテストすれば、彼らはバグを発生させ、開発者はそれを修正し、それがQAテストに合格したら、開発のためにマージします。また、QAは開発ブランチで整数化テストを再度行います。 すべての機能をマージして（ユニットテストと開発者による基本的なテストの後）ブランチを開発し、そこからqaテストを行います。修正とテストもすべて開発中に行われます。 他の人にとってどのアプローチがうまくいったのか知りたいです。

23 testing  git  branching  qa  gitflow 

私たちはプロジェクトでGitHub Flowを使用し、ほとんどの場合、masterから新しい機能ブランチを開き、そこで作業を行い、PRを開き、コードを確認してmasterにマージします。 しかし、私の現在の仕事はで取り組んでいる別の問題に依存していfeature-branch-Aます。他のブランチからブランチを作成するのはコーシャーですか、それともGitHub Flowの精神に反するものですか？ 別の方法は、私のブランチをマスターに基づいて、feature-branch-A（頻繁に）変更をマージすることです。 GitHubフローではどのオプションが推奨されますか？

22 git  github  gitflow