New Year, new Git release
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
Git LFSが1.0になってGitHubで使えるようになったので試してみた - Qiita
先日GitHub Universeをダラダラと聞いてたら、Git LFSの1.0がリリースされてGitHub上で使えるようになったらしいので試してみました。 追記 2016/8/20: まだベータでしたがBitbucketでも使えるようになってました。試したら詳しく追記します。 2017/5/20: git lfs initがgit lfs installにrenameされていたのでその旨追記しました。 概要 Git LFSはGitHubが中心となって開発しているラージファイル(画像・音声・映像等)を扱うための拡張機能です。gitレポジトリにはテキストファイルのポインタを保存しておいて別の場所にラージファイルの実態を保存しておくことができます。これによって不要なファイルのpullやfetchをすることなくgitレポジトリの最新化ができるようになったりします。 先日のGitHub Unive
GitHub、Gitで画像や動画など大容量ファイルを扱える「Git LFS」（Git Large File Storage）正式リリース
GitHub、Gitで画像や動画など大容量ファイルを扱える「Git LFS」（Git Large File Storage）正式リリース GitHubは10月1日（日本時間10月2日早朝）、サンフランシスコで同社初の大型プライベートイベント「GitHub Universe」を開催しています。 その基調講演にて同社CEOのChris Wanstrath氏は、画像や動画、音声といった大容量のファイルをGitワークフローで扱えるGitエクステンション「Git LFS」（Git Large File Storage）の正式提供を発表しました。 Gitはそもそもテキストファイルのコードを扱うことを前提にして差分や圧縮などの操作を行うように作られているため、デザイナやクリエイタなどが扱う画像や動画のような大容量ファイルの扱いは苦手でした。 Git LFSはGitの中に大容量ファイルへのテキストポインタ
Git Submodule の代替: Git Subtree | Atlassian Japan 公式ブログ | アトラシアン株式会社
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか？ 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
'git-バルス'をgit-hookにした
‘git-バルス'をgit-hookにした ロージー先輩がgit hookを簡単に管理できるツールを書いたので、かつて作ったgit-バルスをgit hook化しました Lightweight git hook management tool その名も git-hook を作りました - 宇宙線 : git-hookをインストールしたあとで、 git hook install post-commit https://raw.github.com/yuroyoro/git-balse/master/git-hook/post-commitで入ります。 コミットメッセージに"バルス"という文字列が含まれていると、可能な限りリポジトリを破壊します。ssh-agentであらかじめssh鍵を登録しておくと、取り返しがつかなくなってよいのではないでしょうか？ 以上。 yuroyoro/git-balse
Announcing Git Large File Storage (LFS)
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
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-ignoreというコマンドを書いた話 - ( ꒪⌓꒪) ゆるよろ日記
git-ignore add みたいのが欲しい— azu (@azu_re) August 24, 2014 ちょろっと書けそうだったので書いた。 yuroyoro/git-ignore · GitHub Demo Installation PATH通った場所においてくれ curl -sL https://raw.githubusercontent.com/yuroyoro/git-ignore/master/git-ignore > ~/bin/git-ignore Examples `git ignore add "pattern"`で、.gitignoreへ追加する。 $ git ignore add '*.log' .gitignoreから削除するには、`git ignore remove "pattern"`を実行する。 $ git ignore remove '*.log' a
tigから git rebase -i したらいろいろ捗った - くりにっき
git dtコマンド - razokulover publog を見て自分もgitのコマンドをカスタマイズしてるのを思い出したので普段よく使っているのを紹介します。 対象者 作業途中はtmpコミットをたくさん作って、最後に git rebase -i でコミットを整えている人 前置き gitのタイプ数を減らす gitコマンドを使う時に毎回 git と3文字タイプするのは時間の無駄なのでエイリアスつけるのをおすすめします ~/.bash_profile とか ~/.bashrc 辺りに下記を書きます。 alias g='git' これで g だけでgitコマンドが使えます git-now iwata/git-now tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ 最速でtmpコミットするためのコマンド。Macなら brew install git-
git addするファイルをpecoで選択できるようにした - petitviolet_blog
みんな大好きpecoを使って、git add出来るようにした 作ったもの 深いディレクトリにあるファイルが複数ある時、zshのtab補完でやるのも面倒だったので、peco使ってやりたいな〜と思ったからzsh関数書いた コード 複数選択に対応した 上のgifのように複数選択出来る 検索のハイライトと選択中のハイライトの色が被ってるため見難くなってしまっている function peco-select-gitadd() { local SELECTED_FILE_TO_ADD="$(git status --porcelain | \ peco --query "$LBUFFER" | \ awk -F ' ' '{print $NF}')" if [ -n "$SELECTED_FILE_TO_ADD" ]; then BUFFER="git add $(echo "$SELECTED_FI
Mobile First Development at COOKPAD #deploygate
Bakusoku Iterations Tokyo at mixi (2014/5/29) の発表資料です http://deploygate.doorkeeper.jp/events/11579
develop ブランチなんてオワコン
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"Cannot rebase onto multiple branches" when git pull · Issue #162 · sindresorhus/pure
GitHub - tokuhirom/git-xlsx-textconv
http://benmezger.me/post/109706270421/git-ignore-file-lines
入門書には載ってない Git & GitHub Tips
