このページは別のブログに移転しました。

git でファイルを無視するには、通常は .gitignore や .git/info/exclude を使います。 しかし、既に git 管理下にあるファイルは、これらの設定があっても無視されません。 以下の方法を使えば、git 管理下にあるファイルをあえて無視することが可能です。 方法 次の2つの方法があります。どちらを使っても、ファイルの変更を無視できます。 方法(1) assume-unchanged

前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には

Git のコミットには、Author と Commiter の2つが存在します。 例えば、いつもと違う PC を使ったときに、.gitconfig の設定が違うと、コミットに意図しないメールアドレス・ユーザー名が入ったりします。 Git で見るとこんな感じ $ git log -1 --pretty=full commit befdbcd2389373088fe3e83d9c0d401a9de7717d Author: hogehoge <dummy@example.com> Commit: fugafuga <test@example.com> add test.txt GitHub 上では、コミットに表示される、いつもの自分のアイコンが表示されなくなるので、ちょっと気になります。 そこですでにコミットしてしまった、コミットの Author と Commiter を変更する方法についてま

id:naga_sawa:20110119:1295420861 git でメールアドレスやら名前やらを間違えて commit してしまったときの修正方法 - ..たれろぐ.. しかしStack Overflowで紹介されていた git-filter-branch(1) ベースの手法の方が楽だった． http://stackoverflow.com/questions/750172 version control - How do I change the author of a commit in git? - Stack Overflow 対象commit範囲 (eg. HEAD~10..HEAD) を全て特定のauthor名に書き換えたいとき（ワンライナー）： git filter-branch -f --env-filter "GIT_AUTHOR_NAME='Newname';

既存のGitレポジトリを、GithubやBitBucketのようなホスティングサーバに移行したり、逆にローカルサーバのGitBucketやGitLabなどに移行したい場合、まあ単純にpushすればいいやんと思ったら、思うような結果にならなかったり、面倒な手順になってしまったりしてしまった。 どうも自分のワーキングのレポジトリから飛ばそうとすると、tagだったりbranchだったりが移行できていないかったりするのです。 ぐぐると、いったんローカルにリモートと同名のブランチ作って(checkoutして)から、push --all, --tags とかしてる奴とかありますがそれは面倒だなぁやだなぁみたいな。 最終的には、これが一番楽な手順かなと思う手順に行きつけたのでここに記す。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd <REPOSIT

> git diff diff --git a/main.cpp b/main.cpp index 198f012..6e1f7d5 100644 --- a/main.cpp +++ b/main.cpp @@ -4,7 +4,8 @@ int main() { A a; - printf("%X", &a); + printf("address = %X", &a); + hello(); hello(); return 0; } WinMerge によってグラフィカルに確認・編集できるようにする。 同様にマージ作業も行えるようにする。 環境について 今回の環境を参考までに。 Windows 7 Home Premium 64bit WinMerge 2.4.0.68+-jp-68 (Japanese Unicode X64) git version 2.6.4.windows.1 設

この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する機会が多いので、その経験から、どんなことに注意しながら進めていけばいいか書いてみます。 記事は 「紹介編」,「導入後編」,「おじさん編」の３つの編から構成されています。 紹介編 Git はバージョン管理ツール、 GitHub は Git のホスティングサービ

この記事ではGitの導入までに体験した苦難や失敗と、それを乗り越えた方法を紹介します。 「えっ、今更」と思われるかもしれませんが、Gitを初心者にレクチャーする際などに参考になれば幸いです。 はじめに 僕の働く開発チームは、40代〜50代の職人的なエンジニアが大半を占める、レガシーな開発環境のチームでした。開発項目と線表はExcelで管理され、バージョン管理システムは活用されておらず、何かを開発すれば何かがデグレを引き起こす、そんなことが日常茶飯事でした。 しかし今では、エンジニア全員がGitのコマンドを使えるようになり、git-flowを用いた開発やリリースを並行して進め、RedmineやGitbucketを活用しています。開発チームにGitを定着させるまでのアプローチを紹介します。 まずはGitを知ってもらう 僕はまず、Gitの特徴と使い方をまとめた資料を作り、開発チームへ説明をしまし

こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す

2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん

GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。 GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste

タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま

Gitは特定のコマンドが実行された場合に、スクリプトを起動させることができる。 そのスクリプトは.git/hooks フォルダに特定の名称で作成することで実行される。 検証プログラム 検証環境は以下の通り Debian7.0 git version 1.7.10.4 フックの動作を検証するために、各フックスクリプトに下記を記述する。 #!/bin/sh logger "********************************************" logger ${0##*/} logger "param $*" logger "param cont $#" logger "input..." while read i; do logger ${i} done これにより、フックスクリプトの発生順と、パラメータ、標準入力の検証が行える。 フックの確認 commitコマンドのフッ

Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので