普段から git rebase や git commit --amend をよく使っており、それらのコマンドはコミットのタイムスタンプを変更しないものだと思っていたのですが、実はコミットのタイムスタンプを変更していることに気付いて驚いたという話。 Git のコミットがもつ 2 種類のタイムスタンプ 特に何もオプションを付けずに git log すると、以下のように Author と Date が表示されます。 $ git log commit d447eeeb49d04e79b257e7abe6e633541d5e1c52 Author: nobuoka <...@...> Date: Thu Jan 31 20:45:47 2013 +0900 Prepare test tools (mocha and qunit)で、git rebase や git commit --amend で過

コミット日時を上書きしたい Gitのコミットの、差分とコミットメッセージは維持しつつ、コミット日時を書き換えたいことが稀にある。 こないだあったのは、テストのためにローカルホストの日時を未来に変更したままでコミットしてしまい、「未来のコミットになってますよw」という指摘がコードレビューで出たとき。 普通にamendしても上書きされない 通常のamendでは日付は書き換わらない。 $ GIT_PAGER= git log -1 commit 64c414eaa5084c765c79d2e061ced3d5724d00dd (HEAD -> master) Author: foo <foo@example.com> Date: Sun Sep 29 09:59:00 2019 +0900 an example $ date 日 9 29 10:02:03 JST 2019 $ git comm

対象 gitでrebaseをよくするし、mergeはマージコミットを残す人。 rebaseするとmergeのマージコミットの記録が失われるのが困る人。 概要 付け替えたいブランチの先端を作業コピーにして以下を実施 git rebase --rebase-merge <付け替え先> -i git rebase --rebase-merge <付け替えたいブランチの根本> --onto <付け替え先> -i git rebase --rebase-merge=rebase-cousins <付け替え先> -i なるべく -i をつけてTODOリストを表示し、作業内容を確認する。 --rebase-merge とは By default, a rebase will simply drop merge commits from the todo list, and put the rebased

以前に Gist で書いていたメモにコメントを頂いて知識が更新されたので、せっかくなので Zenn にも転載しようかと。 (Mermaid の Gitgraph Diagrams を使ってみたかったというのもあります) そのような感じで、たまに --onto を使おうとすると忘れているのでメモ。 基本(普通に rebase) これを こうするには 以下のように rebase を使う。

HEAD の省略形 @ git reset HEAD^ は git reset @^ と書ける (git 1.8.5 より) HEAD^ や HEAD~ を使いこなす HEAD から ~, ^ のみでこのツリー上の任意の commit を指定したいときがあるかもしれない (ない). そんなとき, 以下のように tilde と caret を使って指定することが出来る. TILDE ~ ~ は同一ブランチの前の世代を指定する. ~{数字} (~3 など) は n 世代前を指す. CARET ^ ^ は親を指定する. 親 commit には最大で二人親がおり, 一人は同一ブランチの前 commit (== 一世代前, ~). もう一人は Merge 元のブランチの最終 commit である. 後者の親は Merge commit でしか発生しない. 指定方法 同一ブランチの親: ^1 (^ と

利用シーン少なそうですが、mergeを実行する前にコンフリクトが起こるかどうかチェックしたくて調べたのでメモ。 git merge —no-commit topic-branchをmasterにマージしようとしてコンフリクトするケースを想定します。 まず試してみたのは--no-commitオプション。 (master) ✘ git merge topic-branch --no-commit Auto-merging src/hello.py CONFLICT (content): Merge conflict in src/hello.py Automatic merge failed; fix conflicts and then commit the result. これを付けておくとマージ時に自動コミットがされなくなりますが、コンフリクトが起こる場合もローカルファイルにはマージが実

※ 【追記】もうだいぶ古い情報です。 Git の pull は fetch + merge と同じというのをよく目にしますが、自分の中では違う気がしていて混乱しているので整理してみます。 認識が誤っている点などがございましたら、ご指摘いただければ幸いです。 3種類のブランチ この記事では Git の 3 種類のブランチを以下のように表現します。 リモートブランチ トラッキングブランチ ローカルブランチ リモートブランチ リモートのリポジトリで定義されているブランチのことを指します。 トラッキングブランチ リモートブランチを追跡するローカルリポジトリで定義されているブランチを指します。 ローカルブランチ ブランチを切ったり、コミットなどをしていく実際に作業をするローカルリポジトリで定義されているブランチを指します。 これらを図にすると以下のような感じです。 fetch + merge の挙動

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

今まで TortoiseGit を使って SVN のノリでだましだまし使ってたけど、そろそろちゃんとコマンドを覚えようと。 環境 OS Windows 7 64bit SP1 インストール Git for Windows をインストールする。 リポジトリを作成する git init でカレントフォルダを Git のリポジトリにできる。 .git という名前の隠しフォルダが作成される。 カレントフォルダが、そのまま 作業ディレクトリ にもなる（SVN とちょっと違う）。 以下のようにフォルダ名を指定することもできる。

$ gibo --version gibo 1.0.4 by Simon Whitaker <sw@netcetera.org> https://github.com/simonwhitaker/gibo $ gibo java ### https://raw.github.com/github/gitignore/8c9b77cb5c85f6464c0bb31abdf4cfcfdf6833bb/java.gitignore *.class # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.ear # virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml hs_err_pid*

LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 なお、Gitの基本的な考え方や使い方については分散バージョン管理システムGit入門でも紹介しているので、そちらも参照してほしい。

IDE連載の第154回です。今回はWebベースのインターフェースも備えたJavaベースのGitサーバGitblitを紹介しています。 http://news.mynavi.jp/column/ide/154/index.html Gitサーバを自前で立てようとするとインストールやら設定やらなにかと面倒ですが、GitblitはJavaで実装されており、Tomcatなどにwarファイルをデプロイするだけで使うことができます（Tomcatの場合、実際は多少Tomcatの設定を変更しなければならない箇所はありますが…）。内部的にJavaで実装されたJGitを使用しているためGitすら不要という手軽さです。 この手軽さはJenkinsに通じるものがありますね。Jenkinsの場合、当時CIツールとしては既に他のツールがあったわけですが、その導入のしやすさと使いやすさから一気に主流になり、現在に至るま

意外と面倒なGitサーバの構築 GithubやBitBucketといったサービスの登場もあり、GitやMercurialなどの分散型バージョン管理システムも一般的に利用されるようになってきた。しかし、自分でGitやMercurialを利用可能なサーバを構築しようとすると、さまざまな依存ソフトウェアのインストールや設定が必要で、意外と面倒だ。そのような場合におすすめしたいのが、今回紹介するGitblitだ。 GitblitはJavaで実装されたGitサーバで、Tomcatなどのサーブレットコンテナ上で動作する。内部的にはEclipse Foundationで開発されている「JGit」というGitのJava実装を使用しているため、warファイルをデプロイするだけで利用でき、プラットフォームも問わない。Javaさえインストールされていれば利用可能で、非常に手軽に導入することができるのだ。 Git

分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理