Git LFS をちょっと詳しく - Qiita
Git LFS の機能が実際にどういう感じで動作しているかを、基本的な Git の手順に沿って少しだけ詳しく調べてみました。 なお、ロック機能については検証していません orz （今後に期待） TL;DR ワークツリーの情報をリポジトリ（.git/）に格納するタイミング（clean filter）で対象のファイルがメタ情報（ポインタ）に置き換えられ、ファイルの実体（オブジェクト）は .git/lfs/ 以下に格納される push の直前に LFS API を通してオブジェクトがサーバーにアップロードされる リポジトリ（.git/）からワークツリーに展開するタイミング（smudge filter）でメタ情報から実体ファイルに置き換えられる LFS オブジェクトが .git/lfs/ 以下にない場合は LFS API を通してサーバーからダウンロードされる コミット時、マージ時、チェックアウト
Git LFSの使用方法
Git LFSとは Gitは、音声・動画・高画質な画像などの大きなファイルを扱うことは不得意です。Gitリポジトリにそのような大きなファイルを含めると、git clone・git push・git pullの処理に膨大な時間がかかります。 Git LFS （Large File Storage以下、LFS） は前述した問題を解決すべく、GitHub・Microsoft・Atlassian、および他のコントリビュータによって開発されているGitの拡張機能です。 これにより、大きなファイルをより効率的に扱うことができます。 Gitの使用可能なバージョンは こちら をご確認ください。 大きなファイルを必要な分だけダウンロードする たとえば、LFSで管理したファイルはgit clone・git pullのときではなく、git checkoutのタイミングで必要な分だけダウンロードされます。 大きな
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
gitの管理ディレクトリを外出にする方法
2018.12.10はじめにgit の管理ディレクトリ(.git)とソースのディレクトリを別々のディレクトリにする方法を紹介します。 管理ディレクトリが同じことの弊害.git ディレクトリがソースと同じディレクトにあると grep や find を使ってディレクトリ内を検索するとき、除外設定をしなければならなかったりと面倒です。 また、.git ディレクトリを他の人や一部の人に見せたくないシーンもあると思います。 管理ディレクトリを外に出す方法リポジトリの作成から行う場合は、下記のコマンドを実行すると、--separate-git-dir=に指定したディレクトリに管理ディレクトリを置くことができます。 git init --separate-git-dir=/path/to/repository ソースコードと同じディレクトリに.gitが作成されますが、これはディレクトリではなくファイルに
cherry-pick 運用の地獄から這い上がった話をしよう
はじめに はじめに断っておくが、こんな生易しいものじゃない。本当に地獄の沙汰である。 状況と問題点 筆者が参加しているプロジェクトでは、ブランチの運用が cherry-pick で行われていた。Git Flow でも GitHub Flow でもない。言うなれば、Cherry-pick Flow である。 Git Flow について Git Flow なら、本番リリースする際にまず develop ブランチからリリースブランチを切る。 それを master にマージする。 そして、master へのマージ後のマージコミット (M1) を develop に逆輸入すれば、基本的に develop ブランチが Fast-forward な状態となる。 ホットフィックスの場合も同様である。 コミットの取りこぼしなど起きるわけがないし、リリース作業自体もやることが明確でわかりやすい。 Cherry
.gitattributesで改行コードの扱いを制御する - Qiita
Gitで管理するファイルの改行コードの扱いは、どうしたらよいのでしょうか。どうルール化するのがよいのでしょうか。 なぜルールが必要か そもそもなぜルールが必要なのでしょうか。以下の例で考えます。 AさんはLinuxマシンでコーディングしており、LFで改行されたソースコードのファイルXをGitにコミットしました。 一方、BさんはWindowsマシンでコーディングしています。今、Aさんが書いたコードを編集したいとします。GitからファイルXをチェックアウトして編集するわけですが、このとき、Bさんが使っているエディタはファイルXの改行コードをCRLFに変換してしまいました。Bさんはそれに気づかずコードを編集し、保存し、コミットしました。 BさんはファイルXの中の数行だけを編集したつもりなのに、改行コードが変わったために、全行に差分が生じてしまいました。これではコードレビューもしにくいし、後日、g
git push -f をやめて --force-with-lease を使おう - Qiita
force push問題 rebaseなどの作業の際、強制PUSHが必要なタイミングが出てくるが --forceではローカルの内容を破壊的にリモートレポジトリを上書きしてしまう。 同じブランチで複数人開発していた場合にタイミングによっては 「◯◯さんのコミットを吹き飛ばしちゃった//」 が発生する可能性が十分ある。 そもそも上記の運用方法に問題がある気はするが、どんな運用をしていたとしても force pushする際は --force-with-leaseオプションを必ずつけるようにしておいて損はないと思う。 TIPS: Github上でブランチを削除できないようにする 消されるとまずいブランチは [Settings] → [Branches]でさまざまなprotectionルールをかけておきましょう！
2つのGitリポジトリをマージする - Qiita
今回も 100% 自分のためのメモです。仕事で２つのGitリポジトリをマージして新しいリポジトリを作る必要がありました。コマンドの意味のいくつかを理解していなかったので、調べてメモしておきます。 自分の理解にポイントを置く 普段はこのレベルのは書かなかったですが、結城さんの一連のポストが素晴らしく、見習ってみることにしました。特に「自分の理解にポイントを置く」というのは、私におそらくもっとも足りていないことと思っています。 （自分の勉強法でいいのか） あなたの質問の中で「5分考えて何も思いつかない」というところが気になりました。いつも「5分」でタイムアウトするのはいいことなのかなと思ったからです。また「考えて何も思いつかない」というのは、（続く）https://t.co/0CSFZX0e8g pic.twitter.com/5APJBrbawm — 結城浩 (@hyuki) 2018年2月
Gitの便利な-pオプション四兄弟 - エンジニアをリングする
この記事はGit Advent Calendar 2014の6日目の記事です！ （更新がお昼になってしまいました、ごめんなさい＞＜） みなさん！ Gitの-pオプション使ってますか？ 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します！ 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね！ 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
gitのリポジトリ（管理領域）を別の場所に作る - Qiita
$ ls -la foo total 8 drwxr-xr-x 3 pasela wheel 102 11 2 18:31 ./ drwxrwxrwt 29 root wheel 986 11 2 18:31 ../ -rw-r--r-- 1 pasela wheel 29 11 2 18:31 .git $ cat foo/.git gitdir: /tmp/foo.git というわけで、実はgitは.gitの中身を別の場所で管理することができます。 この作業は手動でいじってもできなくはないですが、git initやgit cloneに--separate-git-dir=<git dir>を指定することで自動的にやってくれます。
GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。
git fetch の裏側では何が起こっているか - 詩と創作・思索のひろば
git fetch の裏側でどんな通信が行われてリモートリポジトリの内容が取得できるのか調べたのでまとめる。もともとは git の HTTP や SSH といったプロトコルでどのように実現されているか、というところに興味があった。Git v2.7.1 を基にしている。 事前準備 pack プロトコル pkt-line フォーマット Reference discovery Packfile negotiation Packfile の送受信 packfile への圧縮・packfile からの展開 各種トランスポートの実装 file トランスポート ssh トランスポート git トランスポート http(s) トランスポート まとめ 参考資料 事前準備 手を動かしてプロトコルを理解できるよう、gist の小さなリポジトリ を使う。適当なディレクトリ下に bare リポジトリとして clon
git reset -p で git add -p をリセットする - Qiita
git 助けて 間違ってaddしてしまったのを取り消して前のインデックスの状態を手に入れたい — トデス子 (@todesking) October 5, 2012 私がやりたいのはですね、 git add a; git add b; した状態からgit add a;した状態に戻したい — トデス子 (@todesking) October 5, 2012 例えが悪かった、git add a; edit a; git add a;した状態から二度目のgit add aの影響を巻き戻したい — トデス子 (@todesking) October 5, 2012 それ git reset --patch でできるよ。 git reset (--patch | -p) [<commit>] [--] [<paths>...] Interactively select hunks in the d
git checkoutを図解する | To Be Decided
この記事を読んだ、またはGitのオブジェクトモデルを理解していることを前提に、Gitの git checkout というコマンドについて説明する。 このコマンドは普通ブランチを切り替えるものと説明されるが、主たる機能は オブジェクト格納領域から指定されたファイルを取り出し、ワーキングディレクトリに配置する ものである。 つまりこれがGitにおけるチェックアウトで、チェックアウト=ブランチの切り替えではない。 コマンドに与える引数によっては HEAD の付け替え、つまりはブランチの切り替えもする、というだけ。 git checkout の動作を HEAD の付け替えの有無によって分けて考えると分かりやすく覚えやすいので、以下そのように説明する。 HEADを付け替えないgit checkout HEAD を付け替えない git checkout は、引数にワーキングディレクトリ内の ファイルま
Gitのリポジトリの中身をなるべく正確に理解する | To Be Decided
このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ
[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/595ab9649c16d3f6961498f4d6220e40f1fcf2a7/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-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCZ2l0JTIwcmVzZXQlMjAlMjgtLWhhcmQlMkYtLXNvZnQlMjklNUQlRTMlODMlQUYlRTMlODMlQkMlRTMlODIlQUQlRTMlODMlQjMlRTMlODIlQjAlRTMlODMlODQlRTMlODMlQUElRTMlODMlQkMlRTMlODAlODElRTMlODIlQTQlRTMlODMlQjMlRTMlODMlODclRTMlODMlODMlRTMlODIlQUYlRTMlODIlQjklRTMlODAlODFIRUFEJUUzJTgyJTkyJUU0JUJEJUJGJUUzJTgxJTg0JUUzJTgxJTkzJUUzJTgxJUFBJUUzJTgxJTk5JUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iYTIwNmM4YzMyNTBjODlmZmQ2ZmJlMmQzNjIzNzIwZA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc2h1bnRhcm9fdGFtdXJhJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03NTIzZDczZGI1NzYyYzBhZWM5NjZlOGE1NGE3ODU5YQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Debfa92ade65dfa9b654d70c587e7b15f)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
研究者のためのGit入門
git blame じゃなくて git praise を使う - harunappleのブログ
Git コンフリクト解消手順 - Qiita
GitHubからクローンできない。