私が Git リリース ノートをレビューしてからしばらく経ちましたが 、だからといって私が最新のノートを熱心に読んでおらず、毎日の作業に新たな優れモノを取り入れていなかった訳ではありません。自分の誕生日 (拍手!) と、先日の Bitbucket Server のリリースを祝うため、本日は私が Git 2.x シリーズ (2.6 まで) で気に入っているフィーチャーを全てご紹介します。どれか役に立つようなことがあれば、是非ご一報ください。 リベース前に変更内容をスタッシュ Git 2.6 では、rebase コマンドが皆さんから良い意味での注目を浴びました。以下にご紹介するのは、より興味深い新しいフラグの1つです : git rebase --autostash これからは、rebase 操作の開始時に未コミットの変更内容を一時的にスタッシュするか、操作を失敗させるかを指定できます。この行
vim-gitgutter https://github.com/airblade/vim-gitgutter 良い感じです。 電気グルーヴの新譜「人間と動物」並みに良いです。本記事とは全く関係無いですけど、聴くと良いと思います。 vim-gitgutter? git のHEAD からの差分をvim 上に表示してくれるvim plug-in です。 こんな感じ↓ git で管理しているこのファイルに変更を加えると…… こんな風に左端にdiff のステータスを表示してくれるのです。便利!! インストールの仕方 いつものようにNeoBundle 'airblade/vim-gitgutter' とかやれば良いのではないでしょうか。(適当) 詳しい使い方 まだそこまで触ってないので、オフィシャルのドキュメントを読んだ方が良いと思います。(超適当) "This is a port of the G
4月から都会でOLとして働き始めたので, OL的windowsの事務処理環境を手探りで作ってみました. OLとWindows 事務処理といえばOffice, 当然Windowsで行うことになります. 今時のOLは家ではLinuxを使っているはずなので, 自然とシェル環境で困ることになります. Windowsが本当にわからない linuxコマンド使いたい(DOS音痴) Cygwinは嫌い MinGW+MSYS にしてみたい(けど未だによくわかってない) 事務PCなので, 大掛かりな環境は入れたくない(入れられない) WSL ? そもそも Windows7 なので(ry) などのモチベーションから 色々見ていてcmderが良さそうだなと思ったのですが cmder.net 所属機関でフィルタされて落とせなかった(つらい)ので, ConEmu + msys bash の組み合わせで端末環境を整える
会社で受託開発していて、gitを使った開発フローを考えることになった。 ニアショアに開発をお願いしていて、ニアショアからの受け入れタイミングが何回かあるから、それにあわせてブランチをわけている。 どういうフローで進めているかと、一番最後にやってみて思ったことを書いた。 どういうフローでやっているか リポジトリの構成 下記モジュールを用意した。 parent core entity common web batch tools ニアショアにて開発するモジュールは『common』、『web』、『batch』で、 アーキにて開発するモジュールは『parent』、『core』、『entity』。 ブランチ ブランチはこんな感じで分けている。 ちなみに、ソース管理はgitBucketを使った。 masterブランチ … リリース可能な状態の資源のみを管理する。結合テスト実施時は、本ブランチから資源を
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(!) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか?」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか?これつけると何が変わるんですか?」と質問がきたのです。 作業ブランチで git pull --rebase origin master
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
index.html などの HTMLファイルにビルド時の Git のコミットハッシュ情報があれば、ブラウザJSアプリでのリリース後のトラブル対応時に便利かと思い、入れる方法を考えました。Window.app.gitCommitHash などでも同等かと思います。 git rev-parse HEAD でコミットハッシュが得られます。これを package.json の scripts 欄から環境変数 GIT_COMMIT_HASH に格納して、gulp タスクを実行して、gulp-replace で HTML ファイルの適当なところを置き換えました。 ▼ package.json "scripts": { "build": "GIT_COMMIT_HASH=$(git rev-parse HEAD) gulp hoge" }, var replace = require('gulp-re
何か? git commitのオプション--allow-emptyご存知でしょうか? これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
Windows で作成したファイルを git push し、Linux や FreeBSD で git pull したファイルの属性は、0644 で記録されている。 これらのファイルに実行権限 (ファイル属性の変更) を付与して、git commit して git push した後に、Windows で git pull すると、付与した実行権限が反映されていない。 その場合は、Windows 上ならば、Git Bash で、Linux や FreeBSD などではコマンドライン上で下記の作業を実施する。 % ls -l -rw-r--r-- 1 littlebuddha wheel 329 Jul 30 17:49 sample.pl % git ls-tree HEAD sample.pl 100644 blob e269d073bc1b03ad0a1281a7f005010d4166
本サイトはいわゆる帰国子女で30年弱英語を使っているエンジニアである筆者が英語関連の気になった項目や、質問された項目について解説を試みるサイトです。一応TOEIC 950点ですが、普段から使っているという以外に特に英語の専門的な知識はありませんので、鵜呑みにせず参考としてご使用ください。質問の仕方→ http://www.englishforengineers.jp/post/122219356460 コミット説明文は短めの物なら動詞で始めるのがわかりやすい: Fixed a bug where… Removed duplicate code for… Redo the logic around … ある程度長くなる場合はちゃんとした文章のほうがよいかもしれない。時と場合による。 追記 「コミットメッセージの最初の動詞は現在形で」というのをどっかで見て以来、そうしてるんですが、両者にどうい
Gitでの開発で、こんな体験はありませんか? 3つ前のコミットのメッセージにミスがあった。修正したい・・・ このコミットの順番入れ替えたいなぁ このコミット、ホントは要らなかったから削除したいなぁ …… 実はそれGitでできるんです!今回はGitクライアントソフトのSource Treeソース・ツリーでコミットログを修正する便利な機能「rebase interactiveリベース・インタラクティブ」を解説します。 コミットの再編集ができる機能とは? Gitではコミットを再編集する機能を「git rebase interactive」といいます。たとえば、コミットの入れ替えや編集、統合、削除ができます。正確に説明すると、コミットそのものを編集するのではなく、新しくコミットのコピーを作成して1つずつコミットを組み立てる機能になります。 Source Treeでコミットログを編集しよう Sour
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに こんにちは!nanapiデザイナーのyunicoです!「Git Advent Calendar 2014」の15日目を担当します(^o^) 今年はなんか色々GitGit言っていた年だったので、最後にアドベントカレンダーに参加しちゃいます!わいわい!去年からすると、まさか一年後にGitのアドベントカレンダーに参加しているとは思いもよりませんでした〜。感慨深いものです!よろしくお願いします<(_ _)> #前置きと今年やったことまとめ TechBlogでGitについて書いた nanapi勉強会でTL GithubKaigiでTL
An open source Git extension for versioning large files Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise. Getting Started Download and install the Git command line extension. Once downloaded and installed, set up Git LFS for y
gitを改めてちゃんと使おうという人がまわりで増えてきたのでメモとして貼っておく。 現状の設定はこんな感じ。1年くらい変わってなかった。 https://github.com/suzuken/dotfiles/blob/cbf8e7168c96029d535d69f981337d23aacfa51c/gitconfig 特にaliasまわりは普段つかっているのであげておく。 [alias] # http://oli.jp/2012/git-powerup/ # http://blog.blindgaenger.net/advanced_git_aliases.html alias = !git config --list | grep 'alias\\.' | sed 's/alias\\.\\([^=]*\\)=\\(.*\\)/\\1\\\t => \\2/' | sort b = b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く