tigでgitをもっと便利に！ addやcommitも - Qiita
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
Microsoft、巨大リポジトリを快適に管理できるGVFS(Git Virtual File System)を発表 | ソフトアンテナ
Microsoftは本日、巨大なGitリポジトリを快適に管理するための専用ファイルシステム「GVFS(Git Virtual File System)」を発表しました(slashdot)。 GVFSはGitリポジトリを格納するための専用ファイルシステムで、リポジトリを仮想化し、巨大なリポジトリでも高速な動作を可能とすることを目指して開発されているものです(具体例としてあげられているWindowsのコードベースは350万件を超えるファイルが存在し、サイズは270GBを超えている模様)。 必要なファイルだけをダウンロードすることでcloneを高速化し、リポジトリの状態を積極的に管理することで、checkoutやstatusなどに必要な時間も短縮します。例えばcloneにかかる時間が12時間から数分に、checkoutは2〜3時間から30秒に、statsuは10分から4〜5秒に短縮されるとしてい
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
gitのユーザー名とメールの設定場所でトラブル。 - Qiita
gitをインストールした最初の初期設定の後で別の名前やメールに変更したい。 問題 Ubuntu14.04のインストール直後gitの初期データを設定した、しかし後に別の名前とメールを変更する必要に迫られ設定を変更したが、そのデータ設定が反映されなかった。 原因 .zshrc（zshシェルの設定ファイル）に直接書き込んでいた。 （.zshrcをコピペしたため。） 最初gitの設定ファイルは3箇所あると調べあげ、それぞれ設定しなおしてみたがぜんぜん反映されず色々時間を使ってしまった。 git設定ファイルは基本3箇所 /etc/gitconfig Git でこのファイルの読み書きをするには、 --system オプションを指定します。 ~/.gitconfig ホーム直下 Git でこのファイルの読み書きをするには、 --global オプションを指定します。 .git/config リポジトリに
リモートのブランチをcloneする - Qiita
とかって感じでリモートのリポジトリをcloneしてきたとする。 で、git branchすればわかるんだけど、このままだとmasterブランチしかローカルにcloneできてない。別のブランチ(developmentとする)もローカルにcloneしたい。 という時はまず でリモートのブランチ名を調べる。 そうすると以下のような感じで表示される。 $ git branch -r origin/HEAD -> origin/master origin/development origin/master で、この中からお目当てのブランチ名を探し（この場合は「origin/development」）、こいつを以下のようにしてcloneすればOK。
Git pullを使うべきでない３つの理由 · DQNEO日記
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
git を https 経由で使うときのパスワードを保存する - Qiita
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
HomebrewでError: GitHub API rate limit exceededを回避する
B! 35 0 0 0 Homebrewでsearchコマンド等をたくさんしてると使用回数を超えて GitHub API rate limit exceededと言ったエラーが出てしまいます。 その対処法について。 アクセス回数制限 GitHubでAccess Tokenを作る HomebrewにTokenを渡す。 アクセス回数制限 GitHubでは認証無しのアクセスについて、同じIPアドレスから1時間で60回までと 制限がかかっています1。 Homebrewで沢山searchコマンドなんかを使ってると、 $ brew search Error: GitHub API rate limit exceeded for xxx.xxx.xxx.xx. (But here's the good news: Authenticated requests get a higher rate limi
1つの git を複数のリポジトリに分割する方法
概要 1つの巨大なgitを複数のgit環境に分割してみたいと思います 初めは小さなプロジェクトで1つのgitからスタートしたが、次第にプロジェクトが大きくなり、その過程でgitを複数作らなくて同じgitにpushし続けた結果いろんなソースコードが混じった巨大なgitが出来てしまった なんてことはあると思います 環境 git 2.1.1 分割する方法 例として自分のGitHubアカウントを使って分割してみます 分割先のリポジトリを作成する まず分割先のリポジトリを作成しましょう 名前は何でもOKです できれば空のリポジトリとして作成しましょう 空じゃなくてもOKですが、空リポジトリの方が簡単です 分割対象のリポジトリをcloneする これが巨大な1つgitリポジトリになります ご自身の環境に合わせて分割したいリポジトリをローカルにcloneしてください すでにある場合は特に何もしなくてOKで
追跡ブランチ (tracking branch) というブランチが何なのか調べた - snowlongの日記
まとめ 追跡ブランチを指定する git checkout -b fb_track origin/develop あとから追跡ブランチを指定する git branch --set-upstream-to origin/[branch-name] 追跡ブランチ (tracking branch) という概念がわからない 以前、「tracking branchを指定していないからgit pull してもこのブランチには更新されないよ〜」と言われたことがあり「？？？」となったまま疑問を解消せずに放置を決め込んでいた。 いちおうGit/Githubは操作することはできるけど、きちんと理解したいな、疑問点はすぐに解決しないとなと思いたち調べてみました(1年以上放置してきた疑問だけど:p)。 master とorigin/masterの違い まずは、「master とorigin/masterの違い」に
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
Git 別のリポジトリを履歴を残したまま取り込みたい - かもメモ
Gitで別々に作ってたリポジトリをコミットログを残したまま1つにしてしまいたい時のめも。 例えばkankore_repoとkuchikukan_repoという2つのリポジトリが別々にあったとします。 これらを別々のリポジトリで管理するのが大変になってきたのでkankore_repo内の'destroyer'ディレクトリに kuchikukan_repoで管理していた全てをコミットログを残したまま入れてしまいたい。そんな感じです。 図で書くと /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git /kuchikukan # kuchikukan_repo リポジトリのあるディレクトリ |--- .git これを ↓ のような感じにしたいのです！ /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git |--
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting…
Git のパスワード認証に MacOS のキーチェーンアクセスを使う｜mattintosh note (跡地)