ほぼろ on Twitter: "これは本当にとても便利なgitのログ機能なんですが、 `git log -L :関数名:ファイル名` でその関数の履歴が見れます https://t.co/wcul1OYr0W"これは本当にとても便利なgitのログ機能なんですが、 `git log -L :関数名:ファイル名` でその関数の履歴が見れます https://t.co/wcul1OYr0W
【git】リモートのブランチそのものや1ファイルのみをローカルにチェックアウトするメモ - tweeeetyのぶろぐ的めも
はじめに タイトルまんまですが、既にあるブランチを手元で動かしたいときはよくやる操作です。 特にファイルだけのほうが忘れてしまうことが多いのでメモ。 アジェンダ チェックアウトする前に必要な操作（後述の2,3共用） リモートのブランチを確認したり リモートのブランチをチェックアウトする リモートのブランチからファイルのみチェックアウトする 1. チェックアウトする前に必要な操作（後述の2,3共用） リモートのブランチを持ってくるにせよ、ファイルをもってくるにせよブランチ名を確認したいですよね。 リモートのブランチを確認したり # ローカルのリポジトリ情報を更新 $ git fetch # ブランチが多過ぎて遅い場合は特定のブランチだけfetch $ git fetch origin [取得したいブランチ名] # 目的のブランチが含まれてるか確認 git branch -r | grep [
Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
GitHub おじさん スターターキット - Qiita
この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する機会が多いので、その経験から、どんなことに注意しながら進めていけばいいか書いてみます。 記事は 「紹介編」,「導入後編」,「おじさん編」の３つの編から構成されています。 紹介編 Git はバージョン管理ツール、 GitHub は Git のホスティングサービ
「commit-m: GitHubコミットメッセージの文例が検索できるサービス」がとても便利だったのでcliから使えるコマンド書いた - ( ꒪⌓꒪) ゆるよろ日記
http://commit-m.minamijoyo.com/:titele という有名OSSのコミットメッセージを検索できるサービスがあって、英語のコミットメッセージを書くときに「あれ? これどういう風に書けばいいんﾀﾞｰ」ってときに例文を検索できて捗る。 commit-m.minamijoyo.com が、自分の場合はコミットメッセージ書くときはvim とか git commit -m とかからなのでCLIで検索できたらより捗るかと思ってGolangで書いた。 APIとかは無いようなのでクロールしてる。 GoQuery 使えばこの手のクローラーが一瞬でかけるのでよさがある。 github.com go get github.com/yuroyoro/gommit-m で入れた後に gommit-m keyword [page] で検索できる。
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
Git のマージについて、自分的まとめ - Make You Feel Better
チーム開発で Git を使ってから半年ちょい位経ちました。 Git 玄人な人たちに囲まれて開発していたおかげで、そこそこ Git 力がついてきました。 そんな中で、ブランチの統合（マージ）についての考え方が大分固まって来たのでまとめます。 まずは結論から。 統合するブランチ → 統合されるブランチ : 統合の為に使うコマンド ローカル(自分用) → ローカル(自分用) : 適当に ローカル(自分用) → ローカル(リモート用) : merge --squash リモート → ローカル(リモート用) : pull --rebase ローカル(リモート用) → ローカル(自分用) : rebase ローカル(リモート用) → ローカル(リモート用) : merge --no-ff ローカル(リモート用)は、リモートドラッキングブランチからチェックアウトしたブランチを指してます。 要は、git
図で分かるgit-mergeの--ff, --no-ff, --squashの違い - アジャイルSEを目指すブログ
git-merge の--ff, --no-ff, --squashの違いをまとめてみた。 git helpから引用 まずは、git helpを読みましょう git merge --helpから引用（抜粋） NAME git-merge - Join two or more development histories together SYNOPSIS git merge [-n] [--stat] [--no-commit] [--squash] [-s <strategy>] [-X <strategy-option>] [--[no-]rerere-autoupdate] [-m <msg>] <commit>... git merge <msg> HEAD <commit>... git merge --abort OPTIONS --ff, --no-ff Do not gene
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ - Qiita
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸGitGitHub Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジト
受託開発でGitとmavenを使って開発をしている - そこに仁義はあるのか(仮)
会社で受託開発していて、gitを使った開発フローを考えることになった。 ニアショアに開発をお願いしていて、ニアショアからの受け入れタイミングが何回かあるから、それにあわせてブランチをわけている。 どういうフローで進めているかと、一番最後にやってみて思ったことを書いた。 どういうフローでやっているか リポジトリの構成 下記モジュールを用意した。 parent core entity common web batch tools ニアショアにて開発するモジュールは『common』、『web』、『batch』で、 アーキにて開発するモジュールは『parent』、『core』、『entity』。 ブランチ ブランチはこんな感じで分けている。 ちなみに、ソース管理はgitBucketを使った。 masterブランチ … リリース可能な状態の資源のみを管理する。結合テスト実施時は、本ブランチから資源を
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
Git中級者に送る便利なコマンド群 - カイワレの大冒険 Second
Gitを使っていて、ちょくちょく便利だなと思うコマンドに出会うので、メモ残しておきます。実際中級者の方には物足りないかもしれませんが、とりあえず。目次は以下。 自分がいじったファイルを一旦退避させたい ツリーが今どういう状態になっているか確認したい 今まで作業をやったことを振り返って、特定の過去に戻りたい リモートブランチをチェックアウトしたい コンフリクトがあったファイル一覧を表示したい 間違ってremote masterブランチにpushしてしまったので、取り消したい マージコミットを消したい 過去のまとまったコミットをまとめたい ここから載せるサンプルは、以下のフローが既に処理された前提で話します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 適当にファイル作成、push $ touch sample.txt
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
Gitのベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitignore.io - Create useful .gitignore files for your project
layer8.sh