Pro Git: 6.4 Git のさまざまなツール - 歴史の書き換え
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
git最強のオプション filter-branch - Qiita
Git Advent Calendar / Jun. 21日目の記事を書かせて頂きます。 今回の記事では、gitのfilter-branchを紹介します。 filter-branchとは これは、大量のコミットの書き換えを機械的に行うオプションです。 (filter-branch自体はシェルスクリプトで書かれています。) これを使うとレポジトリの歴史上からコミットされたファイルを完全に抹消することができます！ 今回、ファイルを抹消するためにfilter-branchの--index-filterオプションを使います。 使うシチュエーション こんな怖いオプションどこで使うのかというと、例えば下記のようなシチュエーションが考えられます。 パスワードファイルを間違ってcommitしてしまった or やんごとなき事情により削除したい 巨大なファイルを間違ってcommitしてしまった 1コミットだけ
Git で複数のリポジトリをまとめたり、逆に切り出したりする - Qiita
~/repo1/subdir に ~/repo2 を入れる あるリポジトリのサブディレクトリに別のリポジトリの中身を入れたいとき。たとえば、あるリポジトリのサブディレクトリを切り出して別のリポジトリとして管理しているものを、元のリポジトリに合流させたいとき。 cd ~/repo1 git remote add repo2 ~/repo2 git fetch repo2 # サブディレクトリの内容に repo2 の内容をマージする # （repo2 と内容が似ているサブディレクトリを自動で判別） git merge -s subtree repo2/master # ↑でうまくいかないときにはパスを指定する↓ git merge -X subtree=subdir repo2/master # そもそも ~/repo1/subdir が存在しないときには↓ git read-tree --p
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
Git リポジトリの統合 - エンジニアきまぐれTips
目的 別々に 2つの Git リポジトリがある。この２つを統合して一つのリポジトリにしたい。これらは元々同一のソースコードを管理しているものなのだが、リポジトリとして作成された時期が異なり、別々に存在していた。 経緯 ソースコードの運用者が変わったことで、一時的に VCS を利用していない期間があった。 Subversion で管理していた期間 (前々任者) VCS を何も使用していない期間 (前任者) Git で管理している期間 (現在) 我々が Git を使い始めたときには、古い Subversion のリポジトリは手に入らなかったため、最新のソースを元に新規のリポジトリとして管理を開始した。後に Subversion リポジトリが Git 形式に変換された形で手に入ったため、２つのリポジトリを統合しようということになった。 手順 http://d.hatena.ne.jp/gnarl
[保存版] スタートアップ、ウェブサービスの命名方法・注意点｜イケハヤ大学【ブログ版】
Inc.comにいい記事があったので、以前紹介した記事と合わせて編集してみました。 How to Pick a Great Start-Up Name | Inc.com 1. 音だけで綴りがわかるようにする 特に英語のスペルを用いる際は、音だけで綴りがわかるよう配慮すべきです。たとえば「Phaser（フェイザー）」という名前、一見かっこいいですが「フェイザー」という音だけ聴くと、「Fazer」「Faser」という綴りを想像する人も多いでしょう。 これだと覚えてもらいにくいですし、ユーザーが検索しようとしたとき、間違った綴りを入力してしまう可能性が出てきます。 2. ビビっと来る瞬間を大切にする ネーミングを考えるときは、単語をひたすらリストアップして、組み合わせたり、変化させたりします。無数の組み合わせや変化形を模索するなかで、しばしば「これはいい！」と直感が働くことがあります。 「Bl
![[保存版] スタートアップ、ウェブサービスの命名方法・注意点｜イケハヤ大学【ブログ版】](https://cdn-ak-scissors.b.st-hatena.com/image/square/987cf3f50cd33f98a8b285304ffb655ee2ab8011/height=288;version=1;width=512/https%3A%2F%2Fwww.ikedahayato.com%2Fwp-content%2Fuploads%2Flivedoor%2F2013%2Fca112b5e.png)
ヤフー株式会社を退職しました - isseium's blog
ヤフー株式会社を3月末で退職することになりました。2月28日が最終出社日でした。2010年に新卒入社し、3年間、多くの仲間と多くの経験をすることができました。 せっかくの節目なので、振り返りと今後について書きたいと思います。 少々ながいので簡単にまとめると... いろんな経験ができました いろんな仲間ができました 地域貢献をしたくて岩手にいきます エンジニアをしつつ大学院に進学します 今後もよろしくおねがいします # ぜひ岩手にお越しの際はご連絡をください！ # あ、あとよく間違えられますが、地元は「秋田」です。将来は秋田で！ http://twitter.com/isseium http://facebook.com/isseium カカオトーク: ikomatsu 振り返り はじめての配属（OJT）は、オペレーション統括本部にて、地図サービスの運用を行いました。 社内でスライディングを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
