「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。Read less
![こわくない Git](https://cdn-ak-scissors.b.st-hatena.com/image/square/d79b6ae485a8fca73ba33170c9185573ec144a38/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fgitafraidnot-121120230705-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
このページについて 中央集権型バージョン管理のCVSとSVN、分散バージョン管理のGit両方を各プロジェクトで使用してきた経験から、新規開発、保守開発でSVNを使用し続けているプロジェクトがGitを使うメリットについて考えて書いてみるページです。 あくまでも経験を下に主観で書いていきますので、いやいやその考え方は間違っているよ!とか、これも書いといて!というのがあれば、コメントやら編集リクエストなどください。 想定読者 Gitを使ってみたいけど、保守開発だからSVNからGitに乗り換えるのなんて無理だよ!と半ば諦めている方 SVNからGitに乗り換える提案をしたいから、乗り換えることで生じるメリット・デメリットが知りたいよ!という方 うちはSVNで構成管理をしてきたんだ!Gitなんか誰も使ったことないから何かあったら誰が責任取ってくれるんだ!と使用を許してくれない上司を説得したいという方
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
社内向けに「こわくない 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 すると、空のマージコミットが作られてしまうのです。
Androidはオープンソースってやつなので、プラットフォームのソースコード一式が公開されていますが、「じゃあちょっとだけ欲しい」って際に、いかんせん最終形態は強大で、そこそこ手間(とディスク容量)を食います。 そんな「VMでUbuntuとか用意するの面倒だよ」って方のために、目的別でカンタンな順にAndroidのソースコードを確認する方法を紹介します。 SDKでソースコードが落とせるようになったので、SDK Managerから「Sources for Android SDK」というのをチェックしてダウンロードしてください。 ※ただしAPI14以降にしか対応していません。 【2. もう少しコアな部分のソースの一部だけ見たい】 OESFの協力のもと、Web上でソースコードを検索できるサービスが公開されています。 Androidソースコード検索サービス https://sites.google
はじめに もうだいぶ前に、当時主流だったバージョン管理システムである、CVSを研究して開発に使用したことがあります。 周りに知っている人がいなかったので、ネットで調べたり、本を買ってきて読んで勉強したりましたが、最初のうちは、ぜんぜん分からなくて、かなり苦労しました。 今回、Gitについて調べていて、やはり同じように、はじめは、ぜんぜん分からない状態が続きました。 CVSの時も、今回のGitの時も、「ううん、僕にはバージョン管理を理解する才能が欠落しているのだろうか? もうやめちゃおうか」とも思ったのですが、「えいくそ!」と何とかがんばって続けて、 最終的には理解できました。 この2つのバージョン管理システムの研究で苦労した経験から、 なぜ最初は全然理解できなかったのか、その理由が分かりました。 皆さんがコンピュータのソフトで分からないときは「こんなことがしたい」と思いながら ヘルプを見た
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
目的 別々に 2つの Git リポジトリがある。この2つを統合して一つのリポジトリにしたい。これらは元々同一のソースコードを管理しているものなのだが、リポジトリとして作成された時期が異なり、別々に存在していた。 経緯 ソースコードの運用者が変わったことで、一時的に VCS を利用していない期間があった。 Subversion で管理していた期間 (前々任者) VCS を何も使用していない期間 (前任者) Git で管理している期間 (現在) 我々が Git を使い始めたときには、古い Subversion のリポジトリは手に入らなかったため、最新のソースを元に新規のリポジトリとして管理を開始した。後に Subversion リポジトリが Git 形式に変換された形で手に入ったため、2つのリポジトリを統合しようということになった。 手順 http://d.hatena.ne.jp/gnarl
2. Git のリポジトリ リポジトリ = データを貯めるところ Git ではリポジトリがローカルにある SVNではローカルにないことが多い ローカルのリポジトリに対する操作は高速 (通信不要) push, pull などを使って同期を取る (通信がここで発生) 手元のリポジトリではコンフリクトしない SCMBC Git 資料 3. 多人数開発 SVNでは1リポジトリ複数ツ リー Gitでは個人がリポジトリを SCMBC Git 資料 持つ Figures from Pro Git http://progit.org/book/ja/ch5-1.html 4. 多人数開発 共有リポジトリに pull, push をする 共有リポジトリは複数ある場合も CIサーバとステージング用と、、、 SCMBC Git 資料 Figures from Pro
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Nicolás Aravena - Cómo aprender Git y no morir en el intento9punto5
SCMBootCamp in Tokyo 開催しました。KPT公開。 - うさぎ組にて手ぶらLTをしたので資料はないが、内容を軽くまとめておく。 GitとMercurialの比較 Git Mercurial リポジトリ commit objectのグラフと、branchのHEAD,tagなどの参照で出来ている。 commit objectのグラフだけで出来ている。 歴史改変サポート デフォルトであり。 デフォルトではなし。extensionが必要。 歴史改変 新しいcommit objectグラフを作成し、参照を古いHEADから新しいHEADに移す。表面上要らない歴史の削除として使われるresetはHEADの移動のみを行う。 新しいcommit objectグラフを作成し、古いcommit objectグラフをリポジトリから除去する。要らない歴史の削除として使われるstrip(MQExte
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く