.gitattributesで改行コードの扱いを制御する - Qiita
Gitで管理するファイルの改行コードの扱いは、どうしたらよいのでしょうか。どうルール化するのがよいのでしょうか。 なぜルールが必要か そもそもなぜルールが必要なのでしょうか。以下の例で考えます。 AさんはLinuxマシンでコーディングしており、LFで改行されたソースコードのファイルXをGitにコミットしました。 一方、BさんはWindowsマシンでコーディングしています。今、Aさんが書いたコードを編集したいとします。GitからファイルXをチェックアウトして編集するわけですが、このとき、Bさんが使っているエディタはファイルXの改行コードをCRLFに変換してしまいました。Bさんはそれに気づかずコードを編集し、保存し、コミットしました。 BさんはファイルXの中の数行だけを編集したつもりなのに、改行コードが変わったために、全行に差分が生じてしまいました。これではコードレビューもしにくいし、後日、g
Introducing Git protocol version 2
The latest news from Google on open source releases, major projects, events, and student outreach programs. Today we announce Git protocol version 2, a major update of Git's wire protocol (how clones, fetches and pushes are communicated between clients and servers). This update removes one of the most inefficient parts of the Git protocol and fixes an extensibility bottleneck, unblocking the path
こんなGitの教え方をするエンジニアはデザイナーからモテるぞ！ - Qiita
いかがでしょう！ この通り、デザイナーからモテモテです！ ■真面目な話… タイトルはふざけていますが、真面目な話をすると4年前の私がこんな教え方をしてもらえていたら、本当にGitに怯えることもなかったと思います。 なぜ、あのころ理解ができなかったのか。 あの時どうしてもらえていたら、エンジニアもデザイナーもお互い幸せになれたのか。 Gitを使い始める時にデザイナーとして知りたかったことや知らなくても困らなかったことを一生懸命まとめました。 情熱を込めすぎたせいで、1万字を超えるエントリーになってしまっています。 順番も意識したので、上から順に読み進めていただけると、うれしいです。 ■あらすじ 【その1】「図解」を活用し、「簡単」って嘘をつかないエンジニアはモテる 【その2】Gitで幸せになる世界を共有してくれるエンジニアは素敵だ 【その3】環境構築をサポートしてくれたエンジニアはものすごく
Git: Submodule地獄からの脱出 - Qiita
git の submodule、便利ですが安定してない(変更の多い)リポジトリに使うと 地獄です。 Submodule Hellです。 やばいです。 開発で変更が入りまくるリポジトリをうっかりsubmoduleにしちゃった！ かなり開発して入り組んできたけどどうしよう…。 なぜsubmoduleが地獄になるのか？ 更新が多いリポジトリはコミットが2箇所になって地獄 しかも変更がsha-1形式でしか分からなくて地獄 submoduleのクラス名・メソッド名等をリネームすると、親側もリネームが必要になって無駄に2回のコミットをしなくちゃいけなくて地獄。 さらに、親のコミットはコードの修正＆submoduleの変更の取り込みも必要 submoduleの参照先同士が衝突した時、何が悪いのか探すのが大変すぎて地獄 いともたやすくsubmodule側が detached HEAD になって自分のコミッ
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬
GitLFS移行のお話 / migrate to git lfs // Speaker Deck
All slide content and descriptions are owned by their creators.
【旅する勉強会】Grani & カヤックで合同勉強会を開催しました！ - KAYAC Engineers' Blog
こんにちは、藤田です。 2/24(金)に『神獄のヴァルハラゲート』を提供していることで有名な株式会社グラニさんのオフィスにお邪魔して合同勉強会を開催しました！ 今回は当日の発表内容を簡単にご紹介します。 Golang x gRPC の話 トップバッターは、カヤックの矢吹から Golang × gRPC の技術検証についての発表を行いました。 カヤックのゲーム開発で用いている Baal などの開発現場の背景について紹介させていただきつつ、gRPC の検証についてお話しました。 社内検証の結果、protobuf は json と比べて最大で25倍エンコード/デコードが高速で低スペック端末ほど効果が大きいものの、 gRPC は .NET Framework 4.5+ を要求するのに対して、Unity に搭載されているバージョンは 3.5 である点が最大の課題となりました。 その他にも AWS 上
グラニ x カヤック合同勉強会レポート。ネイティブ開発をテーマに gRPC, Unity, アセット管理, GitLFS について - Grani Engineering Blog
CTOの河合です。 2/24(金)に面白法人カヤックさんと合同で、弊社の休憩/セミナースペースにて勉強会を開催しました！ カヤックさんには以前にもお越しいただいて、その時はVRがテーマだったので、今回はネイティブアプリケーション開発をテーマに、特に弊社では最近gRPCが熱いのでgRPCを切に希望しつつ、お悩みどころでもあるアセット管理などについて、お互いの知見を共有し合いました。 Golang x gRPC の話 カヤック矢吹さんより、GolangとgRPCの話をしていただきました。詳細はカヤックさんのレポート 【旅する勉強会】Grani & カヤックで合同勉強会を開催しました！ へ。 gRPCの採用を検討し最終的には……！理由は非常に納得の行くもので、しっかりした検証と、しかしより良い形を目指して現実的な採用を進めるところは、さすがだと思いました。 NextGen Server/Clie
Git, fatal: The remote end hung up unexpectedly
When I tried to run git push origin master --force I just got Counting objects: 2649, done. Delta compression uses up to 2 threads. Compressing objects: 100% (1280/1280), done. error: RPC failed; result=22, HTTP code = 413 | 116 KiB/s fatal: The remote end hung up unexpectedly Writing objects: 100% (2504/2504), 449.61 MiB | 4.19 MiB/s, done. Total 2504 (delta 1309), reused 2242 (delta 1216) fatal:
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
GitHubでGitLFSを使ってみる - たけぞう瀕死ブログ
実際にGitLFSを使ってみようということでGitHubで試してみました。 まずはgit-lfsのインストールから。gitはインストール済みとします。MacならHomebrewで簡単に入れられます。 $ brew install git-lfs 適当なGitリポジトリを作成し、GitLFSを有効にします。 $ mkdir git-lfs-test $ cd git-lfs-test/ $ git init $ git lfs install GitLFSで管理するファイルを指定します。 $ git lfs track *.jpg あとは普通にファイルをコミットしてpushすれば該当のファイルが自動的にGitLFSに保存されますし、git-lfsがインストールされている環境であればcloneしたりpullしたりすると自動的にローカルにもファイルの実体がダウンロードされてくるので普通にリポジト
Getting-Cheat-Sheet.md
Getting-Cheat-Sheet.md Git Cheat Sheet Commands Getting Started git init or git clone url Configuration git config --global color.ui true git config --global push.default current git config --global core.editor vim git config --global user.name "John Doe" git config --global user.email foo@citrix.com git config --global diff.tool meld Working with Local Branch Branching # See the list of all local
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
Unity Feedback - git-lfs (large file support) for unity cloud build
Github is rolling out the git-lfs extension, which allows you to stash big binary files outside the git repository, but still keep the same git workflow you're used to. It seems to be a great fit for Unity3d, which encourages keeping the source assets in the Unity3d project to take advantage of the Unity3d asset workflow. https://git-lfs.github.com Unity cloud build would break if it doesn't suppo
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
中の人に聞いたGitHub flowの本当の使い方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SourceTree 2.0 is horribly slow and not scaling well on Windows 10
既に git 管理しているファイルをあえて無視したい - Qiita
Can Not Authenticated · Issue #399 · Microsoft/Git-Credential-Manager-for-Windows
大容量ファイルもGitで管理。 Git LFSの使い方
