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

Gitは、オープンソースの分散バージョン管理システム(DVCS)です。このタグは、Gitの使用法とワークフローに関連する質問に使用します。単にリポジトリがGitHubでホストされているからといって、Git関連の問題には[github]タグを使用しないでください。また、Gitリポジトリが関係する一般的なプログラミングの質問には、このタグを使用しないでください。

5
名前を変更したファイルのログをgitで本当に表示するにはどうすればよいですか?
私はgitに比較的慣れていません。以前にSubversionを使用しました。 ほとんどのグラフィカルgitフロントエンドとIDEプラグインは、ファイルの名前が変更されている場合、ファイルの履歴を表示できないようです。私が使うとき git log --follow コマンドラインでは、名前を変更してもログ全体を確認できます。 Linus Torvalds氏によると、-followスイッチは「SVN noob」を喜ばせるものであり、深刻なgitユーザーはそれを使用しません。 --followは完全なハックであり、親子関係や素敵なリビジョングラフなどについて何も知らなかった元SVNユーザーを満足させるだけのものです。 これは完全に基本的なものではありませんが、「-follow」の現在の実装は、実際に不可欠なものではなく、リビジョンウォーキングロジックにボルトで固定された迅速な前処理です。 それは文字通り、「実際のgit機能」としてではなく、「SVN noob」を満足させるものとして設計されました。アイデアは、全体像で問題の名前を変更するという(壊れた)思考の考え方から逃れることでした。 私の質問:名前が変更されたときに、ハードコアのgitユーザーがファイルの履歴をどのように取得しますか?これを行う「本当の」方法は何ですか?
132 git 

6
ローカル変更を維持するgit pull
アップストリームの変更がある場合でも、特定のファイルを変更せずにgitプロジェクトを安全に更新(プル)するにはどうすればよいですか? myrepo / config / config.php このファイルがリモートで変更されていたとしても、git pullすると他のすべてが更新されますが、このファイルは変更されていません(マージされていません)。 PS。私はgitベースのデプロイスクリプトを作成しているだけなので、私が求めていることを行う必要があります。設定ファイルをテンプレートに変更できません。 そのため、ローカルで変更された内容を失わない更新スクリプトを作成する方法が必要です。私は次のような単純なものを望んでいました: git assume-remote-unchanged file1 git assume-remote-unchanged file2 その後 git pull
132 git 

5
Git:フェッチ専用のリモートをセットアップしますか?
git remote -vリモートが構成されているGitリポジトリの1つで実行すると、各リモートにフェッチ仕様とプッシュ仕様の両方があることがわかります。 $ git remote -v <remote-name> ssh://host/path/to/repo (fetch) <remote-name> ssh://host/path/to/repo (push) ピア開発者をポイントするリモートの場合、プッシュする必要はありません。Gitは、とにかく裸でないリポジトリへのプッシュを拒否します。これらのリモートをプッシュアドレスや機能のない「フェッチ専用」として構成する方法はありますか?
132 git  workflow 


10
キー指紋のためHerokuにプッシュできません
私はRailsを初めて使い、非常にシンプルなアプリをHerokuにデプロイしようとしていました。これは私がデプロイした2番目のアプリで、最初のアプリは問題なく実行できました。しかし、私はこれでいくつかの問題を抱えています。「git push heroku master」を実行すると、常に次のエラーが発生します。 !指紋がxx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xxのキーは、my_heroku_appへのアクセスが許可されていません。 致命的:リモートエンドが突然ハングアップした herokuにログインした後、キーを管理しようとしました。コンソールに「heroku keys」と入力すると、次のようになります。 myemailaddressのキーがありません。 ただし、コマンド「heroku keys:add」を実行すると、 既存の公開鍵が見つかりました:/Users/michele/.ssh/id_rsa.pub ssh公開鍵のアップロード/Users/michele/.ssh/id_rsa.pub!指紋はすでに存在しています。Herokuアカウントごとに1つのSSHキーを使用してください 私を助けてください!これは非常にイライラします、何が悪いのかわかりません!ありがとうございました
131 git  heroku  ssh  git-push 

7
Google Code Subversionリポジトリをフォークし、GitHubに同期します
書き込みアクセス権のないGoogle Code Subversionリポジトリとフォークして、GitHubリポジトリに同期するにはどうすればよいですか? 私は自分のGitリポジトリーで独自の機能を開発できるようにしたいのですが、Google Code Subversionリポジトリーと同期したいと思っています。Google Codeプロジェクト側からフィックスをフェッチする。 私はgit-svnについて知っており、私が完全に制御したSubversionリポジトリにアップダウンストリームする前にそれを使用しました。しかし、Google Code Subversionリポジトリと同期を保つ方法がわかりません。
131 svn  git  github 

2
最初のコミットを参照するには?
リポジトリの最初のコミットを参照する必要があるスクリプトがあります。gitには特別な参照HEADがありますが、対応するはありませんTAIL。git help rev-parse助けになりそうなものは何も見つかりません。 これが私がしたいことです: git show TAIL ここに私が持っている1つのオプションがあります: git show `git log --reverse | if read a commit ; then echo $commit ; fi` これはかなりハックで、変更されないgit logの出力に依存しています。 現在、私は最初のコミットにタグを付け、それを自分のrefspecとして使用しています。ただし、一般的なツールをリリースしたいので、あまり良い方法ではありません。
131 git  git-commit 

7
Gitでは、現在のコミットハッシュを同じコミットのファイルにどのように書き込むことができますか
私はここでGitフックを使って空想的なことをやろうとしていますが、どうすればよいのか(あるいはそれが可能かどうか)はわかりません。 私がする必要があるのは、すべてのコミットでそのハッシュを取得し、このハッシュでコミット内のファイルを更新することです。 何か案は?
131 git  hook 

11
GitブランチとRailsマイグレーションの操作方法
私はかなりの数のgitブランチを持つRailsアプリに取り組んでおり、それらの多くにはdbマイグレーションが含まれています。注意を払いますが、マスターのコードの一部が、別のブランチで削除/名前変更された列を要求することがあります。 gitブランチをDB状態と「結合」するための良い解決策は何でしょうか? これらの「状態」は実際にはどうなりますか? サイズが数GBのデータベースを複製することはできません。 そして、マージはどうなりますか? ソリューションはnoSQLデータベースにも変換されますか? 現在、MySQL、mongodb、およびredisを使用しています 編集:私は非常に重要なポイントを言及するのを忘れたように見えます、私は開発環境にのみ興味がありますが、大規模なデータベース(サイズが数GB)があります。


7
git:メッセージの入力中にコミットを中止する
私はコミットの最中です。コミットメッセージをvimに入力しました。今、何かを変える必要があることを思い出しました。私がやりたいことを達成する他のオプションがあることを理解していますが、コミットを中止する方法があるかどうかを知りながら、これまでに入力したコミットメッセージを保存します。
131 git 

4
Gitリベースのマージ競合は続行できません
私は「マスター」ブランチに追いつくために「dev」をリベースしようとしています。 $ git checkout dev $ git rebase master First, rewinding head to replay your work on top of it... Applying: Corrected compilation problems that came from conversion from SVN. Using index info to reconstruct a base tree... M src/com/.... <stdin>:125: trailing whitespace. /** <stdin>:126: trailing whitespace. * <stdin>:127: trailing …
131 git  git-rebase 

6
リベース後にブランチにプッシュできません
gitを使用し、masterブランチとdeveloperブランチがあります。新しい機能を追加してから、コミットをマスターにリベースし、マスターをCIサーバーにプッシュする必要があります。 問題は、リベース中に競合が発生した場合、リベースが完了した後、リモートブランチをプルするまで、(Github上の)リモート開発者ブランチにプッシュできないことです。これにより、コミットが重複します。競合がない場合、期待どおりに動作します。 質問:リベースと競合の解決後、重複したコミットを作成せずにローカルおよびリモートの開発ブランチを同期するにはどうすればよいですか セットアップ: // master branch is the main branch git checkout master git checkout -b myNewFeature // I will work on this at work and at home git push origin myNewFeature // work work work on myNewFeature // master branch has been updated and will conflict with myNewFeature …

6
テスト/ QAプロセスと統合されたGit分岐戦略
私たちの開発チームはGitFlow分岐戦略を使用してきました。 最近、ソフトウェアの品質を向上させるために、テスターを数名採用しました。アイデアは、すべての機能がテスターに​​よってテスト/ QAされるべきであるということです。 以前は、開発者は別々の機能ブランチで機能に取り組みdevelop、完了したらそれらをブランチにマージします。開発者は自分の作業をそのfeatureブランチで自分でテストします。今、テスターと一緒に、私たちはこの質問をし始めます テスターはどのブランチで新機能をテストする必要がありますか? 明らかに、2つのオプションがあります。 個々の機能ブランチ 上のdevelop枝 開発ブランチでのテスト 最初は、これが確実な方法であると信じていました。 この機能は、develop開発が始まってからブランチにマージされた他のすべての機能でテストされます。 競合は早期に検出できます これにより、テスターの作業が簡単になり、develop常に1つのブランチ()のみを処理します。彼は開発者に、どのブランチがどの機能に対応するかを尋ねる必要はありません(機能ブランチは、関連する開発者が独占的に自由に管理する個人のブランチです) これに関する最大の問題は次のとおりです。 developブランチはバグで汚染されています。 テスターはバグまたは競合を発見すると、開発者に報告し、開発ブランチで問題を修正します(機能ブランチはマージされると中止されました)。その後、さらに修正が必要になる場合があります。複数のサブシーケンスのコミットまたはマージ(developバグを修正するためにブランチからブランチが再作成される場合)はdevelop、可能であればブランチからの機能のロールバックを非常に困難にします。developブランチにマージされ、ブランチで修正される複数の機能があります。これは、developブランチの一部の機能のみを含むリリースを作成するときに大きな問題を引き起こします 機能ブランチでのテスト そこで、もう一度考えて、機能ブランチで機能をテストする必要があると判断しました。テストする前に、developブランチからの変更を機能ブランチにマージします(ブランチに追いつきますdevelop)。これはいい: あなたはまだ主流の他の機能で機能をテストします さらなる開発(バグの修正、競合の解決など)によってdevelopブランチが汚染されることはありません。 完全にテストおよび承認されるまで、機能をリリースしないことを簡単に決定できます。 ただし、いくつかの欠点があります テスターはコードのマージを行う必要があり、競合がある場合(非常に可能性が高い)、開発者に支援を依頼する必要があります。当社のテスターはテストを専門としており、コーディングはできません。 機能は、別の新しい機能がなくてもテストできます。たとえば、機能AとBは両方とも同時にテスト中ですが、どちらもdevelopブランチにマージされていないため、2つの機能は互いに認識していません。つまりdevelop、両方の機能が開発ブランチにマージされたときに、ブランチに対して再度テストする必要があります。そして、これを将来テストすることを忘れないでください。 機能AとBの両方がテストおよび承認されているが、マージされたときに競合が特定された場合、両方の機能の開発者は両方とも、テストを通過した機能ブランチであるため、自分自身の障害/ジョブではないと考えます。コミュニケーションには余分なオーバーヘッドがあり、競合を解決する人がいらいらすることもあります。 上記は私たちの物語です。リソースが限られているため、どこでもすべてをテストすることは避けたいと思います。私たちはこれに対処するためのより良い方法をまだ探しています。他のチームがこの種の状況をどのように処理するかを聞きたいです。
131 git  testing  qa  git-flow 


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