Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
gitリポジトリのサブディレクトリを別のリポジトリとして抽出する方法 - 拡張現実ライフ
記事内に広告を含む場合があります。記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。 ディレクトリ original_dir に元のリポジトリが入っていて、これから new_dir という新しいリポジトリを作って、そこに一部を抽出する場合、以下のようにします。 % git clone original_dir new_dir % cd new_dir % git filter-branch --subdirectory-filter sub_dir_name HEAD これで、ディレクトリ sub_dir_name だけが、新しいリポジトリとして抽出されます。
Detach (move) subdirectory into separate Git repository
I have a Git repository which contains a number of subdirectories. Now I have found that one of the subdirectories is unrelated to the other and should be detached to a separate repository. How can I do this while keeping the history of the files within the subdirectory? I guess I could make a clone and remove the unwanted parts of each clone, but I suppose this would give me the complete tree whe
.ideaのgit管理について Android Studio - Qiita
Android Studioでプロジェクトを開始するときに.ideaファイル内のgit管理についていつも迷うのメモします。 結論 こちらによると以下3個をgit管理しておけば良いみたいです。 build.gradle .idea/gradle.xml .idea/misc.xml 自分の場合 しかし自分の環境ではmisc.xmlにはユーザー固有のファイルパスが記述されていました。とりあえずユーザー固有のファイルパスの部分を$PROJECT_DIR$に変更しておけば良いと思います。 上記以外も基本的にユーザー固有ファイルパスの部分を適宜$PROJECT_DIR$に直してさえいればgit管理して問題ないかと思います。 .idea内のファイルについて 記事を各過程で各ファイルがどのような役割なのか簡単に分かったことをまとめたいと思います。(適宜更新していくかと思います。) workspace.x
Git でコミット、チェックアウト時に改行コードを自動変換する (core.autocrlf, core.safecrlf)
Git でコミット、チェックアウト時に改行コードを自動変換する (core.autocrlf, core.safecrlf) Git の設定 (git config) で、core.autocrlf や core.safecrlf を設定しておくと、コミットやチェックアウト時に改行コードを自動変換することができます。 変換設定として、下記のような設定を行うことができます。 core.autocrlffalse: コミット時、チェックアウト時に改行コードの変換を行わないtrue: コミット時に CRLF→LF の変換を行い、チェックアウト時に LF→CRLF の返還を行う。input: コミット時に CRLF→LF の変換を行い、チェックアウト時には変換を行わない。core.safecrlftrue: ファイル内に複数の改行コードが混じっている場合に自動変換を行わない。おすすめの設定は以下の
AWS Code シリーズ - Qiita
■AWSのCode シリーズ CodeCommit ソースコードを管理するGitリポジトリサービス CodeBuild ソースコードのビルド/テスティングサービス CodeDeploy ビルドされたモジュールのデプロイサービス CodePipeline 継続的デリバリー/継続的インテグレーションをサポートするサービス 1.CodeCommit 概要 - 簡単にGitリポジトリをホストすることができる。 - サードバーティ製のツールも利用可能。 - プルリクエスト機能も利用可能。 接続方法 - コンソール - https - ssh 基本的な利用の流れ その他参考情報 1-1 CodeCommitのリポジトリを作成する [リポジトリ名]に任意のものを入力 1-2 初期セットアップ、コードのPush IAMユーザの権限を使って、CodeCommitのリポジトリに接続し、Pushします。 git
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
自分の言葉で書かれたコミットメッセージが好き
誰にも質問されていないけど回答すると、ぼく個人としては「レビュー指摘事項を反映」的なコミットメッセージにはやんわり否定派で、どうしてそう変更すべきと思ったのかを自分の言葉で書く方がベターと思っています。 — juné29💩公式アカウント (@june29) January 11, 2017 140文字には納まらないな、と思ったのでちゃんとエッセイを書く人間になろう！ たとえばぼくがレビューを担当させてもらって「ここはAの方がよいと思いました」とコメントしたとして、そのときに「レビューで指摘された箇所を修正」というメッセージ付きのコミットが追加されたとする。そのあとぼくが思い直して「いや、他の箇所も考慮すると、やっぱりBの方がよさそうです」とコメントしたとする。また「レビューで指摘された箇所を修正」というコミットが追加される。 こういうやりとりだと、「レビュー」というプロセスというよりは「
gitでローカルブランチにmasterなんて（普通は）要りません - Qiita
理由 GitHubやGitLabなどのおかげで、リモートで直接masterにマージできるようになった。 どうしても、という時以外ローカルのmasterブランチで作業する必要はないはずです。 間違えてmasterを壊してしまうリスクが更に減る ローカルのmasterブランチをメンテするコストが減る 地味なメリットに聞こえるかもしれませんが個人的にはありがたいので最後のものを詳しく説明します。 Gitの仕様上、ローカルのmasterブランチはリモートのmasterブランチを更新しても自動的には更新されません。 現状、git checkout masterしてからgit pullしないと更新できないはずです（他にも方法はありそうな気がしますが割愛します）。 この方法、一瞬でもmasterにチェックアウトしなければならないため、チェックアウトする前のブランチとローカルのmasterの差が大きい場合
Keep a Changelog
Keep a CHANGELOGDon’t let your friends dump git logs into CHANGELOGs™ Version 0.3.0 What’s a change log? A change log is a file which contains a curated, chronologically ordered list of notable changes for each version of a project. # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and t
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
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
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - filhodanuvem/gitql: 💊 A git query language
横着で神経質な私とあなたに贈るgit add -p - Qiita
