Gitのfetch/pullサブコマンドで--pruneオプションをデフォルトにする
Gitではbranch -aでリモート・リポジトリーも一覧できる。この一覧には既にリモートでは消されたリモート・リポジトリーも表示される。この一覧を更新するにはfetch --pruneを使うわけだが、いちいちそうするのは面倒くさい。どうやらfetch.pruneをtrueにするとデフォルトで--pruneを付けてfetch(及びpull)を実行してくれるようだ。 $ git config --global fetch.prune true $ git fetch From https://github.com/hail2u/example x [deleted] (none) -> origin/deleted-branch グローバルに設定して良い場合はこれで常に--prune付きでfetchとpullが実行されるようになる。この設定はプロジェクト・ローカルで特定のリモートに対してのみ
Gitでリモートブランチを消してもgit branch -aに出てくる件 - chulip.org
$ git push origin :remote_branch_nameとかやるとリモートブランチを削除できるのですが上記コマンドを実行した環境以外で git branch -aをやるとまだ表示されてしまっていたので消す方法。 git fetchで行けるかと思ったのですがどうもfetchは同期をとるものではなく取りに行くだけのようですね。 下記サイトを参考にさせていただきpruneオプションの存在を知りました。 どこにもリンクしていないオブジェクトは削除してくれるようです。 $ git fetch --prune 2011-12-01 ただ、このオプションはgit1.6.6以降のみ使用可能とのことで。 git fetch --prune doesn't exists with all git versions · Issue #75 · fcuny/jitterbug · GitHub
githubのリポジトリにアクセスするとパスワードを求められる時の対処 - Qiita
~/.netrcにIDとパスワード書けばいいよ！と言う人もいるけど平文でパスワード書くなんて恐ろしい真似はしたくないよね。 まず、なぜパスワードを求められるかと言うと、http(s)でcloneしたからと思われる。新しいリポジトリを作った時、例としてhttpsでcloneするコマンドが出てくるのでついやっちゃってるケースがありそう。 リモートのURLを確認・変更 リポジトリのディレクトリに入って
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
空のディレクトリをgitで管理するには.gitkeepを使う（.gitignoreは使わない） - YomuKaku Memo
gitを使ってバージョン管理を行う際に、プロジェクト全体のツリー構造をそのまま管理する目的で、中身が何も無いディレクトリもgitの管理下に置きたい場合があります。 何も対応しないと、gitは空のディレクトリをバージョン管理してくれません。 中身が空のディレクトリをgitのバージョン管理下に入れるためには、当該の空ディレクトリの中に .gitkeep というファイルを作成してからgitで管理します。 実例 Railsのアプリケーションを新しく作成する場合を例に用います。 $ rails new test_application $ cd test_application $ ls -l vendor/plugins （vendor/pluginsは中身が空なので何も出力されません） 上のように、vendor/pluginsは中身が空です。 このディレクトリをgitの管理下に入れるために、次の
初心者でもわかる！リベースの使い方を解説します | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる？ コミットが綺麗になる！ 以上です！ この一言に尽きる！ 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか？ 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います！ マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
git で強制的に pull する方法 - Cube Lilac
ようやく悩みが解消されたのでメモ． Visual Studio 辺りのプロジェクト・ファイル群を丸ごと git リポジトリで管理していると，（自動生成されるファイルなどの関係で）手動では何も変更を加えていない（ビルドしただけなど）にも関わらず git pull 時に衝突が発生すると言う問題に悩まされていました．今まで，そう言った自動生成されるファイルを git リポジトリに登録するのが悪いと .gitignore を頑張って記述してみたり，git add . みたいに，適当な形でレポジトリインデックスに追加しないなどいろいろやってみましたが，なかなか上手くいきませんでした． そんな感じで悩んでいたところ，衝突が発生したときに git status を眺めていると以下のようなメッセージが書かれてありました． $ git status # On branch master # Changed
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
既に削除したリモートブランチを一覧から削除したい - rela1470のブログ
社内でちゃんとgitを使っていると､すごくbranchの増減があり、 fetchしたタイミングによってbranchの存在情報がバンバン入っていきます。 しかし、その開発branchが削除されても、 git branch -a で削除されているはずのbranchが表示されてしまう場合があります。 これは.git/objectsフォルダにゴミオブジェクトが残っているからです。 実際はどこにもリンクしていないオブジェクトですので、まとめて削除してしまいましょう。 どこにもリンクしていないオブジェクトを全て削除する命令が「prune」です。 こんな風に使います。 git fetch --prune pruneしても通常は全く問題がないはず（どこにもリンクしていないオブジェクトを消しているだけなので）ですので、自分ではfetchする際には必ずpruneオプションをつけています。 実際、自社の開発フェ
Git で不要になったリモートブランチを削除する - koogawa blog
こんなブランチ構成だとする。 $ git branch -a * master ios7 remotes/origin/HEAD -> origin/master remotes/origin/ios7 remotes/origin/master ios7のブランチを消したい。 まずはローカルブランチを削除 $ git branch -d ios7 Deleted branch ios7 (was 57c1b0b). リモートブランチも削除 $ git push origin :ios7 To https://xxx.git - [deleted] ios7 確認 $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master ちゃんと消えた！ push で消すのとか、:hoge で指定
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
Gitでコンフリクトした時のための備忘録 - アジャイルSEを目指すブログ
コンフリクトしたときに便利そうなので、備忘録を残しておく Gitのコマンド コンフリクトしているファイルの一覧を表示する。 $ git ls-files -u [<path>] ファイルの状態(コンフリクト含む)を表示する。 -s でshort-format で特定のディレクトリのファイル一覧を表示できる $ git status [<path>] 手動で直す方法 修正後にaddが必要 $ vi <path> (手動でコンフリクトを直す) $ git add <path> mergetool でマージする方法 -y でデフォルトのマージツールが実行する で1つずつ指定できる $ git mergetool -y [<path>] をHEADと同じ状態にする。 修正後にaddが必要 $ git checkout --ours [<path>] $ git add <path> をマージで指定
Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
作りながら覚えるGit (1) - みねこあ
濱野さんの「入門Git」を初めて読んだ時、いきなり 第二章から Git の構造の説明を始めてしまう構成に「Git<の使い方>入門」じゃなくて「Git<の作り方>入門」でしたかーっ（さすがメンテナですね）、、と思ったことを覚えています。 入門Git 作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/24メディア: 単行本購入: 31人 クリック: 736回この商品を含むブログ (155件) を見る それは結構楽しい体験で、それまで全く思っても見なかった「Git作ってみたいな」という うずうずとした衝動がわたしに芽生えるきっかけでした。それ程に Git の設計はシンプルで 手に終えそうで、それでいて「うまくいく仕組み」が備わっている、興味深いものだったのです。まさにハックと呼ぶにふさわしいそれは、VCS全般に抱いていた「しっかり綿密に作りこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Fix Composer Update Failure due to GitHub Authorization | ArtArmstrong.com
http://blog.inouetakuya.info/entry/20120826/1345979787
Merging vs. Rebasing | Atlassian Git Tutorial
Perlゼミ(サンプルコードPerl入門)
gitでリモートのブランチにローカルを強制一致させたい時 - Qiita
