Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
あなたのプロジェクトに秩序をもたらす！git commit 支援ツールを作りました。 - Qiita
前置き 【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 Gitのコミットに絵文字を使おう！ 上記のような記事でコミットメッセージにprefixを使うことのメリットが語られています。 実際、自分も今やっている仕事ではコミットにprefixをつけています。 が、これが結構面倒くさい。 「どんなprefixがあったっけ?」「docだっけ、docsだっけ?」 みたいな。 prefixを楽にするツールにcommitizenというのがあるけど、これが結構使いにくい。 なぜならprefixの種類が強制されていて自由に変更できないから。 ということで自分好みのツールを作りました。 それがgit-consistentです。 ↑ こんなやつです。 インストール npmかyarnでインストールするだけです。 $ cd my-project/ $ git cons
Go製のCHANGELOGジェネレータを作った - wadackel.me
はじめに タイトルにある通り、git-chglog という Go 製の CHANGELOG ジェネレータを作りました。 git-chglog/git-chglog https://github.com/git-chglog/git-chglog Git を使用したコミットとタグからなる情報を元に CHANGELOG を作成するためのツールです。 まだまともなサンプルが用意出来ていないのですが、以下は Angular のリポジトリで試しに作ってみたイメージです。 2018/02/20 時点の Angular のコミット数がおよそ 9600 程度で、生成までの時間が 2.5〜3.5s なので、まぁストレスなく使えるレベルの速度かなと思います。 僕が普段仕事としている Web Front-End 界隈では、conventional-changelog というツールが存在し、恐らく最も使われていま
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
Git - 変更内容のリポジトリへの記録
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ：git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
MacのGitで補完を効かせたりブランチ名を表示する設定(Homebrewでgitをインストールした場合) - Qiita
目的 Macのターミナルでgitコマンドの補完を有効にする。 Homebrewでgitをインストールした場合は、git-completion.bashが既にダウンロードされている。特に新しいファイルを用意せずとも.bashrcの設定のみで利用可能。 設定方法 git-completion.bashの存在を確認 補完を有効にするためにはgit-prompt.shとgit-completion.bashを有効にする必要がある。 Homebrewでgitをインストールした場合は/usr/local/etc/bash_completion.d/の中にシンボリックリンクがおかれているようなので、存在を確認する。
gitのブランチ名補完を試した際の備忘録 - Qiita
環境 git version 2.4.0 はじめに gitのブランチ名補完を試してみて詰まったところの備忘録です。 「git chechkout ~~」や「git log ~~」など様々な場面でブランチ名を指定する際に、いちいち「git branch」を行ってからコピペという流れが無くなるので作業が早くなるはず？（まだ検証中） 先にまとめ 導入方法 http://qiita.com/snaka/items/4b0437a32da832d2e0db すごく簡単！のはずなのですが... 解説 「FETCH_HEAD」「HEAD」「ORIG_HEAD」しか表示されない問題 参考URLに沿って作業を行ったのですが補完時に上記3つしか表示されませんでした。 ▽Qiita - GitのHEAD, ORIG_HEAD, FETCH_HEAD, MERGE_HEADとは？ http://qiita.com
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
「Git補完をしらない」「git statusを1日100回は使う」そんなあなたに朗報【git-completionとgit-prompt】 - Qiita
はじめに 「Git補完をしらない」「commitブランチを間違える」「git statusを1日100回は使う」そんなあなたに朗報です。 bashの説明だけに絞っています。zsh？ tcsh？ 知らない子ですね。 いきなり完成形 # スクリプト読み込み source $HOME/.git-completion.bash source $HOME/.git-prompt.sh # プロンプトに各種情報を表示 GIT_PS1_SHOWDIRTYSTATE=1 GIT_PS1_SHOWUPSTREAM=1 GIT_PS1_SHOWUNTRACKEDFILES= GIT_PS1_SHOWSTASHSTATE=1 ############### ターミナルのコマンド受付状態の表示変更 # \u ユーザ名 # \h ホスト名 # \W カレントディレクトリ # \w カレントディレクトリのパス # \
Code snippet organizer for pros | Cacher
Snippets: The pro's way of remembering Code snippets help you retrieve and share the technical details behind any implementation. Use snippets to: Recall machine setup instructions open_in_browser Teach coding techniques open_in_browser Write great documentation open_in_browser Labels for every occasion Use Cacher’s flexible color-coded labeling system to organize your code any way you like. Label
Linuxメモ : icdiffコマンドで横並び、文字単位で差分を表示 - もた日記
icdiff インストール 使い方 git diffで使う icdiff icdiff: side-by-side highlighted command line diffs github.com 2つのファイルを横並び（サイドバイサイド）で比較する場合、diff -yを使う、vimdiffを使う、WindowsならWinMergeなどのソフトを使う方法があるが、今回はicdiffコマンドを試してみる。 icdiffを使うとコマンドラインで図のように横並び、文字単位で差分を表示することができる。icdiffはImproved Colored Diffの略だと思われる。 インストール pipでインストールできるので下記コマンドを実行。 $ pip install icdiffまたはここからバイナリをダウンロードしてパスが通っているディレクトリに置く。 ヘルプメッセージは以下の通り。 $ i
GitHub - elsewhencode/project-guidelines: A set of best practices for JavaScript projects
There are a set of rules to keep in mind: Perform work in a feature branch. Why: Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. read more... Branch out from develop Why: This way, you can
GitHubだけで超高機能なスライド資料が作れる「GitPitch」の使い方を徹底解説！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、ブラウザ上のGitHubでMarkdown（マークダウン）ファイルを作成し、そのまま超高機能なスライド資料に変換してくれるサービスのご紹介です！ もちろん、自分でMarkdownファイルを用意してpushするだけでもOKなのですが、今回はコンソール画面などは使わずにすべてブラウザだけで完結できる方法をご紹介致します。 【 GitPitch 】 ■「GitPitch」の基本的な使い方！ それでは、実際に簡単なスライド資料を作ってみましょう！ まず最初に、自分のGitHubアカウントでログインし、新規のリポジトリを作成しましょう！ 「① リポジトリ名」は好きな名前を付けてください。 画面下にある「② チェックボックス」をONにしてから「③ Create repository」ボタンをクリックしましょう。 すると、自動的に「README.md
よりよいGitの設定 | Yakst
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
gitでローカルブランチをリモートブランチの内容で上書きする
gitでサブモジュールを使っていて、そのサブモジュールはリモートリポジトリからコードを引っ張ってくるためだけの目的で使っている場合、そのサブモジュールの内容は自分ではいじることはなくて、単にリモートリポジトリのコピーであればいい。 で、サブモジュールの内容を最新に更新しなきゃな―、って思って pullしたときに、衝突がワンサカ出た。リモートリポジトリ側でブランチがきちんと管理されていればこういう衝突は起こらないはずだが、まあそこは何か事情もあるのだろうし、完璧を求めても仕方ない。 ってことで、今回はmasterブランチを使っているので、ローカルのmasterブランチをリモートのmasterブランチの内容で強制的に上書きしてやることにする。masterブランチをチェックアウトした状態で、 git fetch origin git reset --hard origin/master でOK。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでファイル名の大文字・小文字の変更を検知するようにする - Qiita
GitHub - GitbookIO/theme-api: Theme for publishing a beautiful API documentation with GitBook