gitでコミットの順序を入れ替える | Webシステム開発／教育ソリューションのタイムインターメディアgitでは様々な方法でコミットログを書き換えることができます。 その一例としてコミットの順序を入れ替える方法を紹介します。 問題 とある新機能Xを追加することになったとしましょう。 まずはこの作業用のトピックブランチを作成します:
git/コミットログを修正する方法 - TOBY SOFT wiki
はじめに † gitでコミットログを修正したいです。 Redmineとかで、refs #10とかcloses #10とかつけるとコミットログにチケットを関連付けられますが、これがよく書き忘れるんですね…。 直前のコミットログを修正する方法あるみたいです。 直前のコミットログ以外も修正する方法はないのかな…。 (Subversionだとhookスクリプトで許可できますよね。分散型だとやっぱり無理？) ↑ 直前のコミットログを修正する方法 † 直前のコミットログの修正は"git commit --amend" でよいみたいです。 例えば、 $ git commit -m "fixed xxx bug" : # コミット完了! # あ！しまった！"refs #(チケット番号)"つけるの忘れてた！ # (私が使うプロジェクト管理ツールRedmineではrefs #13 のようにすると # コミット
「githug」でgitの基本操作を算数ドリルみたいに学ぼう！ | Act as Professional
GitHubのイベントである「The GitHub poweredby Agile渋谷 〜日本のSOCIAL CODINGの今を見る〜」の懇親会を受付始めました@HIROCASTERでございませう。 イベント参加者以外でも参加可能のため、イベントは補欠だったけど、どういうふうにGitHubを使っているのか聞きたい人は、ご参加ください。（イベント参加者優先で、空気読んで登録してください） イベントではGitHubの話をするので、Gitが使えることが前提になっています。 そこで、Gitの基本操作方法を学べる「githug」を紹介します。 githug Gazler/githug「githug」はgitの基本操作を実践的に学ぶための良いソフトウェアです。 特に他のバージョン管理システムを使ったことのある人がgitの基本操作だけを学ぶだけならちょうど良い。 インストールgemで公開されているのでイ
git-cherry-pickを掘り下げる - idesaku blog
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
[デザイナー向けGit解説] みんなで開発できるGitのカタチ | uniq-style
私のまわりには「バージョン管理が未体験」なデザイナーさん多いです。 デザイナーでも、プログラマーと一緒に仕事すると、Gitやsvnを使うことになると思うんですが、Gitとかsvnはまず「その仕組みとかカタチとか」が、デザイナーにとっては分かりにくいと思います。 そんなわけで（元）デザイナーの私が、理解してる範囲のことを分かりやすい言葉で解説してみます。 例の図を描いてみました。 だいたいこんな感じなのですが。。。 解説すると みんなの場所 プログラマーの人がremote（りもーと）とかorigin（おりじん）とか言ってる場所です みんなのファイル共有置き場です branch（ぶらんち）というものがあります。branchはプロジェクトやリリース毎や機能ごとに作られます。 図では「デイリーランキング機能追加用のdaily-rankingというbranch」「検索ページリニューアル用のse
Git だろうと Mercurial だろうと、ブランチ名をzshのプロンプトにスマートに表示する方法 - mollifier delta blog
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl
Gitのベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
GitをupgradeしたらWarning: Non-libraries were installed to "lib".と表示された - A Way of Code
結論：気にするな (Conclusion: Ignore it.) homebrewからgitをupgradeしたら、Warningが出たので調べてみました。 1 ==> Caveats 2 Bash completion has been installed to: 3 /usr/local/etc/bash_completion.d 4 5 The 'contrib' directory has been installed to: 6 /usr/local/share/git-core/contrib 7 Warning: Non-libraries were installed to "lib". 8 Installing non-libraries to "lib" is bad practice. 9 The offending files are: 10 /usr/local
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
Git Immersion
A guided tour that walks through the fundamentals of Git, inspired by the premise that to know a thing is to do it. Git is a powerful, sophisticated system for distributed version control. Gaining an understanding of its features opens to developers a new and liberating approach to source code management. The surest path to mastering Git is to immerse oneself in its utilities and operations, to ex
入門Git (Chapter1〜4) - 車輪を再発明 / koba04の日記
今の職場がバリバリgitなことや、githubをちゃんと活用したいなという思いから、読むことにしました。 同じような入門系の本として、 「入門git」というかなり似たタイトルの本もあってどちらにするか迷ったのですが、Gitの開発責任者が書いている点に惹かれてこちらを読むことにしました。 もう一方の本はこちら。こっちの方が使い方メインで載っていてわかりやすいという声が多いような気がします。 入門git 作者: Travis Swicegood,でびあんぐる出版社/メーカー: オーム社発売日: 2009/08/12メディア: 単行本（ソフトカバー）購入: 25人 クリック: 305回この商品を含むブログ (101件) を見る gitはバージョンによってオプションなどが変わっていたりすることがあるみたいです。自分はhomebrewで入れた「1.7.3.5」で動かしています。 Chapter 1
入門Git (Chapter7) - 車輪を再発明 / koba04の日記
Chapter 1 〜 4 http://d.hatena.ne.jp/koba04/20110114/1294936149 Chapter 5 〜 6 http://d.hatena.ne.jp/koba04/20110124/1295795842 Chapter 7 ブランチを使った開発 「git checkout -b branch_name」でブランチを作る % git checkout -b test1 これは下記のようにブランチを作ってそれを使用するのと同じ結果になります。 % git branch test1 % git checkout test1 ブランチの名前は関数名と同じで目的をわかりやすく！ 「git branch」で現在のブランチを確認 下記のような感じで「*」がついているブランチが現在のブランチになります。 % git brach master * test1
あまり知られていないGitのTips - アジャイルSEを目指すブログ
思い浮かんだ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 initしたあとにリモートを追加してorigin masterを省略するメモ - がぶちゃんの日記
先に結論 git remote add origin git://gabuchan.git git push -u origin master どういう場合に便利？ git cloneすると.git/config が [remote "origin"] url = git://gabuchan.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/masterみたいになるので、git pushでorigin masterを省略できる。 ローカルでgit initしてリポジトリを先に作って、 ちゃっちゃか開発して、 「そろそろリモートにアップしとくかー」って感じでリモートを作って、 git remote addすることが多い。 ちょっと開発をはじ
たのしいGit - Nalsh's Notes
序 言うまでもないことだが、タイトルはジョークである。 そもそもバージョン管理は本来我々がしたい事ではない（一部の人を除く）。別に作りたいものがあり、そこでの作業を円滑に進めるためにバージョン管理するのだから、所詮はヤクの毛刈りである。さらに、Gitクライアントのへっぽこさも相まってなかなかに時間を食われる。この文書はそのような人々が、より円滑にGitを使えることを祈って書かれた。 なお、バージョン管理というのはとても複雑なシステムであるため、バージョン管理自体が目的な人には楽しい世界である。そのような人々はぜひGitやその他のバージョン管理システムのマニュアルやソースコードを読んでいただきたい。きっとその奥深い世界を堪能できることだろう。 Git概説 Gitはこれまでの旧来のバージョン管理システムとは一風違った設計で作られている。また、Git特有の概念も多い。なので、まずGitの概観を説
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bayashi.jp
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
[git] 共有リポジトリを作る：git init --bare --shared=true - satoko's blog - s21g