これ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ commit 3a8461e04c04ed94a64df5d2cd7adbe764a2b8d8 Author: bigwheel <hogehoge@gmail.com> Date: Tue May 2 02:50:19 2017 +0900 Fix Process output method 同僚に「ちょっとそのコミットのこれ、slack DMで送ってー」なんて言うとき、あると思います。 これをなんと呼ぶか。 自分はコミットハッシュないしコミットIDと呼んできましたがどうやら正しい呼称ではなさそう。 先に結論 Git manual的には コミットのSHA-1 ないし コミット(オブジェクト)?の(オブジェクト名|SHA-1)が正しい。 もしくはPro Git - Bookには以下の表現もある。 コミッ
このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ
自前のブログからの転載。 (Qiitaにスライドってどう載せればよかったんだろうか。) このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO'Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェ
Steins;GitはSteins;Gateを用いてGitを解説する薄い本です。 Steins;GitはSteins;Gateの二次創作物です。そのため貢献をする前に次に挙げるページを読み、これらに遵守した形で貢献をしていただけるようお願いします。 著作物転載ガイドライン｜ニトロプラスNitroplus 二次創作活動における同人誌等の活動に関する取り扱いについて｜ニトロプラスNitroplus Steins;Gitの執筆方針について Steins;Gitは「Gitの使い方を、Steins;Gateの世界観を使って説明する」書籍です。「Steins;Gateのストーリーの流れに沿って、Gitの説明をする」書籍ではありません。 簡潔に書くと「シュタゲ本」というよりは「技術書」よりです。とはいえ、なるべくSteins;Gateを絡めていきたいですし、全体の雰囲気もSteins;Gateっぽくした
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 （Windowsの場合、msysgit は標準で入ってます） contrib/completion/git-completion.bash - GitHub インストール方法（引用） # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
この記事はGit Advent Calendar / Jun.27日目の記事です！ 26日目はhoshina85@githubさんの横着で神経質な私とあなたに贈るgit add -pでした。「Adventってなんなの？」って方は、Wikipediaの解説をご覧下さい。 特定の文字列を変更したコミットを探し出す テンプレの張りつけが終わったところで改めましてこんにちわ、実用Gitの訳者の一人、hirataraです。 7/1の江頭2:50さんの降誕を待ち望むAdventの期間も残り4日間となりました(残り3日間の担当者募集中です！)。今日はGitでつるはしを使って過去の遺物を掘り起こす話を書こうと思います。 つるはしとはpickaxeのことです。pickaxeはgitのサブコマンドではありませんが、gitglossaryやgitdiffcoreのドキュメント中で言及されていたり、diffcor
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
zsh で Git 使ってる人はプロンプトにブランチ名とかを表示してる人も多いと思う。 zsh に標準で入ってる vcs_info っていうのを使うとだいたいいい感じにできるんだけど、できないことも当然ある。 例えば stash した数の表示には対応していないので、自分で無理矢理な感じで Git コマンドを呼び出してプロンプトに表示してる人もいると思う。 でも zsh 4.3.11 ぐらいから vcs_info に Hooks というのが追加されて、元の機能に自分で処理を追加できるようになってる。これを使うと好きなようにカスタマイズできるようになるので紹介する。 この記事でできるようになること こんなことがプロンプトに表示できるようになる。 使用しているバージョン管理システムの名前(svn, git, hg, ...) 現在のブランチ名 マージ失敗のエラー表示 さらに Git の場合は以下
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
#!/bin/bash if [ -z "$1" ]; then echo "Error: Specify a path to the submodule directory" 1>&2 exit 1 fi if [ ! "$(pwd)" = "$(git rev-parse --show-toplevel)" ]; then echo 'Error: Run again after: cd "$(git rev-parse --show-toplevel)"' 1>&2 exit 1 fi git config --remove-section submodule."$1" || exit 1 git config --file .gitmodules --remove-section submodule."$1" || exit 1 git rm --cached "$1" || ex
Review the details about the commits from the upstream repository, then click Update branch. If the changes from the upstream repository cause conflicts, GitHub will prompt you to create a pull request to resolve the conflicts. Syncing a fork branch with the GitHub CLI GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, y
ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回 を自動化したもの」と考えられる（適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない） 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C
Git 可愛いよ、Git という訳で、最近Git の使い方を覚えてきたので、少しまとめておく。 書いたのは、下記の2コマンドのオプションについてです。 git add -p git rebase -i 両方ともSVN では出来ないですので、SVN 使っている方はGit キモい 凄いと思うこと間違いなし！ コミットの選択(git add -p) 普通のコミット 例えば、下記のような（作成中の）ソースがあるとする。 fizzbuzz.py #!/usr/bin/env python # -*- coding:utf-8 -*- def fizzbuzz(num): return num if __name__ == '__main__': for n in range(1, 20): print n これを普通にコミットする場合、add してcommit すればいい。 $ git add fi
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
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く