Ask questions, find answers and collaborate at work with Stack Overflow for Teams. Explore Teams Collectives™ on Stack Overflow Find centralized, trusted content and collaborate around the technologies you use most. Learn more about Collectives
Git LFS （Git Large File Storage） とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。 Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。 本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、一方でどういった問題が解決されないかまでを、まとめて紹介します。 Git のラージファイル管理における問題点 まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。 バイナリファイルの管理に不向き Git は、ソースコード（テキストファイル）のバージョン管理に特化したツールです。
git hyper-blame is like git blame but it can ignore or "look through" a given set of commits, to find the real culprit. This is useful if you have a commit that makes sweeping changes that are unlikely to be what you are looking for in a blame, such as mass reformatting or renaming. By adding these commits to the hyper-blame ignore list, git hyper-blame will look past these commits to find the pre
About SSH key passphrases You can access and write data in repositories on GitHub using SSH (Secure Shell Protocol). When you connect via SSH, you authenticate using a private key file on your local machine. For more information, see "About SSH." When you generate an SSH key, you can add a passphrase to further secure the key. Whenever you use the key, you must enter the passphrase. If your key ha
Git 2.9 has been released https://github.com/blog/2188-git-2-9-has-been-released 昨日キレイなDIFFが出せるgit2.9がリリースされました。 homebrewで brew upgrade git な感じでアップグレードすれば2.9は入るのですが、 このキレイなDIFFは標準では有効になってないので、記事にあるとおりに設定を行いましょう。 だいたい以下のような感じのコマンドうてばいいと思います。 下準備：diff-highlightにPATHを通す まぁ通さずに直接読んでもいいんですが、通しておきましょう。 homebrewでいれるとdiff-highlightさんは↓あたりにいるのでPATHを通しておきましょう。 export PATH=$PATH:/usr/local/Cellar/git/2.9.0/s
git diffした時に、横に長い行の表示がコンソールの右につきぬけてしまって、右のほうが見えなくなってしまうんだけど、どうすればコンソールの右で折り返して表示してくれるのか誰か教えてくれませんか。MacのTerminalです。 http://twitter.com/shin1ogawa/status/13489861413 というのがあって、 git diff --color | less -Rとかで出来るっぽいという話になったんだけど、そんなのやらなくても設定でどうにかできるはずだよね、という話をhokaccha氏にしてみたら、すぐに調べて教えてくれた。ありがとうございます！ $HOME/.gitconfig に、 [color] ui = auto [core] pager = less -rと書いておけばいいだけらしい。 git diffとかで表示が切れてしまうときの対象方法 -
みなさんgitのsubmoduleって理解して使ってますか？ 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか？ 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
set variable = value bind keymap key action color area fgcolor bgcolor [attributes] source path You can permanently set an option by putting it in the ~/.tigrc file. The file consists of a series of commands. Each line of the file may contain only one command. Commands can span multiple lines if each line is terminated by a backslash (\) character. The hash mark (#) is used as a comment character.
# Visualization set author-width = 14 set filename-width = 16 set id-width = 14 set blame-options = -C -C -C set line-graphics = ascii set line-number-interval = 5 set horizontal-scroll = 33% set read-git-colors = no set show-author = abbreviated set show-filename = always set show-date = local set show-notes = yes set show-refs = yes set show-id = yes set show-rev-graph = yes set show-changes = y
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか？ 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
Just browsing Stack Overflow? Help us improve your experience. Sign up for research
git clone http://example.com/fuga.git remote: Counting objects: 3203, done. remote: warning: suboptimal pack - out of memory remote: fatal: Out of memory, malloc failed error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal:
git でリポジトリを clone した場合、通常は元のリポジトリを丸ごと取得してきます。 しかし、最新版が取得できればそれでよい、過去の履歴情報はいらない、という場合もあるかと思います。そんなとき、次のようにすればリポジトリを丸ごと取得せず、最新版だけ取得できます。 これは、git のマニュアルでは shallow clone と呼ばれています。 オプション depth に渡す値は、取得する履歴の数です。上記では 1 を指定しているので、最新のみを取得します。depth 1 で shallow clone したリポジトリで git log を実行すると、ログが 1 つしかないのが分かります。 利点 変更履歴が多くて通常の clone では時間がかかるような git リポジトリの場合、shallow clone を使うことで通常の clone より速く最新版を取得できます。 とりあえず最近
git config list [<file-option>] [<display-option>] [--includes] git config get [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<value>] [--fixed-value] [--default=<default>] <name> git config set [<file-option>] [--type=<type>] [--all] [--value=<value>] [--fixed-value] <name> <value> git config unset [<file-option>] [--all] [--value=<value>] [--fixed-value] <name> git c
Gitでリポジトリを作成する場合は以下の二種類がある。 git init git init --bare で、ベアリポジトリってのは、ワークツリーを持たないリポジトリだけで構成されたリポジトリ*1ってことなんですが、じゃあ、普通に作ったリポジトリと何が違うの？っていう素朴な疑問があった。 結果 で、調べてみた結果、大きな違いはたった一つだけだった。*2 [core] bare = false がtrueかfalseかの違いのみだった。bare = true になっているとワーキングツリーを持てないってこと以外は本当にほぼ一緒のよだ。その証拠にgit cloneなどもきちんとできるみたい。 ものすごくシンプルな設計だなぁとまた一つ感心した。 *1:hoge.gitみたいに.gitまでをフォルダ名にするのが通例 *2:他にも細かい違いはあるんだけど今回は割愛。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
