こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる？ コミットが綺麗になる！　以上です！　この一言に尽きる！ 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか？　整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います！ マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、

> 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 設

URLYou can post either your article on Qiita or your blog post. About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)

# 全ユーザで共有している設定を出力する git config --system --list # ユーザ固有の設定を出力する git config --global --list # リポジトリ固有の設定を出力する git config --local --list の3つのコマンドを続けて実行したときと同じものになるはずである。 ところが、Git for Windows 2.7.0のGit Bashで同じコマンドを実行してみると、 $ git config --list core.symlinks=false core.autocrlf=false color.diff=auto color.status=auto color.branch=auto color.interactive=true help.format=html http.sslcainfo=C:/Program Fi

Posted by OOHASHI on Mar 2nd, 2017 こんにちは、ひさっしーです！ 今回は、久しぶりにGitネタです。 Gitを使っている方のあるあるかと思いますが、急いで作業している時にコミットメッセージを書き間違えたままcommitしてしまった！なんてことありますよね。 また、グランフェアズではBitbucketで課題を発行してタスクをこなすことがあるので、コミットメッセージに「refs #25」などをつけてコミットを該当の課題と関連付けたりするのですが…これを書き忘れたり、間違えて違う番号にして関連付けをミスったり…ということもあったりします。 コミットメッセージを書き間違えた！ 課題との関連付けをし忘れた！ そういった迷えるうっかりさんを救う、「コミットメッセージを後から変更する方法」を今回はご紹介します！ 【初級編】直前にコミットしたメッセージを変更する 例えばこ

git logはオプションがありすぎて全然使いこなせていなかったので よく使いそうなものだけまとめた。 表示形式 git log --oneline --graph --decorateでそこそこ見やすく表示される。 自前のaliasが設定されていない環境でgitを使うときに頭に入れておくとよいかも。 自分は以下のようなaliasを設定している。 [alias] graph = log --graph --date=short --pretty=\"format:%C(yellow)%h %C(cyan)%ad %C(green)%an%Creset%x09%s %C(red)%d%Creset\"

git log で変更者、変更日時等の変更履歴が表示されますが、変更されたファイル名を表示するには --stat, --numstat, --name-status, --name-only などで知ることができます。 % git log --stat commit 801fe8c4bd09f91bb2172640c4857acc52f89135 Author: Yuumi Yoshida <yy@ey-office.com> Date: Sun Aug 3 12:15:30 2008 +0900 バグ対応 upload.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) commit 609aa81ec0a489cdac4cb2398918758f609a47e4 Author: Yuumi Yoshida <yy@ey-

git diff --stat [コミットId]した時に、対象のファイルの階層が深いなどの理由で .../short/path/to/filename. というように、パスが省略されてしまいます。 これを避けるには、 git diff --stat-width=800 [コミットId] とすればOK。 800という値は試行錯誤で決めうちです。 ちなみに、これを調べてる途中で見つけたんですが Githubのリポジトリの一番最初からの差分を表示するには git diff --stat-width=800 4b825dc642cb6eb9a060e54bf8d69288fbee4904 とするそうです。 参考URL： Making git diff --stat show full file path - Stack Overflow

Posted by NAGAYA on Dec 8th, 2016 こんにちは！めぐたんです。 グランフェアズでGitの運用が始まってからずいぶん経ちますが、Git Bashの設定ってあまり頓着したことがありませんでした。何だかんだデフォルトのまま使い続けています…（笑） そこで、今回は初心に帰ってGit Bashの設定などを見直してみます！Gitを始めたばかりの人はもちろん、使い慣れた人も以外と知らないことがあるかも…？です。 Git Bashとは？ Git Bashは、Windowsにてコマンドでgitの操作を利用する際に使うターミナル（いわゆる黒い画面）のこと。 Git for Windowsのインストールが済んでいると使えるようになります。

はじめましてこんにちは、今年新卒でKRAYに入社しました亀井と申します。 会社のみなさんからは「あさちゅん」と呼ばれております。どうぞよろしくお願いします。 突然ですが、みなさん使ってますか？ Git。 KRAYではバリバリ活躍してるGitですが、 「よくわからない……」と頭を抱えてる方も多いですね。 わたしも抱えてます。 正直、KRAYに入社するまでターミナルを使ったことすらなく、 Gitも入社してから使いだしたので初心者もいいところです。 そんなわたしが1日約200回×3ヶ月ターミナルでGitコマンドを打ち続けて やっとわかってきた、Gitの「これなんで？」を解説します。 主にGit初心者、Gitについて理解を深めたい人向けです。 もくじ なんでcommitする前にaddしなきゃいけないの？ ブランチってなんのために分けるの？ HEADってなんなの？ 消したファイルもコミットしなきゃい

git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ

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

git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「

社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。 本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。 (追記：第二弾できました) →　[社内新人向け]Gitで絶対にオススメなプラグインや設定3つ 社内環境 Web系開発がほぼ100％ ブランチワークはGitflowをベースにしたプルリク駆動開発 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい（vagrantや開発サーバ上の操作など） GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました CIツールはまだ導入できず。各サーバーへのデプロイ

海外でフリーランスをしているテクニカルアーティスト ゲーム開発・映像制作・WEB制作等を請け負っています。 当ブログは作業効率化のための技術ブログです。 なぜ.gitignoreの設定をするのか？ Gitでデータをコミット・プッシュする際にUnityの「Library」フォルダや「.csproj」「.sln」など、余計なデータをコミット・プッシュしてしまうと、相手側がデータを取り込んだ際に余計なUnityの設定が更新されてしまいます。 そして相手がコミット・プッシュする際にその余計なデータがリストアップされ、大迷惑をかけてしまいます。 ですので、初期設定時に余計なデータを無視するリスト「.gitignore」の設定は非常に重要です。

対応バージョン この記事の内容は、少なくともGitのバージョン2.19.1までは対応している。 もし最新のGitで新しい動きがあれば随時更新する。 基本 .gitignoreを使うと無視する（Gitのトラッキングの対象外とする）ファイル or ディレクトリを指定できる。 .gitignoreは複数のディレクトリに置くことができる。 深い階層の.gitignoreに書かれた指定の方が優先順位が高い。（後に解釈される） .gitignore内の記述は上の行から順に以下のように解釈される。 /を含まない行（fileなど） .gitignore以下の全サブディレクトリ下にあるこの名前のファイル or ディレクトリを無視する 末尾以外にのみ/を含む行（/file, /path/to/file, path/to/fileなど） .gitignoreが置いてあるディレクトリをカレントディレクトリとする相