git push時に表示されるwarning: `push.default is unset...`の意味と解決方法 - Qiita
git push時に表示されるwarning: `push.default is unset...`の意味と解決方法Git $ g push warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default
Git Submodule の代替: Git Subtree | Atlassian Japan 公式ブログ | アトラシアン株式会社
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか？ 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
git subtreeの練習
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
gitで未追跡（untracked)なファイルもまとめて退避(stash)する - Qiita
stash便利ですよね git stashを使えば作業中のファイルを一旦退避させておいて、別のブランチで作業し、その後また戻ってきて再開するってことができますね。 $ git branch * original hogehoge master # 作業中のファイルを一旦退避 $ git stash # 退避できたか確認してみる $ git stash list # ブランチ変更 $ git checkout hogehoge $ ~hogehogeブランチでなんか開発作業~ # ブランチを元に戻す $ git checkout original # 退避を元に戻す $ git stash pop でもstashってtrackedなファイルだけなんでしょ・・・・ git stashだと追跡してる(tracked)なファイルだけを退避してくれます。 なので追跡してない(addしてない）ファイル
[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法 - Qiita
[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法Git新人プログラマ応援 1. gitの基礎（言葉の意味） ワーキングツリー[working tree]：最新のファイルの状態 インデックス[index]（ステージ[stage]）：コミットするためのファイルの状態 ローカルリポジトリ[local repository]：ファイルの変更履歴を記録（手元で管理） ヘッド[HEAD]：最新のコミットの状態 リモートリポジトリ[remote repository]：ファイルの変更履歴を記録（みんなで共有） add：「ワーキングツリー → インデックス」への反映 commit：「インデックス → ローカルリポジトリ」への反映 push：「ローカルリポジトリ → リモートリポジトリ」への反映 2. git resetを使いこなす git re
![[git reset (--hard/--soft)]ワーキングツリー、インデックス、HEADを使いこなす方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/16218eabd4d9c7c7d4432d8883062cf0140eef7a/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZ2l0JTIwcmVzZXQlMjAlMjgtLWhhcmQlMkYtLXNvZnQlMjklNUQlRTMlODMlQUYlRTMlODMlQkMlRTMlODIlQUQlRTMlODMlQjMlRTMlODIlQjAlRTMlODMlODQlRTMlODMlQUElRTMlODMlQkMlRTMlODAlODElRTMlODIlQTQlRTMlODMlQjMlRTMlODMlODclRTMlODMlODMlRTMlODIlQUYlRTMlODIlQjklRTMlODAlODFIRUFEJUUzJTgyJTkyJUU0JUJEJUJGJUUzJTgxJTg0JUUzJTgxJTkzJUUzJTgxJUFBJUUzJTgxJTk5JUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01NTdmYTA0MTI2YzRjZjM5MmRkY2M2Yzc0NmZkYzVlNw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzaHVudGFyb190YW11cmEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTAxOWU5OGNjMmY5Njk3YzdhMTAxOGM2YjdkNTliYzc5%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44K344Ot44Kv%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D40daa3618b9feaf756b5bde0fe7d03b4)
隅っこのおぼえがきノート [Git]コミットの親を後から変更してマージさせたことにする
ちゃんとマージ機能を使ってればこんなことしなくて済むんだけど…… 例えばこんな感じにコミットされてたとする。 大元のブランチがmasterで、途中でブランチfix1を切って変更をかけている。 で、fix1の内容をマージ機能を使わずに手動でマージしてしまったせいで、fix1がちゅうぶらりんのままになっている。 これ、後から見たときになんかすごくダサいというかわかりづらいというか紛らわしいというか、なんか嫌。 なのでこのfix1をmasterに合流させたい、というのが今回やりたいこと。 後から履歴をごにょごにょ変えたいときは「git filter-branch」を使うと良いらしい。 Git - git-filter-branch Documentation http://git-scm.com/docs/git-filter-branch git filter-branchは取り扱い注意の危な
![隅っこのおぼえがきノート [Git]コミットの親を後から変更してマージさせたことにする](https://cdn-ak-scissors.b.st-hatena.com/image/square/9e84467cb73bbbb065e600b20fa857bf468928e6/height=288;version=1;width=512/http%3A%2F%2Fblog-imgs-73.fc2.com%2Fs%2Fu%2Fm%2Fsumikko8note%2F2015021219373241a.png)
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
図解Gitコミットの修正まとめ git reset, cherry pick, revert, commit --amend, rebase - Qiita
HEADの参照を指定されたコミットに変更し、インデックスや作業ディレクトリの状態も変更する事ができる。git resetのオプションに--hard、--soft、--mixed（デフォルトオプション）があり、それぞれ使い方が異なるので覚えておく。個人的にはgit resetは良く使うので重点的に説明する。 とりあえず以下に示す通りGitレポジトリを作成して、このレポジトリを参考に各オプションの説明をして行く。 $ mkdir git-reset-test $ cd git-reset-test/ $ git init $ echo A > A; git add A; git commit -m "add A" A $ echo B > B; git add B; git commit -m "add B" B $ echo C > C; git add C; $ echo D > D; #
gitのrebaseとremoteとbranchと - 日々常々
gitでrebaseは呼吸するようにするものらしいですが、remote絡むと若干息苦しくなる。 $ git log --oneline --graph --decorate * caec1ad (HEAD, origin/master, origin/HEAD, master) add e * cb99644 add d * 912a264 add c * 14bb339 add b * b33a46a add a * 5fd8be9 initpush済みのこれをうっかりrebaseする。 $ git log --oneline --graph --decorate --all * f853362 (HEAD, master) add d * 4163b31 add e | * caec1ad (origin/master, origin/HEAD) add e | * cb99644 a
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
GitHub上の大事な中央ブランチをgit push --forceの恐怖から守るgit hookスクリプト - Qiita
つい先日、GitHubで管理していたテスト用中央ブランチに、チームメンバーが誤ってgit push --forceしてしまい、 一部の歴史が消失するという事件が起きました。 ぎゃあああ！なんばしよっとね！うっかりでしたじゃ済まんばい！ とか思っていたらJenkinsの開発者みたいなスゴい人でもやらかしちゃうみたいです。 Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう http://cpplover.blogspot.jp/2013/11/jenkinsgit-push-force.html スゴい人でもやらかすんだから、平民の我々もそのうちやらかすに違いない。 緊急バグ修正などで慌てていたら尚更ですね。（というか自分が一番やりかねない） というわけで、何とか仕組みの上で防くことができればと思って仕掛けることにしました。 以下のスクリ
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
ドリコムの開発を支えるGitリポジトリ - gussan
はじめに これは ドリコム Advent Calendar 2014 の5日目です。 4日目は、@ka_nipan さんによる ドリコムを支えるデータ分析基盤 です。 自己紹介 @gussan ドリコム歴は10年になります。 アーキテクチャ設計、ミドルウェア・ライブラリ及び社内ツールの開発運用等を担当しています。 本日の話 2年前の12月、メインのソースコードリポジトリをSubversionからGitLabへ移行しました。 本日はGitLabへの移行と運用の話をします。 GitLabに決めた理由 選択肢としてはGitLab, GH:E, Stash等がありました。 メインの機能はどれも十分な機能を有していましたが、 GitLabを選んだ主な理由としては以下の3つです。 継続的にメンテナンス・リリースがなされている 社内にある技術で運用可能である(Rails, MySQL, Redis) も
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳
10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか？ トーバルズ：俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた（データベースは別だが）。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B
How to create and apply a patch with Git · devroom.io
Creating a patch file with git is quite easy to do, you just need to see how it’s done a few times. This article will show you how to create a patch from the last few commits in your repository. Next, I’ll also show you how you can correctly apply this patch to another repository. Before you start To make creating patches easier, there are some common git practices you should follow. It’s not nece
Git リポジトリの統合 - エンジニアきまぐれTips
目的 別々に 2つの Git リポジトリがある。この２つを統合して一つのリポジトリにしたい。これらは元々同一のソースコードを管理しているものなのだが、リポジトリとして作成された時期が異なり、別々に存在していた。 経緯 ソースコードの運用者が変わったことで、一時的に VCS を利用していない期間があった。 Subversion で管理していた期間 (前々任者) VCS を何も使用していない期間 (前任者) Git で管理している期間 (現在) 我々が Git を使い始めたときには、古い Subversion のリポジトリは手に入らなかったため、最新のソースを元に新規のリポジトリとして管理を開始した。後に Subversion リポジトリが Git 形式に変換された形で手に入ったため、２つのリポジトリを統合しようということになった。 手順 http://d.hatena.ne.jp/gnarl
Git、複数のリポジトリを一つにまとめる - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
やりたいこと ReopA,RepoBがある。ReboB/masterをRepoA/repob-branchにコピーしたい 方法 追記: git fetch location refs/heads/branch-from:refs/heads/branch-to でいける、とJunio様に教えていただきました(ひー)。コメント参照。 各リポジトリの位置を/repo_a,/repo_bとする 1. RepoBのオブジェクトを全部RepoAにコピー。 $ cp -rf /repo_b/.git/objects /repo_a/.git/2. RepoB/masterのオブジェクトIDを調べる [/repo_b]$ cat .git/refs/heads/master 37e7c1e20928bc...3. 2で調べたコミットオブジェクトをチェックアウトする [/repo_a]$ git chec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://elinux.org/images/8/87/Celf_git.pdf
Gerrit Code Review - Signed-off-by Lines