追跡ブランチ (tracking branch) というブランチが何なのか調べた - snowlongの日記
まとめ 追跡ブランチを指定する git checkout -b fb_track origin/develop あとから追跡ブランチを指定する git branch --set-upstream-to origin/[branch-name] 追跡ブランチ (tracking branch) という概念がわからない 以前、「tracking branchを指定していないからgit pull してもこのブランチには更新されないよ〜」と言われたことがあり「？？？」となったまま疑問を解消せずに放置を決め込んでいた。 いちおうGit/Githubは操作することはできるけど、きちんと理解したいな、疑問点はすぐに解決しないとなと思いたち調べてみました(1年以上放置してきた疑問だけど:p)。 master とorigin/masterの違い まずは、「master とorigin/masterの違い」に
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
magit.el を試してみた - gom68の日記
egg.elいまいちーと書いたところ、 @gom egg.elが嫌ならmagit.elでどう？俺的にはそっちのが使いやすいけど。 http://twitter.com/rubikitch/statuses/1901340067 と id:rubikitch さんに教えてもらいました。ありがとうございます。 というわけで、早速試してみた。 インストール makeするのね $ git clone git://github.com/jdhuntington/magit.git $ ./autogen.sh $ ./configure --prefix=$HOME/lisp/magit $ make $ sudo make install .emacsの書き換え (add-to-list 'load-path "~/lisp/magit/share/emacs/site-lisp/") (requ
cdせずに任意のgitレポジトリを操作する-Cオプションの紹介 · DQNEO日記
例えば、git pullとかするときはcdしてからgit pullする人が多いと思います。 たとえばrbenvをアップデートしたいとき、 $ cd ~/.rbenv $ git pull $ cd ~/.rbenv/plugins/ruby-build $ git pull なんてしますよね。 でもいちいち cd するの面倒くさいと思いませんか？ 実はgitには -C オプションというのがあって、これを使うと cd せずにレポジトリの場所を指定することができます。 git -C <レポジトリの場所> サブコマンド という風に使います。 なので、さっきの rbenvを更新する例はこのように書けます。 $ git -C ~/.rbenv pull $ git -C ~/.rbenv/plugins/ruby-build pull シェルスクリプとかcrontabから git を実行するときは大
とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
ぐにゅぐにゅ動く直感的なGitクライアント ungit｜TechRacho by BPS株式会社
ungitはnode.jsで動くグラフィカルなgitクライアントです Learn Git Branchingみたいな直感的なGUIで操作できるので とても分かりやすいです インストール 今回はnvmを使用してnode.jsを入れます $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm install v0.10.22 $ npm install -g ungit $ nvm use v0.10.22 ログイン時も有効にしたい場合は.bashrcに以下のように書いておきます if [ -d $HOME/.nvm/ ] then source ~/.nvm/nvm.sh nvm use v0.10.22 > /dev/null fi 起動 以下のコマンドで
Git入門 v1.1.0
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
git reset と git revert についてメモ - u16suzuの blog
git reset もとに戻す。変更履歴は残らない。 指定したリビジョン以降のコミット全てを無かったことにする。 ex1. git reset HEAD^ --soft ex2. git reset HEAD~3 --hard ex1. 1個前に戻す。working directoryは無変更 ex2. 3個前に戻す。working directoryも戻す。 git add foo したファイルを以下の方法で取り消すことが可能 $ git reset HEAD foo git revert もとに戻すためのパッチを作成する。 変更履歴は残る。default で --hard がついている。 指定したリビジョンのコミットのみ無かった事にする。 ex3. git revert HEAD~2 ex3. ２個前のコミットのみをなかった事にする。 git reset はgit add を取り消すの
gitで差分ファイルを抽出する - Qiita
案件で「作業の差分を納品してくれ」とか言われることってよくあります。 今までは手作業でディレクトリ作って、ファイルをコピーしてましたが、 もう、そんなうんざりする作業とはおさらばできそうです。 git archive と git diff の合わせ技で差分を出力できる事がわかったからです。 例えば、一個前のコミットから現在のコミットまでの差分を取り出したい時は、 git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o archive.zip まずは、git archive について。 --format=zip を付けるとzipで固めてくれます。 --prefix=root/ は抽出したファイルをrootディレクトリに入れた状態にしてくれます。 -o a
Git初心者に捧ぐ！Gitの「これなんで？」を解説します。
はじめましてこんにちは、今年新卒でKRAYに入社しました亀井と申します。 会社のみなさんからは「あさちゅん」と呼ばれております。どうぞよろしくお願いします。 突然ですが、みなさん使ってますか？ Git。 KRAYではバリバリ活躍してるGitですが、 「よくわからない……」と頭を抱えてる方も多いですね。 わたしも抱えてます。 正直、KRAYに入社するまでターミナルを使ったことすらなく、 Gitも入社してから使いだしたので初心者もいいところです。 そんなわたしが1日約200回×3ヶ月ターミナルでGitコマンドを打ち続けて やっとわかってきた、Gitの「これなんで？」を解説します。 主にGit初心者、Gitについて理解を深めたい人向けです。 もくじ なんでcommitする前にaddしなきゃいけないの？ ブランチってなんのために分けるの？ HEADってなんなの？ 消したファイルもコミットしなきゃい
Gitの忘れがちだけど絶対に使うであろうコマンド達 | Basicinc Enjoy Hacking!
ベーシックでは、Gitを使ったバージョン管理システムを導入しています。一部のプロジェクトでは先行して導入していたものの、全社的にはまだまだ…といったわけで、よくGitコマンドについて質問されるので、ここで軽くまとめておきたいと思います。 普段は git add / commit / push / pull しかしてない…っていう人向けです。 addしたファイルを取り消す $git reset HEAD ファイル名 更新内容自体は取り消さず、addしてインデックスに登録するのを取り消します。 更新したファイルの更新内容を取り消す $git checkout ファイル名 commitする前限定です。 他ブランチの特定のコミットだけマージしたい $git cherry-pick コミットID とても便利なコマンドですが、cherry-pickを多用するような運用スタイルになっていたら問題なので、
transitive.info - git blame 使い方
git blame 使い方 ファイルの各行がどのコミットのものか調べる file.txt に対して git blame file.txt とすると、 各行毎にコミットのハッシュ値、著者、時間が表示される。 git blame の出力を変更する -f コミットのファイル名を表示する -s 著者とタイムスタンプを表示しない -l ハッシュ値を短縮しないで表示する 行番号で指定した範囲の各行がどのコミットのものか調べる 「-L」オプションで範囲を指定できる。 行番号で指定するには数字を二つコンマで区切って指定する。 また、「+」と「-」を使ってオフセットを指定できる。 git blame -L 5 file.txt git blame -L ,5 file.txt git blame -L 5,10 file.txt git blame -L 5,+3 file.txt git blame -L
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 への切り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あとからまとめて.gitignoreする方法 - Qiita
https://qiita.com/takashibagura/items/6d03cdd9ab2f88df828d
gitで複数のコミットを1つにまとめる | Webシステム開発／教育ソリューションのタイムインターメディア
http://blog.inouetakuya.info/entry/20120826/1345979787
