東京工業大学の「システム開発プロジェクト応用第一」の講義動画シリーズです。再生リスト→ https://www.youtube.com/playlist?list=PLbBGNsln3DxR3yFgCPvj40_nV-k5buTvz 今回は GitHub を使った開発のやり方を紹介します。まず、分散開発と Push/Pull/Fetch の挙動を説明します。次に Fork/Pull Request との関連を見てみます。後半はブランチモデルの紹介とそれが必要な理由を説明し、リポジトリ内/間 Pull Request の出し方を学びます。 0:23 Git を用いた分散型の開発 3:53 Clone と git remote 9:43 Push/Pull/Fetch 16:07 Pull = fetch + merge 20:46 Pull と Push の非対称性 26:50 GitH
東京工業大学の「システム開発プロジェクト応用第一」の講義動画シリーズです。再生リスト→ https://www.youtube.com/playlist?list=PLbBGNsln3DxR3yFgCPvj40_nV-k5buTvz 今回はバージョン管理システムを紹介します。主に Git の操作やデータモデルを説明します。ローカルにリポジトリを作ったり,リポジトリを複製して push/pull を試したりします。ワークツリー,インデックス,HEAD の関係を理解することで,git reset コマンドの挙動を深く理解します。3-way マージの仕組みとリベースの挙動を詳しく解説します。 00:00 バージョンを管理する、とは何か 12:25 基本的なgitコマンドたち(前置きを飛ばして見たい方はここから) 16:10 git diff 17:45 git log、git log --g
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
(注:2017/06/22、いただいたフィードバックを元に翻訳を修正いたしました。) このような経験はありませんか?「ローカルのコミットをし過ぎてしまったことに急に気づいて ローカルコミットを書き直している最中 、rebaseしすぎてしまい、自分が思い描くような履歴になっていなかった」。どうですか? 私はあります。そのような時、「ただ CTRL + Z で開始時に戻れればいいのに……」と思います。もちろん、決してそんなに単純ではありません。 GUI でさえもです。 そんな絶望的な瞬間を経験することがあったので、 git undo コマンドを独自に作成する決心をしました。以下に私のアイデアと、そこに行き着くまでの過程を紹介したいと思います。 Reflog Gitのundo操作を行うために私が最初に目を付けたのは、reflogです。「 reflogとは何だろう? 」と思うかもしれませんね。Gi
pygit: Just enough of a Git client to create a repo, commit, and push itself to GitHub April 2017 Summary: Recently I wrote approximately 500 lines of Python code that implements just enough of a Git client to create a repository, add files to the index, commit, and push itself to GitHub. This article gives a bit of background on my hack and walks through the code. Git is known (among other things
1. Getting Started 1.1 About Version Control 1.2 A Short History of Git 1.3 What is Git? 1.4 The Command Line 1.5 Installing Git 1.6 First-Time Git Setup 1.7 Getting Help 1.8 Summary 2. Git Basics 2.1 Getting a Git Repository 2.2 Recording Changes to the Repository 2.3 Viewing the Commit History 2.4 Undoing Things 2.5 Working with Remotes 2.6 Tagging 2.7 Git Aliases 2.8 Summary 3. Git Branching 3.
NetOpsCoding#4の発表資料です。現時点では事前資料ですので、講演後に予告なく資料が更新される可能性があります。
10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか? トーバルズ:俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた(データベースは別だが)。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B
「Git 2.3.0」では、新たにサーバ上のレポジトリへ、直接変更をプッシュできるようになった。サーバ上における現行ブランチへの変更が、自動的に適用され、簡単にデプロイできるようになる。 ただし、この機能では変更履歴が保存される「.git」ディレクトリが作成されるとともに、変更の適用中は、ユーザーに対して変更前と変更後の混在するデータが提供される可能性があるため、利用にあたっては注意が必要となる。 さらに、リモートレポジトリをクローンする際に、すべてのデータをクローンせず、変更が行われたデータのみクローンすることを可能にしている。また、git pushコマンドのデフォルトの挙動を変更し、上流のブランチが指定されていない場合は、プッシュを行わないようにした。 シェル変数では、オプションを指定してSSH接続できるようにするGIT_SSH_COMMANDや、cronのジョブなどでGitを使用する
Version 12.5.1 was released on February 20, 2025 Version 8.3 was released on December 16, 2024 Read Blog Post Read Blog Post 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 • G
2014年6月1日(日)、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ── Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ── Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「GitHubを利用した開発の世界を知る」「GitHubを(利用|活用)する違いを
■ GitHub Kaigiへ行ってきた GitHub Kaigiの開催案内をTwitterで見かけてなんの気なしに申し込んだら、その後あっという間に300席がうまって、その後500人へ拡大してもなおキャンセル待ちがあったとか。東京のエンジニアの勉強欲は異常や。いつものようにRubyist時間に到着したらもうすっかり席が埋まっていて、最後方入り口近くの椅子をなんとか確保*1。会場になったサイバーエージェントのセミナールームには何度か行っているけど、こんなに人が詰まっているのを見たのは初めてだ。 最初は「GitHub実践入門 ─ Pull Request による開発の変革」だったのだけど、のっけから「あれれれれ?」って感じだった。GitHubでもたらされたとされている「変革」が、どれも(GitHub登場前からの)ごく当たり前のプラクティスに見えたからだ。おかしな変数名に対してレビューアが対案
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く