GitHubYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
２つのコミット履歴を１つに統合する - Qiita
ここではmasterブランチに対して、Nには任意の数字をセット 実際にどのように編集するか見ていきます。 例）first_file, second_file1, second_file2のファイルを持ったリポジトリを作成します。以下の2,3を別々のコミットにするのは冗長なので１つにまとめます。 手順としては、 first_fileを新規作成してコミット second_file1を新規作成してコミット second_file2を新規作成してコミット first_fileを編集してコミット コマンドにすると以下のものになります。 #gitの初期化 $ git init Initialized empty Git repository in /Users/TechMeetMeet/Documents/work/git_work/.git/ $ git config user.email "tec
git commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
【永久保存版】初心者 ~ 上級者向け Gitをより理解するために厳選したサイトやスライドをまとめてみた | nanapi [ナナピ]
はじめに この記事は、筆者が自分自身のためにまとめたものですが。以下のような方にもとってもオススメできるのでぜひご覧ください。 これからGitを覚えたい方（まだ簡単に追いつけます！） Git使っているけど実はよくわかっていない方（怖がらず裏を理解すれば意外と簡単でシンプルなんですよ！） 日常的にGit使いこなしているけど、いざというときググってしまう方も理解を深めるのに役立つと思います。（怖くない！Git！！） Gitの基礎・振返り向けサイト Git本家！ サイトデザインもかなり洗礼！ここらへんにも人気具合が伺えます。 git-scm.com ドキュメント(日本語)も豊富で素晴らしい。 Git - Book The entire Pro Git book, written by Scott Chacon and published by Apress, is available here
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Git ブランチ操作のまとめ
個人的なメモ その２ その１は [2010-04-29-1] にあるよ。 Git では、たった一日の作業でもブランチを作ることが良くある。基本ブ ランチは修正が終わったら master に merge して削除、つまり使い捨て。 別な作業が入ったら、master から新たにブランチを作る。 cvs とか svn だと、作業単位毎にディレクトリを掘って cvs checkout と かしていたけど、Git はこれをブランチ操作のみでできる点が超便利。 ただ、他に違わず、ブランチ操作も複雑なのでメモメモ。 (1) ローカルブランチの確認 % git branch (2) リモートブランチの確認 % git branch -r (1) + (2) % git branch -a (3) ローカルブランチ bar の作成 % git branch bar (4) ローカルブランチ bar への切り
gitで共用リポジトリにpushした変更を取り消す。 - このブログは証明できない。
天ぷらを大量に食べました。油でギットギトです。というわけで、gitで共用リポジトリにpushした変更を取り消す方法です。gitって、ローカルのリポジトリを使う参考記事は多いですが、共用リポジトリを使う記事は少ない気がしますね。でも、githubのユーザーは多いと思います。 490円のServersMan@VPS (CentOS 5) をGitサーバーにする会。 - このブログは証明できない。 追記 2010-12-03 ：重要！注意を書いたつもりが書き忘れてました。共用リポジトリをいじるので、複数人で使ってる場合は他の人に影響がでますよね。注意！！ あ。間違えてcommitしちゃった。しかも、共用リポジトリにgit pushしちゃった。しかも、50万円もする布団買っちゃった。まず、間違えてcommitしただけなら、git resetを使います。 $ git reset --soft HEA
git のブランチ名を zsh の右プロンプトに表示＋ status に応じて色もつけてみた - ヤルキデナイズドだった
Update 改良しました→ git のブランチ名 *と作業状態* を zsh の右プロンプトに表示＋ status に応じて色もつけてみた - ヤルキデナイズドだった 以下古い情報 こんなんなります。 作業ディレクトリがクリーンなら緑 追跡されていないファイルがあるときは黄色 追跡されているファイルに変更があるときは赤 変更あり＋未追跡ファイルありで太字の赤 そんな感じで。 コード # ${fg[...]} や $reset_color をロード autoload -U colors; colors function rprompt-git-current-branch { local name st color if [[ "$PWD" =~ '/\.git(/.*)?$' ]]; then return fi name=$(basename "`git symbolic-ref HE
はじめてのgithub
世界一簡単なGithub入門（githubは無料で使用する場合、全てのファイルが公開されていることにご注意ください） ややこしいコマンドを全スルーして個人用バックアップとして使ってみる 2013.01.26 LDD13 LT 【概要】 次々と新しい技術やサービスが公開され、いろいろ挑戦してみたい・・・とは思うのですが、それが複雑なものだったり高機能であったりすると、どうしても最初のハードルが高く、なかなか踏み出せないと感じます。 そんな時、私の場合は、とりあえず、できるだけ簡単なマニュアルを探してきて、良く分からないところは全部無視して無理やり使ってみることにしています。訳が分からないままでも、使っていることで、ちょっとずつイメージが湧いてきて、画面が見慣れたものになってきます。そして、それから改めて入門書を読み始めます。そうすることで、最初のハードルが、少しは下がるのではと考えています。
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
Vimmer 達の vimrc - はやくプログラムになりたい
有名な Vim 使いが github で公開している vimrc を簡単にまとめてみました． 一段落ついたら参考にして自分の vimrc を見直そうと思います． Shougo さん https://github.com/Shougo/shougo-s-github/blob/master/vim/.vimrc kana さん https://github.com/kana/config/blob/master/vim/personal/dot.vimrc tyru さん https://github.com/tyru/dotfiles/blob/master/dotfiles/.vim/init.vim ujihisa さん https://github.com/ujihisa/config/blob/master/_vimrc tpope さん https://github.com/tp
git初心者向けのTipsなど - os0x.blog
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
まだ使っていない人にこれだけは伝えたいgitの便利機能 - (ﾟ∀ﾟ)o彡 sasata299's blog
2010年12月26日11:03 Git まだ使っていない人にこれだけは伝えたいgitの便利機能 ということで、今更ですけど git は便利ですね〜。もう subversion には戻れません。気が向いたので、個人的に気に入っていることをちょっと書いてみます。 1) 直前のコミットに対して、コミットし忘れたものを追加できる よくありがちなパターンですね。一通りコミットしたあとに「あっ！○○をコミットし忘れた！」とか、「××を一カ所修正し忘れていた」みたいなことってあると思います。subversion だとそういうのでコミットが増えて履歴が汚くなってしまうものですが、git だと簡単に直前のコミットに忘れてたものを追加して隠蔽(笑)することが可能です。 例えば hoge というファイルをコミットし忘れた場合を考えてみます。 $ touch hoge fuga foo $ git add fu
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitignore.io - Create useful .gitignore files for your project
longkey1.net
http://www.machu.jp/posts/20100703/p01/
Gitを使い始めたらやっておきたい便利な設定いろいろ
