GitのWorking TreeとIndexが分かる記事 - Qiita
こんにちは。 この記事は、GitのWorking TreeやIndexについて分かるようになる記事です。 なぜコミットの前にgit addするのか分からない git restoreで何が復元されるのかが分からない git reset で何がリセットされるのか分からない このような疑問を持つ人向けに、Working Tree (Working Directory)とIndex (Staging Area)について解説していきたいと思います。またよく使うGitコマンドがこれらにどう作用するかについても見ていきたいと思います。 用語の定義はこちらのGit公式リファレンスから引用しています。 今回使うリポジトリの準備 あまりGitリポジトリを初期化したことのない方が読む可能性を考え、このセクションに今回使うリポジトリの準備方法を書いておきます。折りたたんでおきますので、見たい方のみご覧ください。
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
僕が使ってる git コマンドのエイリアスを紹介 - Qiita
はじめに @ohakutsu が alias の記事を書いていたので私も利用している alias を書いてみました 設定してる Git aliase .gitconfig や .zshrc は dotfiles レポジトリに保存しています その中で Git に関連するもの ( かつ よく使うもの ) だけ記載します Zsh [alias] ad = add ci = commit co = checkout cop = !"git branch --all | tr -d '* ' | grep -v -e '->' | peco | sed -e 's+remotes/[^/]*/++g' | xargs git checkout" d1 = diff HEAD~ d2 = diff HEAD~~ d3 = diff HEAD~~~ d4 = diff HEAD~~~~ d5 = dif
.gitignoreでフォルダの構造のみを保持したい場合のより良い書き方 - Qiita
例えばWebサイトのバックエンドでアップロードされたファイルを/storage/フォルダ内に入れているとする。その場合、Gitではアップロードされた/storage/内の各ファイルは無視したいが、/storage/フォルダ自体は残しておきたいということがよくある。しかしGitで管理できるのはファイルだけなので、ファイルが一つも入っていないフォルダをGitで表現することはできない。そのために.gitkeepというダミーの空ファイルを作成してGitで管理することでフォルダを保持するということが頻繁に行われている。 ここではそのような場面でこれまでよく解説されている.gitignoreの書き方とは異なる、より柔軟で単純な書き方を発見したので解説する。 結論 保持したいフォルダ構造を作成。ここでは/storage/フォルダ以下のフォルダ構造をgitで保持したいとする。 各末端のフォルダに空のファイ
cherry-pick 運用の地獄から這い上がった話をしよう - Qiita
はじめに はじめに断っておくが、こんな生易しいものじゃない。本当に地獄の沙汰である。 状況と問題点 筆者が参加しているプロジェクトでは、ブランチの運用が cherry-pick で行われていた。Git Flow でも GitHub Flow でもない。言うなれば、Cherry-pick Flow である。 Git Flow について Git Flow なら、本番リリースする際にまず develop ブランチからリリースブランチを切る。 それを master にマージする。 そして、master へのマージ後のマージコミット (M1) を develop に逆輸入すれば、基本的に develop ブランチが Fast-forward な状態となる。 ホットフィックスの場合も同様である。 コミットの取りこぼしなど起きるわけがないし、リリース作業自体もやることが明確でわかりやすい。 Cherry
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Homebrewは定期的にupdateしないとupdateできなくなるんじゃないか説 - Qiita
【git】特定のブランチを除外して、ローカルブランチを一括で削除するコマンドの解説 - Qiita