はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装

前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset

はじめに コミットログの整理のため、git rebase -i でいくつかのコミットを整理することを考える。しかし、rebaseの途中にできたパッチが空になると、rebaseが失敗する。その時のエラーメッセージや対処法が分かりづらかったのでメモ。 現象 こんな感じの作業をする。 「Hello」という内容のテキストファイルtest.txtを作る test.txtに「foo」を追加する。 test.txtに「bar」を追加する。 やっぱり気が変わって「foo」「bar」を削除する test.txtに「baz」を追加する 実際の作業はこんな感じ。最初のコミットにstartというタグをつけてある。 rm -rf rebasetest mkdir rebasetest cd rebasetest git init . echo "Hello" > test.txt git add test.txt

を叩けばOK。 --softオプション：ワークディレクトリの内容はそのままでコミットだけを取り消したい場合に使用。 --hardオプション：コミット取り消した上でワークディレクトリの内容も書き換えたい場合に使用。 HEAD^：直前のコミットを意味する。 HEAD~{n} ：n個前のコミットを意味する。 HEAD^やHEAD~{n}の代わりにコミットのハッシュ値を書いても良い。 gitのv1.8.5からは、「HEAD」のエイリアスとして「＠」が用意されている。 HEAD~とHEAD^と@^は同じ意味。 HEAD^^^とHEAD~3とHEAD~~~とHEAD~{3}と@^^^は同じ意味。 ただしWindowsの場合はgit reset --soft "HEAD^"と、HEAD^を"で囲んでください。 git resetの詳細は、下記記事に詳しく書いているので、ぜひ参考にされてください。 ▼[g

こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる？ コミットが綺麗になる！　以上です！　この一言に尽きる！ 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか？　整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います！ マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、

Dockerでbuildしたときにプライベートレポジトリからgo getしたい。 やらなければならないことは3つあります。 .gitconfigの変更 秘密鍵の配置 .ssh/configの変更 これだけです。 .gitconfigの変更 GithubのプライベートレポジトリやGithubEnterprise等との通信でhttpを使っているとgo getした時に毎回パスワードを聞かれてしまい、Docker内では失敗してしまいます。 そこでsslの通信に変更します。 変更は.gitconfigで指定します。下記が例です。

※この記事は、2014年06月06日に書きました。 ■まえがき 以前の状態に戻そうとした時に、 新規に追加したファイルがgit Untracked filesってずらーっと並んだりする事があるかもしれない。 stash、reset時に、前回のコミット時には無かったファイルがあると、未追跡ファイルとしてこのような表示になる。 もし、それらのファイルが余りにも多く、 もしも消し去ってもいいのなら、次のコマンドで吹き飛ばすのも手かと思います。 備考 もし、今の状態を一時保存して、また戻ってくるのであれば一旦コミットを行い、 戻ってきた時には、git reset --soft HEAD^して続きをするのもありだと思います。 細かい事を気にしないならgit add .、git commit --amendで追加をコミットに足していくとかでもいいかもしれません。 ■メモ git clean git c

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

とかって感じでリモートのリポジトリをcloneしてきたとする。 で、git branchすればわかるんだけど、このままだとmasterブランチしかローカルにcloneできてない。別のブランチ(developmentとする)もローカルにcloneしたい。 という時はまず でリモートのブランチ名を調べる。 そうすると以下のような感じで表示される。 $ git branch -r origin/HEAD -> origin/master origin/development origin/master で、この中からお目当てのブランチ名を探し（この場合は「origin/development」）、こいつを以下のようにしてcloneすればOK。