Gitの.git/objectsの中身を追ってみる - kk_Atakaの日記
あらすじ この記事は Git Advent Calendar 2013 の 14 日目の記事です。 12 日目: @ton1517さん - gitのサブコマンドを自分で作る - ton-tech-ton 13 日目: @horimislimeさん - git mergeでコンフリクトが発生するか前もって調べる方法 - Qiita [キータ] 14 日目: ここ 15 日目: kyanroさん - git - rebase 直後に、自分が修正していたファイルが変更されたかどうかを調べる - Qiita [キータ] とりあえず 12 日目へつなげておきますね。 最近 Subversion を使うことが多く、めっきり Git を使っていないので、復習として .git/objects の中身を追ってみた。 参考 Pro Git 9章 Git - Gitの内側 アリスとボブのGit入門レッスン Ch
GitHubクローンまとめ 無料でGitHubのような機能を実現するための候補 | Act as Professional
Bitbucket – 無料のプライベートリポジトリが魅力https://bitbucket.org/ 無料でプライベートリポジトリを無制限につくることができる。 プライベートリポジトリは5人までは無料で利用できる。GitHubクローンではないが、個人や数人で利用するだけならBitbucketのサービスだけでまかなえるのでおすすめ。オンプレミス製品は有償での提供。 Gitea – Go製セルフホスト型のGitHubクローン2016年にver1をリリースした期待の新星です。別途記事を書いてますので、詳細はそちらをどうぞ。 https://hiroki.jp/gitea Go製のためマルチプラットホームでさくっと動きます。DockerやVagrantの提供もしているため動作させるまでのハードルが低いです。 全文検索機能はありませんが、主要な機能は搭載されています。 GitPrephttp://
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
SVN から Git へ：進行中の開発に影響を与えずに Git へ移行したアトラシアンの方法 ― 人間的側面 | Atlassian Japan 公式ブログ | アトラシアン株式会社
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 31 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Human Side" この記事は、エンタープライズ開発チームが Git に切り替えることに注目した連載記事の一つとして、 Dr. Dobb's で紹介されました。 この 3 部からなるブログシリーズ では、私たちが JIRA のコードベースを Subversion から Git へ移行したことに注目しました。私たちは、自分たちの移行で経験したことを、巨大なプロジェクトを Git へ移行することを検討している皆さんと共有したいと思っています。それも、
SVN から Git へ：進行中の開発に影響を与えずに Git へ移行したアトラシアンの方法 ― 技術的側面 | Atlassian Japan 公式ブログ | アトラシアン株式会社
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 22 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Technical Side" このポストは、エンタープライズ開発のバージョン管理を Git に切り替えることに注目した連載記事（全三回）のうちの第二回目として、 Dr.Dobb's で紹介されました。最初の記事では、 今日、これほど多くのチームが切り替えを決断している理由 について議論しました。今回の記事では、アトラシアンが行った Git への切り替えにおける技術的な側面に焦点を合わせています。 この三部からなるブログシリーズでは、アトラシアンが行
SubversionからGitに移行するときの注意点 - yukobaのブログ
自分へのメモです。SubversionからGitに移行するときの注意点。 git-svn(1) にしたがって、Subversion から Git に移行できるのですが、 git svn clone Subversionのリポジトリ Gitは色々なツールが、リポジトリ内は CR+LF ではなく、LF であることを期待しているみたいなので、上の方法で Subversion 内が CR+LF だと、Gitのリポジトリ内も CR+LF になってしまい、トラブルが起きます。 なので、上の方法で移行した後、gitattributes(5) の When text=auto normalization is enabled in an existing repository あたりに書かれている、 $ echo "* text=auto" >>.gitattributes $ rm .git/index
.gitattributesのeol=crlfは改行コードをCRLFに変換してチェックインするものではない - エンジニア的考察ブログ
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html eol This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line normalization without any content checks, effectively setting the text attribute. Set to string value "crlf" This setting forces git to normalize line endings for this file on checkin and convert them to CRLF when the f
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
Confluence
{"serverDuration": 17, "requestCorrelationId": "f12953c41087422ba55291f4cd3ff3b9"}
GitHub初心者はForkしない方のPull Requestから入門しよう // qnyp blog
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Get Great Git #1を開催しました！ - Qiita Blog
@naoya_itoさんに最近痩せたねと言われて喜びながら体重計に乗ったが全然減っていなかった！camelmasaです。 さて、今週火曜日に弊社主催のGet Great Git #1というGitの情報共有・啓蒙を目的とした勉強会を開催しました。 場所は株式会社mixi様の100名で利用できるスペースをお借りすることができました。ありがとうございます。 イベントの詳細はATNDで確認できます。 今回は第一回目ということで、Git初心者〜中級者向けの発表をしていただきました。 登壇の様子とスライドを紹介します。 Git 7つの心構え (by 株式会社クロコスCTO @sotarok) Git ライフを快適にする知られざるコマンドたち (by Increments株式会社 @uasi) pull request を利用した開発ワークフロー(by クックパッド株式会社技術部長 @hotchpotc
Git ライフを快適にする知られざるコマンドたち
Git 初心者〜中級者に向けて、目立たないけど便利なコマンドを紹介します。
www.codebreak.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
git? tig! | Atlassian Japan 公式ブログ | アトラシアン株式会社
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合： Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
引数なしのgit pushは危険なので気をつけましょう · DQNEO日記
絨毯爆撃pushの例 いまmasterブランチに、未プッシュのコミットがあるとします。 ここで、新たにbr1ブランチを作ってチェックアウトします。 $ git checkout -b br1 master $ git branch * br1 master br1ブランチでコミットを作ります。 echo hello >> hello.txt git add . git ci -m "add file" 引数なしでプッシュします。 git push すると、どこに何がpushされると思いますか？ 実は、master -> masterにpushされます。 masterがまだpushできる状態でない場合、これはかなり痛い。すごく痛い。頭が頭痛でおなかが腹痛。 しかもpushしたかった当のbr1ブランチはpushされないというオチ。(リモートにbr1ブランチがない限りは) この挙動は大半のユーザ
gitリポジトリをホストするのにWebDAV使わないほうがいい - id:anatooのブログ
共有gitリポジトリをホストする方法をググると、WebDAVを使ったやり方が結構出てくる。このやり方には明確なデメリットしか無いにもかかわらず、WebDAVを使ってホストする方法を紹介するページでは触れられていないことが多い。まったく大した話ではないが、開発者が二度とひっかからないためにリポジトリのホストにWebDAVを使わないほうがいい理由を書いておく。以下、２つ。 WebDAVを通じてホストすると遅い WevDAVを通じてホストするとサーバサイドフックが起動しない 遅い 超遅い。ベンチマークを測ったわけではないが、sshでホストする場合と比べてcloneやpushやpullが3倍以上遅いのではないか。 WebDAVでホストすると遅くなってしまうのには理由があって、sshでホストする場合とWebDAVでホストする場合とでは、そもそもの通信プロトコルが違うから。pro gitを参照すると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Flow (Japanese translation)
layer8.sh
layer8.sh