Gitのゆるめな勉強会 ワークショップ進行スライド
ローカルで GitHub を構築! Git リポジトリ管理ツール「GitLab」を Mac OS X にインストールしてみた GitLab とは GitLab は Git リポジトリを簡単に管理できるツール Gitolite をブラウザから管理できるようにする Ruby アプリケーションです。 GitHub のオープンソースクローンと呼ばれることから分かるように、UI が GitHub とめっちゃ似ています。 GitHub みたいなサービスを使いたい!だけど Public はアレだなということもあると思います。そんなときに便利です。 社内 GitHub として使うケースが主なユースケースだと思います。 しかもすべてローカルだけで作ることができるので、ローカルマシンにインストールすれば、構築後はネットワークなしで GitHub 的な環境を使うことができます! そんな GitLab を Mac
2013年 02月 05日 デザイナーでも使うと便利なバージョン管理システムGitの勉強会に参加しました カテゴリ: Git タグ:Git この週末にGitの勉強会を開いてもらって基礎的なところから教えてもらいました。これまで興味はあったけど全く何も知らなかったので、いろいろ詳しく教えて頂きました。 1.Gitとは? 2.用語解説 3.実際に使ってみる。msysgit 4.参考文献 Gitとは? 分散型バージョン管理システムの一つです。ファイルの更新状態を好きなタイミングで保存しておくことが出来、好きなタイミングで保存している状態へ戻したり、編集した箇所の差分を表示したりする事が出来ます。 また、プロジェクトを複数人で進行している場合に起こりうる、古いファイルでの最新ファイルの上書きといったトラブルについても、Gitを利用すればエラーが帰ってくるため避けやすくなります。 尚、Gitと聞くと
まず、リモートブランチを最新に更新しておく。 $ git fetch $ git svn fetch # git-svnでSubversionレポジトリをリモートリポジトリに持つ場合 リモートブランチを確認。 $ git branch -a * master remotes/origin/master remotes/svn/tags/RELEASE_20101022 remotes/svn/tags/RELEASE_20101025 remotes/svn/trunk 現在のローカルブランチとリモートブランチの差分を表示。 $ git diff remotes/origin/master 現在のローカルブランチとリモートブランチの差分を表示(簡易表示) $ git diff --name-status remotes/origin/master 現在のローカルブランチとリモートブランチの
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 3 日、Jonathon Creenaune 投稿 “From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development“ このポストは、エンタープライズ開発チームが Git に切り替えることに注目した連載記事の一つとして、Dr.Dobb’s で紹介されました。 アトラシアンでは、ここ何年もの間、DVCS に熱狂していました。私たちは DVCS に多額の投資を行ってきたのです。Bitbucket (クラウド DVCS リポジトリのホスト) を買収し、Stash (社内環境での Git リポジトリマネージャ) を開発しました。さらに、Fish
Git 合理的なブランチ戦略 crocosの中のひと Gitを使った開発 Git移行について考える svn up = git pull svn ci = git push という考え方はやめる。 Gitに移行するということは、svnに対応するコマンドを おぼえることではない。Gitを最大限活用する開発フローを 考える。 ローカルで気軽にコミット ローカルで気軽にブランチを切る 賢く、高速なマージ それを活かしたブランチの戦略を考えるべきである。 Gitのブランチ戦略とは どのようにブランチを切るか 日々の開発 リリース 緊急対応 などをこなすか A Successful Git Branching Model http://nvie.com/posts/a-successful-git-branching-model/ Master 常に最新の安定したソースコード カタマリごとにmerge
チーム開発で Git を使ってから半年ちょい位経ちました。 Git 玄人な人たちに囲まれて開発していたおかげで、そこそこ Git 力がついてきました。 そんな中で、ブランチの統合(マージ)についての考え方が大分固まって来たのでまとめます。 まずは結論から。 統合するブランチ → 統合されるブランチ : 統合の為に使うコマンド ローカル(自分用) → ローカル(自分用) : 適当に ローカル(自分用) → ローカル(リモート用) : merge --squash リモート → ローカル(リモート用) : pull --rebase ローカル(リモート用) → ローカル(自分用) : rebase ローカル(リモート用) → ローカル(リモート用) : merge --no-ff ローカル(リモート用)は、リモートドラッキングブランチからチェックアウトしたブランチを指してます。 要は、git
Issues with git-flow I travel all over the place teaching Git to people and nearly every class and workshop I’ve done recently has asked me what I think about git-flow. I always answer that I think that it’s great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner.
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
Gitの本質は「コミットオブジェクトのチェーン」 コミットには親子関係がある。 子は親を参照している。 子の名前(=コミットハッシュ値)が特定できれば先祖をたどれる。 コミットオブジェクトがチェーンのようにつながっているので、「コミットオブジェクト・チェーン」と理解しましょう Gitとは、コミットオブジェクトのチェーンなのです。 (専門的には「オブジェクトグラフ」と言います) ブランチとは枝のことではない ほとんどの初心者が勘違いしていますが、ブランチとは「枝」のことではありません。 ブランチの正体は「立て看板」です。 「ラベル」といってもよいでしょう。 それは、コミットオブジェクトにつけられらた「別名」のことです。 下記の図でいうと、"branchX"とはコミット"C"を指します。 「アメリカ大統領」という言葉と「バラク・オバマ」という言葉は、同一人物を指しますよね? まさにそれといっし
コンフリクトしたときに便利そうなので、備忘録を残しておく Gitのコマンド コンフリクトしているファイルの一覧を表示する。 $ git ls-files -u [<path>] ファイルの状態(コンフリクト含む)を表示する。 -s でshort-format で特定のディレクトリのファイル一覧を表示できる $ git status [<path>] 手動で直す方法 修正後にaddが必要 $ vi <path> (手動でコンフリクトを直す) $ git add <path> mergetool でマージする方法 -y でデフォルトのマージツールが実行する で1つずつ指定できる $ git mergetool -y [<path>] をHEADと同じ状態にする。 修正後にaddが必要 $ git checkout --ours [<path>] $ git add <path> をマージで指定
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です! こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ? A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー(説明は省略) 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く