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

GitはオープンソースのDVCS(分散バージョン管理システム)です

1
リリースブランチをマスターにマージする必要があります
私のチームはGit Stable Mainlineブランチモデルを使用しており、最初のリリースブランチを作成しようとしています。これまで読んだことから、リリースブランチはマスターブランチからサイロ化されており、完全にマスターにマージされることはないようです。代わりに、リリースブランチで修正が行われた場合、通常はマスターブランチにチェリーピックされます。現在のリリースを次のリリースの開発から完全に分離したまま、現在のリリースの準備と同時にマスターで次の機能セットを開発できるようにしたいので、これは私にとって意味があります。 これらのリリースブランチはどのくらいの期間保持する必要がありますか?それらを完全にマスターに戻す必要がある場合はありますか?

1
古いブランチのトランクからのバグ修正をマージ
私は現在、私の会社でsvnからgitへの切り替えの過程にあります(1年後に、人々を説得するために費やしました!)。 これまでのところ、これですべてが良くなりますが、私たちが現在ワークフローに持っている小さなものの1つで、私には適切な同等のものを見つけることができません。 現在、すべての開発者はマスターで作業しています。四半期ごとに、マスターをXxブランチにブランチします。Xxブランチは後で最新のリリースになります。これは、svnリポジトリが次のようになることを意味します。 トランク 枝 3.8 4.1 4.2 ... 実際にはタグを使用しません。 時々、発見された緊急のバグ修正があります。 私たちがそれを行う現在の方法は次のとおりです。 マスターで修正する SVNは、関連するコミットの範囲を関連するブランチにマージします(おそらく、最新のリリースなど)。 私たちは宇宙産業にいるので、支社は長命であり、顧客のアップグレードプロセスはかなり長いので、これまでのところ、そのように取り組んできました。 さて、gitでどのようにして良い同等物でしょうか? これまでのところ、マスターから生成されたブランチのバグを修正してから、このブランチをマスターと4.3にマージしました(たとえば)。ことは、ホットフィックスブランチにはマスター履歴が含まれており、マスターと4.3の間のすべてのコミットもマージされるためですが、これは不要です。 これまでに考えたこと: 私は非常に成功したGitワークフローメソッドを見てきましたが、それらの解決策は、リリースブランチのバグを修正して、逆にマージするのではなく、マージすることです。これは私たちのケースではうまくいくかもしれませんが、実際にバグを修正する前に、バグを修正したい最も古いブランチをすでに知っている必要があるため、かなり面倒です。 もう1つの解決策は、マスターで修正してからコミットを選択することです(今日のsvnマージの場合と同様)。ここでの厄介なことは、この場合、チェリーピックが新しいコミットのように見え、関係が失われるため、マージされたものの履歴がどこで失われるかということです。 それを行うための「良い」方法は何ですか?履歴のコミットを修正するか、チェリーピックを使用して、マージされたものや他の何かを手動で追跡する必要がありますか? gitでの制作経験がほとんどない場合、私は何かを見逃している可能性があります。
9 git  svn  branching 

3
gitなどのバージョン管理システムでコミットをグループ化するにはどうすればよいですか
1つの長いフラットなコミット履歴の代わりに、階層がないのはなぜですか。そのため、トップレベルでプルリクエストがあり、レベルを下げてそのPRのコミットを確認できます。PRはgithubに固有のものであると思いますが、あなたはそのアイデアを理解しています。たとえば、いくつかのコミットを機能やバグ修正としてグループ化することを意味します。 確かに、コミット履歴をナビゲートしやすくなります。 この質問には明白な答えがあると思いますが、それを見つけることができないようです。

2
GITをリポジトリとして使用する場合のコードレビュープロセス?
GITを使用する場合のコードレビューの最適なプロセスは何ですか?外部GITプロバイダー(Unfuddle)があり、リソース使用量に上限があります。そのため、すべての開発者に専用のリモートリポジトリを用意することはできません。 現在のプロセス: master誰もがコミットするブランチを持つGITサーバーがあります 開発者はローカルmasterミラーまたはローカル機能ブランチから作業します 開発者がサーバーのmasterブランチにプッシュ 開発者は最後のコミット時にコードレビューをリクエストする 問題: コードレビューのすべてのバグは、それがキャッチされるまでにすでにマスターにあります。 さらに悪いことに、通常、誰かが何が起こったのかを理解しようとして数時間火傷しました... ですので、 コードを実行するには、「マスター」に配信する前に確認してください。 グローバルチームと連携するプロセスを用意する(肩のレビューではありません!) 個人の開発者が自分のデスク/マシンに電源を入れて他の誰かがリモートでアクセスできるようにする必要がないもの(人間の依存関係を削除し、開発者が異なるタイムゾーンで家に帰る) TortoiseGITを使用して、変更されたファイルのリスト、ファイルの差分などを視覚的に表現します。GUIが十分でない場合、GITシェルにドロップする人もいますが、理想的には、ワークフローをシンプルでGUIベースにしたい(私は私のツールではなく、あらゆる負担を取り除くツールを求めています)。

2
ソース管理における機密情報のベストプラクティス
このトピックはかなり取り上げられていますが、自分の特定の状況に対する答えを見つけることができません。 現在、私は.gitignore機密コンテンツを除外し、それ(構成ファイルなど)を個別に保持するために使用しています。私のコードベースがますます多くのプロジェクトに拡大するにつれて、これは管理が非常に難しくなり、変更を追跡したり、ファイルを適切にバックアップしたりする実際の方法もありません。 そこにこの問題のためのいくつかのツールのような、ではないgit-secret、Hashicorp Vaultとgit-crypt私は(さまざまな理由のために)私の開発のすべてを行うのWindows、これらの作品のどれも。 現在、私は自社内で作業する唯一の開発者であり、拡張する予定はありません。ソース管理(Gitlab)は、主に自分の参照と変更を記録する機能に使用されます。いくつかの接続文字列または構成ファイルをソース管理にプッシュすることは、大きな問題またはリスクになるでしょうか?その情報は現在、セキュリティで保護されていないネットワークドライブにあります(NTFSアクセス許可を除く) 私は、ベストプラクティスはこのようなものをソース管理にプッシュすることではないという考えを得ますが、ローカルネットワークの外部ではアクセスできないプライベートにホストされたGitlabインスタンスがあります-これはリスクが少ないことを意味しますか?
8 git  security 

2
GitHub Flowはマスターにマージする前に本番環境にデプロイします:2番目の機能が最初の機能をオーバーライドしませんか?
GitHubフローを理解するために、ここで見られるように、コードレビューの後、機能は最初に本番環境にデプロイされ、次にマスターにマージされます。 最初の機能と同じコミットから分岐した2番目の機能があり、それも本番に直接デプロイされている場合、本番には最初の機能が含まれなくなります。 learngitbranching.js.orgで作成 c2がデプロイされたら、c2またはc4とマージする前にc3をどのようにデプロイできますか? GitHub Flowはこの問題をどのように処理しますか? 明白な解決策は、本番環境にデプロイする前に、機能をマスターにリベースする必要があることです。ただし、これは人為的なミスが発生しやすくなります。リベースを忘れた場合、プロダクションには機能がありません。 特にGitHub Flowの使用経験のある方からの回答をお願いします。どのようにこの問題を抱えていませんか?
8 git 

5
他人の作業を元に戻すためのエチケット
最近、チームメイトと「元に戻す前に相談していない」との議論がありました。「馬鹿のように見える」からです。(コンテキストについては、これは大学のプロジェクトであり、元に戻すのはコードの配置でした。) これは私に不思議に思います:元に戻す必要があることをコミッターに知らせるための規範は何ですか?どのようにして、ハードフィーリングを扇動せずにこのコミットを元に戻す必要があると彼らに伝えますか?
8 git  etiquette 

1
ソース管理された環境でのコード署名の処理
簡単な質問ですが、うまくいけば: 私のチームは、ClickOnce配置を使用し、証明書で署名されたソフトウェアを管理しています。署名のみに使用される別のマシンで実際に使用される公開証明書を保持します。それはうまくいきます。 ただし、問題が時折発生するのは、誰かがソリューションを構築してテストできるように、誰かが新しいテスト証明書でローカルに署名する必要がある場合です。必然的に、この新しい証明書のフィンガープリントは、プロジェクト設定ファイルの一部としてバージョン管理にプッシュされます。独自の証明書設定がGitサーバーにプッシュされることはないため、署名ボックスで問題が発生することはなく、そのマシンからのプルによってローカルの変更が上書きされることはありません。ただし、ローカルマシンで使用される独自のテスト証明書を持っているため、他のすべての人に問題が発生します。 この状況を処理する正しい方法はありますか?おそらく、Gitで変更を全体ではなく構成ファイルの特定の部分のみから除外する方法があるでしょうか?
8 git 

3
誤ってコミットに無関係な変更を含める
私のgitコミットへの個人的なアプローチは、すべてのコミットがその完全性に変更の単位を含める必要があるということです。 私が開発するとき、私は通常そのようなユニットに焦点を合わせます。しかし、時々、私の注意がどこか他の場所に迷子になり、しばらくの間別のユニットで作業します。これはおそらく最適ではありませんgit add --interactiveが、慎重にコミットすることを学びました(私の良い友達です)。 ただし、変更を選択的にステージングするのを忘れて、代わりにファイル全体をコミットする場合があります。diffに表示されるすべての変更は、実際には同じユニットに関連していると信じています。 それから私git push。 これは危険ですか?意図した変更のみが含まれるようにコミットを修正するよう努力する必要がありますか?私の主な懸念は、歴史を見る他の誰もが変更を目にし、おそらくそれが間違いであることに気付く前に数分間頭を掻くでしょう。さらに悪いことに、変更が関連しているように見え、プログラマーがエラーを認識しない可能性があることは想像できます。 問題は、すでにプッシュしているため、サーバーの履歴を安全に書き換えることができないため、おそらく最初にコミットを元に戻して、適切に分割して再度コミットする必要があるでしょう。または、コミットをより適切なコミットメッセージで修正することもできますが、履歴の書き換えも必要になるため、本当に高速でなければなりません。最後の手段として、私が取り組んでいるユニットを次のようにコミットするだけで、以前のコミットに関連する変更があることに注意してください(ただし、これは間違っていると感じています)。 適切なコードレビューワークフローを備えたマルチ開発者の設定では、これが発生しない可能性があることを理解しています。私がプロジェクトの唯一の開発者である場合、履歴を書き換えることがこれに対する最良の解決策であることも理解しています。
8 git 

1
Git-FlowでGrid of Doom™を回避する
私のプロジェクトはGit Flow分岐モデルに従っています。開発はで行われdevelop、masterリリースにマージされ、タグが付けられます。修正プログラムは、現在のブランチから分岐しmasterます。 ただし、現在の開発では修正プログラムも必要なので、各修正プログラムのブランチもマージさdevelopれます。 これにより、非常に見苦しいリビジョングラフが作成されます。特に、開発/ホットフィックスは、短い時間枠で頻繁にマージされます。 これは一般にGit-Flowで発生する問題ですか?簡単な修正はありますか?
8 git  gitflow 

3
Git、セマンティックバージョニング、およびそれが(私の)典型的な開発タイムラインにどのように適合するか?
Q&Aシステムに取り組んでいて、現在のアプリケーションに最初の公式バージョン/タグとして「1.0.0」のタグを付けようとしています。ベータテストのために、次に限定されたテスト対象者にロールアウトするところです。この段階で「1.0.0」は正しいですか? また、その段階で多くのバグが見つかることは間違いありません。「1.0.0」のままにしておきますが、リリースされるまでタグを強制的に移動します。または、バグを修正したら、新しいタグ「1.0.1」を付けますか。その後、おそらく「1.0.2」のテストを繰り返します。 したがって、拡張機能(たとえば、新しいメニュー、新しい検索入力フィールドなどの新機能)に取り組む場合、これらは「1.0.0」から「1.1.0」へのように小さな変更でしょうか?

2
Gitにタグがあるのはなぜですか?
私はGitの分岐とタグ付けのベストプラクティスとgitタグ付けのコメント-ベストプラクティスを読みましたが、長い間疑問に思っていたものに対する直接的な回答がありません。 Gitにタグがあるのはなぜですか?(枝だけではなく) 彼らは二流の市民、または少なくとも「異なる」ようです。明示的に指定しない限り、プッシュされません。リモートタグを削除しても、ダウンストリームレポジトリは削除されません。 この最後のポイントは最近問題になりました。誰かが別のリポジトリからの大量のコミットで大量のガベージタグをプッシュしたためです。上流でそれらを削除してコミットをgit push --tagsGCすることもできますが、それは反映されず、次に誰かがでタグをプッシュしたときに、それらのガベージタグとコミットを再プッシュします。そのため、全員が削除したことを確認する必要がありました。 いつ、なぜブランチではなくタグを使用するのですか?

2
なぜGitのstashコミットには2つの親が必要なのですか?
なぜGitのstashコミットには2つの親が必要なのですか? でGitのハッカーの手引き、私はスタッシュのために、このメンタルモデルを参照してください。 ガイドによると、stash @ {0}にはAとBの両方が親として必要です。どうして?stashがCの必要性をなくしてBを指しているのはなぜですか?Gitの理解に何か欠けていると思います。
8 git  concepts 

1
アップストリームがプルしない機能ブランチを持つフォークされたgitリポジトリを維持する方法は?
これがGithubの典型的なワークフローです... いくつかのプロジェクトのように->それをフォークし-> git clone https://github.com/you/someprojectます。 プロジェクトを開きます。あなたが見るものに似ていますが、いくつか変更を加えます。 feature-branch(git checkout -b some-feature)でのみ機能するように注意して、Githubフォークにupstreamプッシュした後、メンテナーにプルリクエストを出すことにしましたfeature-branch。 メンテナは、何らかの理由でプルを拒否します。 たとえば、上記のシナリオに一致する、失敗したプルリクエストは次のとおりです。.. 今一般的にメンテナ場合、HADがマージプル...ワークフローがシンプルになります...私のローカルマシン上で、私は何でも上の任意のローカルの変更コミットするだろうfeature-branch、私は一度にあったし... git fetch --all、git checkout master、git pull upstream --ff-only。次に、必要に応じて、その上で変更を再生します... だが... 私のフォークへの変更を無理なく続けていきたいと決心した場合はどうなりますかupstream?それでも、発生した変更を追跡してマージできるようにしたいですか?通常、私はあなたが維持することができますどのように..機能ブランチを削除して、自分の道に行くとmaster、マージされた上流ことすることができ、まだから「永久に切り離さ」されながら、あなたのフォークの機能を維持し、分岐upstreamのをHEAD?

3
中央開発サーバー(LAMP)でバージョン管理を管理する
私は最大5人の(ウェブ)開発者がいる小さなチームで働いています。私たちのチームは頻繁に成長しており、複数の人が同じコードで作業しているときに問題が発生したため、VCSをセットアップすることにしました。 現在の状況 現在、中央開発サーバー(LAMP)を使用しています。したがって、すべての開発者が同じコードベースで作業し、コードがテストされてライブサーバーの準備ができている場合は、ftp経由でコードをコピーするだけです。私はこれがanno 1600ワークフローの一種であることを知っていますが、そうです。それが何であるか、そしてこの質問の理由でもあります。 開発サーバーでは、ディレクトリ構造は次のようになります。 /var/www /Project1 /Project2 /Project3 ... さらに、いくつかの小さな非Webアプリケーション-Android / iPhone / Windows 8などのアプリといくつかのC#ツールもあり、これらもVCSに含める必要があります。 目標と問題 私たちの目標は、VCSのクリーンセットアップを取得することです。VCSは、問題追跡ソフトウェアと連携し、コードを上書きせずに同じプロジェクトで同時に作業できるようにし、バージョン管理の利点を提供します。 私たちにとっての最初の質問は、どのテクノロジーを使うべきかということだと思います。私たちの一部は、すでに転覆を経験しています。しかし、gitはある種の「標準」になり、多くの「プロgit」の議論がWebユーザーの間で存在するため、私たちはgitを使用する傾向があります。 不確実性が始まります。git-分散型VCS-を使用する場合、各開発者のコ​​ンピューターで別個の開発サーバーの使用を開始する必要があるようです。それに関する問題は次のとおりです。 ときどき別のコンピューターで作業するため、コードのプッシュを忘れると問題が発生します。 開発サーバーはライブサーバーと同じである必要があるため、仮想マシンで作業する必要があります(これは私たちの環境では強制できないため、不可能だと信じています)。 開発サーバーは通常、「トライアウト」または「プレゼンテーション」サーバーとしても機能し、開発者以外の人が何が起こっているのかを確認できました。 単一の(!)開発サーバーを使用しながらシステムから利益を得ることができるように、gitで別の可能なセットアップはありますか?たぶん、開発者ごとに異なるディレクトリがあります。または、作業中のファイルをロックし、リポジトリにコミットして、同じコードベースで作業することはできますか?それが私たちにとっての要因になった一方で、複数の開発者がアプリケーションの同じ部分で同時に作業することはまだ珍しいと言うことが重要かもしれません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.