ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
いかがでしょう！ この通り、デザイナーからモテモテです！ ■真面目な話… タイトルはふざけていますが、真面目な話をすると4年前の私がこんな教え方をしてもらえていたら、本当にGitに怯えることもなかったと思います。 なぜ、あのころ理解ができなかったのか。 あの時どうしてもらえていたら、エンジニアもデザイナーもお互い幸せになれたのか。 Gitを使い始める時にデザイナーとして知りたかったことや知らなくても困らなかったことを一生懸命まとめました。 情熱を込めすぎたせいで、1万字を超えるエントリーになってしまっています。 順番も意識したので、上から順に読み進めていただけると、うれしいです。 ■あらすじ 【その1】「図解」を活用し、「簡単」って嘘をつかないエンジニアはモテる 【その2】Gitで幸せになる世界を共有してくれるエンジニアは素敵だ 【その3】環境構築をサポートしてくれたエンジニアはものすごく
By Mike Mozart Microsoftが仮想ファイルシステムの「Git Virtual File System(GVFS)」を発表しました。GVFSはリポジトリ下のファイルシステムを仮想化することで、ファイルを開く時点でダウンロードを実行する仕組みを採用しており、大幅な高速化が実現されています。 Announcing GVFS (Git Virtual File System) | Microsoft Application Lifecycle Management https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/announcing-gvfs-git-virtual-file-system/ Microsoftは2013年にオープンソースの分散型バージョン管理システムである「Git」のサポートを開始していま
SourceTree for Windows 2.0ではタブ中心のUIとなって、現在の作業に集中しやすい画面になりました。細かいデザインや配色、アニメーション効果などを見直したことで視認性も改善。 Windows 10 Anniversary Updateで追加されたモニタごとのDPI設定に対応したことで、モニタ間で表示を移動させてもつねに精細な表示を実現しました。 またGitの操作にLibGit2を採用したことで、SourceTree for Windows 1.10と比較して性能が大幅に改善しています。 そしてマイクロソフトが開発したGit Virtual File System（GVFS）をサポート。GVFSはリポジトリ下のファイルシステムを仮想化し、Gitリポジトリにあるように見せつつ必要なファイルをローカルにダウンロードすることで、特に大規模なリポジトリに対する操作を高速化するも
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秒に短縮されるとしてい
調査以前に PSD ファイルのバージョン管理について検討した。 .psd や .ai はどのようにバージョン管理すべきなのか | DeadwoodGitHubその後、GitHub が GitLFS に対応。 Git Large File Storage v1.0無料で 1GB 分のサイズが提供されている。 毎月 $5 追加することで 50GB まで利用できるようになる模様。 直近の小規模サイト制作で受け取った PSD ファイルの総量を確認したところ 17GB であったので微妙なところ。 Bitbucket残念ながら Cloud サービスには対応していない。 が、Server (オンプレミス型) が、10 ユーザーまで $10 買い切りだった。 Bitbucket – Pricing | Atlassian適当な環境があれば、これを導入すると良いかも。 Server (オンプレミス型) –
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
Version 11.0 was released on May 7, 2024 Version 7.0 was released on May 7, 2024 Read Blog Post Release Notes Git Made Easy Drag and Drop • Undo everything • A unique Conflict Wizard • File history • Extensive documentation • Great customer support Learn More All of Git's Power (And None of the Pain) Pull Requests • Single-line staging • Interactive Rebase • Submodules • Git LFS • Git-Flow • File
イラストの管理 自分はたまにイラストを描いたりするのですが、以前からその管理方法に苦労していました。 苦労していた点は主に次の 2 点です。 バックアップ 制作過程 Gif をつくるのが面倒くさい 強い人は、短時間でもさらっとイラストを描いてしまいますが、自分は時間をものすごく掛けないとまともなものが描けないので、バックアップは結構頻繁に取ります。 手動でバックアップしようとした場合は、ふつうにファイルを複製する感じになると思います。 ただ、普段からコードを書いていて VCS を利用している身だと、どうしても原始時代かと錯覚してしまいます。 さらに、PhotoShop の psd 形式や CLIP STUDIO PAINT の標準である clip 形式はいろんなデータが詰め込んであるので 1 ファイル当たり平気で 50 MB くらい持って行かれます。これも結構厳しいところです。 VCS を
前置き 皆さんも業務上やむを得ずWord, ExcelやPowerpointでドキュメントを作っていることと思います。他にもなんかよく分からない画像だったりとか、Astahとかそういうやつとか。とにかく望むと望むまいと僕たちはプロプライエタリなバイナリに囲まれて生きています。 まあその手のドキュメントは作ったり読んだりしてる限り別にいいんですが、だいたい世代管理が困難に近いです。MicrosoftのSharepointとかいう地上最低の操作性を誇るWebアプリを使う 1など、まあ手が無いこともないのですが、いろいろと厄介です。で、そういうファッキンバイナリィドキュメンツが数十GB単位で貯まってきた頃に事故があって、誰かが共有フォルダのファイルを消したりぶち壊したりしてしまったりなんだりして、上司が「ちょっとこれいい感じに管理する方法考えといて」とか無茶なことを言ってくるわけです。 後半に私
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
I actually want to remove a branch in the bare repository i am working with, but this task hits a dead end because I cannot switch away from the master repository without a 'work tree' which a bare repository does not have. When I run git branch -d master the output is: error: Cannot delete the branch 'master' which you are currently on. So I try to switch to another branch called 'develop' by run
遅まきながらgit initやcloneにあるseparate-git-dirオプションを使いました。 ちょろっとググると、Dropboxでの応用があるみたいですね。 このエントリではトリッキーかもしれませんが、git initでの違う応用を紹介します。 separate-git-dirを使うと何ができるの？ チームで使っているWindowsの共有フォルダをローカルで版管理しています。 これは、個人的なバックアップと差分チェックを兼ねたものです。 この共有フォルダは、 諸事情によりPJに関係ない人でもアクセスできるフォルダなので、 gitレポジトリ(.gitディレクトリ)を作りたくありません。 PJに関係ないファイルということと、レポジトリを壊されたくないからです。 共有フォルダの中身を、rsyncでローカルへ同期してから版管理していました。 separate-git-dirを使うことで、
2週間ほど前にGitHub社からGitBucketのコミッタ宛てにメールが届きました。 それは「GitBucketはGitHubにあまりにも似すぎているが、GitHub社はGitHubのプロプライエタリなマテリアルをコピーしたり、ユーザインターフェースをクローンすることは許可していない。これはGitHub社の知的所有権を侵害している可能性があり、GitHubのユーザに混乱を引き起こすもので、改善を求める」という趣旨のものでした。 1点目についてはGitBucketはOcticonsやBootstrapテーマなどオープンソースのリソースは活用しているものの、GitHubからいかなるプロプライエタリなマテリアルやソースコードもコピーしていませんので問題ではありませんでした。 2点目については（ユーザインターフェースに関する権利については諸説あるようですが）、GitBucketが「GitHubク
概要 SourceTreeの環境構築中に変なところで躓いたので、忘れないように書いておこうと思います。 解決するまで時間がかかったのと、根本的な原因は未だに不明です。 環境 Windows 7 Professional SourceTree Version 1.7.0.32509 問題 環境構築自体は途中まで問題なく出来ていました。 SourceTreeのインストール PuTTY Key GeneratorでSSHキーの作成 SSHエージェントを起動し、SSHプライベートキーの登録 BitbucketにSSHパブリックキーを登録 Bitbucketから「SourceTreeにクローン」ボタンを使用してクローン開始 ……クローンできない！(というかそもそもGitリポジトリとして認識されていない？) という具合にピンポイントでここだけ上手くいきませんでした。 いくら待ってみてもリポジトリの取得
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く