このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

.gitignore を設置 GitHub に .gitignore のテンプレートがあるのでそれを使うとらくです。 github/gitignore .gitignore をコミット チームで開発していたり、複数のマシンで編集する可能性がある場合は、他の環境でも同様にこれらのファイルを無視してくれるように、.gitignore 自体をコミットしてしまいましょう。

ネット上で複数のアカウントやら人格やらを使い分けてる git 使いの方必見。 git でメールアドレスやら名前やらを間違えて commit してしまったときの修正のやり方。 きげんよく開発＆コミットをしてきてふとコミットログを確認すると、 D:\ToaruGitNoRepository>git log -2 commit d104bc235464568b95bf18b00e00583b90a8ccbb Author: foo Date: Tue Jan 4 17:48:40 2011 +0900 新環境に合わせて環境変数設定用のbatファイルを更新 commit e566fc3bde92333b1e60f9cb508cbd13ba4f0cbe Author: hogehoge Date: Tue Jan 4 17:20:44 2011 +0900 関連ファイルの再配置 「やっべ！裏アカウン

これでコメントの内容を修正して、:wqで保存して終了すれば書き換えられます。 直前以外のコミットログを修正する 例) 過去3つ分のコミットログを修正 1. 編集対象のコミットを選ぶ

GitHub で awslabs のリポジトリを眺めてたら git-secrets という便利なツール（シェルで実装されてる）を発見した． どんなものかを簡単に説明すると，アクセスキーなどを誤ってコミットすることを Git の hooks を使って未然に防ぐツールで，誤って GitHub に push してしまったために，AWS を不正利用されてしまった，みたいな事故もたまに聞くし，そういうのを防ぐことができる．非常に良かったので，一部のリポジトリに git-secrets を設定した． github.com インストール make install でも良いけど，Mac なら brew が使える． $ brew install git-secrets インストールすると git secrets コマンドが使えるようになった． $ git secrets usage: git secrets

git pull して、リモートブランチの最新に合わせようとしたら・・、あれ？コンフリクト・・？なにこれ、うまくいかない！「git push -f origin masterして強制Pushはできたのに。git pull -f origin master的な強制コマンドはないの？！」 とにかくリモートに合わせたい。そんなあなたのための、解決方法と解説です。 「git pull --force」は存在しない・・。 「git push --force」というコマンドがあるので、そこから連想してしまいますが、「git pull --force」というオプションは存在しません。 git pull の強制的に実行するには、別のコマンドが必要になりますので、見ていきましょう。 git pull で、ローカルを強制上書きする方法 ローカルのmasterを、強制的にリモートのmasterに合わせる //

It has been archived by the owner. It is now read-only. 日本語翻訳に関するメモ Git や GitHub の便利な使い方をまとめたられた GitHub cheat sheet の日本語訳です。 もっと分かりやすくしたいので翻訳に関するダメ出しは歓迎です。 レポジトリ

開発当初はローカル環境でgitを使っていたが、 途中からgitHubにpushする際の手順を説明します。 gitHubにアクセスし、新規リポジトリを作成する https://github.com/ 1、リポジトリ名入力 2、Public選択(有料アカウントならPrivateも選択可能) 3、Create repositoryをクリックしてリポジトリを作成する。 リモートリポジトリを登録する 新規リポジトリ作成後に表示される上記画面の1の内容をコピーし、 以下の内容をターミナルに入力する。

概要 macOS 10.12 (Sierra) で、キーチェーンが SSH のパスフレーズを憶えてくれず、毎回入力しなくてはいけなくて煩雑。 shao-01:~/dev/ % git clone git@github.com/some-organization/some-repository.git Enter passphrase for key '/Users/shao/.ssh/id_rsa':

ソフトウェアエンジニアの @DQNEO です。こんにちは。 Gitの内部構造を深掘りするシリーズ３回目です。 前回までのお話はこちら Gitのつくりかた – Mercari Engineering Blog Gitのコミットハッシュ値は何を元にどうやって生成されているのか – Mercari Engineering Blog 今日はみんなだいすき「ステージング領域」の中身について解説してみます。 ステージング領域とは何か？ 簡単に説明すると「次にコミットしたときにコンテンツとして登録されるもの」リストです。(別名「インデックス」ともいいます。) このリストは、 git addやgit rmしたときに書き換わります。 (古くはcacheと呼ばれていました。内部実装やgit diff --cachedに今もその名残があります。) git addのマニュアルに説明があります。 Git – git

はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか？と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals

こんにちは。サーバサイドエンジニアの @DQNEO です。 前回の「Gitのつくりかた」に続いてGitのコアな部分のお話です。 Gitのコミットハッシュ値とは何か Gitを使っていると必ずコミットハッシュ値というものが出てきます。9e47c22みたいなアレです。 これはある特定のコミットを指し示すIDとして使うことができます。 では質問です。 このコミットハッシュ値は「何を元に」「どうやって」計算されているでしょうか？ 「ある特定のコミット」とはそもそも何なのか この問題を考える前に、まず「コミットとは何か」を明らかにしておきましょう。 コミットというと「コミットする行為」すなわち「動作」のことを想像するかもしれません。 しかしGitの内部構造的観点から言うと、Gitが管理記録しているのはコミット行為の結果生成されたデータの方です。 この「コミットによって生成されたデータ」のことを「コミッ

こうしてコミットhogehoge3が作成された。 ここで問題。 ブランチ"feature/fuga" にも、コミットhogehoge3を反映したい。 このとき、どういう操作をすればいい？ feature/fugaにて を再度行えばいい？ （つまり、 hogehoge1, hogehoge2, fugafuga1, fugafuga2 から hogehoge1, hogehoge2, hogehoge3, ffuuggaa1, ffuuggaa2 にする） ただ、feature/fugaがローカルにのみ存在している場合はそれでもいいが、 既にリモートにpushされていた場合、コミットのSHA-1が変化してしまい、 同内容のコミットが複数現れることになってしまうのでは…？ fugafuga1とffuuggaa1の内容は同じだが、SHA-1が違うので別のコミットとみなされてしまうはず。 …えーと

Kaleidoscopeの設定 menu→Integrationを選択。「git」を選択。 step1で「Install」をクリックしてKaleidoscopeのCLIをインストール step2で「Configure」をクリックしてKaleidoscopeをgitのdiftool、margetoolのデフォルトに設定 gitのdiftoolでKaleidoscopeを使用 上記の設定が完了していれば、デフォルトのdiftoolにKaleidoscopeが設定されてるので下記のコマンドでKaleidoscopeが立ち上がる。 デフォルトのツールには指定したくないが時々使いたい場合 上記同様、menu→Integration→gitを選択。 下部の方にdiftoolとしてKaleidoscopeを選択できる設定がある。 step1で「Install」をクリックしてKaleidoscopeのCL

すでにマージ済みのブランチをまとめて削除するには以下のようにする (master ブランチを checkout していると仮定する) $ git branch --merged | grep -v '*' | xargs -I % git branch -d % Deleted branch foo (was ce1b0d5). Deleted branch bar (was 7623b2b). Deleted branch baz (was d4c396d).

#ファイルの変更を残す場合 $ git reset --soft HEAD^ #ファイルの変更を無かったことにする場合 $ git reset --hard HEAD^

18. git-flow $ git flow init $ git flow feature start branch_name $ git flow feature end branch_name $ git flow hotfix $ git flow release 19. legit - Git Workflow for Humans $ git switch <branch> $ git sync $ git publish $ git unpublish $ git harvest $ git sprout $ git graft $ git branches

参加レポート【GitHub トレーニングチームから学ぶ Git の内部構造＠名古屋】 2013/11/17 | 所要時間 約14分 11月17日に行われたGitHub トレーニングチームから学ぶ Git の内部構造＠名古屋 のレポートです。 メモが追いつかなかったり、聞き取れなかったりしたとこは抜けてます。すんません。 ちょっと長いですがどうぞ。 最初に ハッシュタグは@githubjp 今日の講師はマシュー(@matthewmccull)とジョン(@johndbritton)) マシュー日本語勉強中だって:) 今回の内容はGitの内部構造について。Gitの紹介とは違う。 Gitの定義 the stupid content tracker (man gitしたときに最初に出てくる説明) 2005年 git誕生 githubは自社の製品を自分たちの作業にも使っている。 ここからGitの内部構