背景 Obsidianのコミュニティプラグイン「Git[1]」を利用することで無料でデバイス間データ同期ができる。 しかしPC側は設定できたものの、スマホ側の設定で少し手こずったので記録。 検索すると「Working Copy」を使ってモバイル端末上でリポジトリを管理する方法がいくつか出てきたが、現在(2024年11月)は不要だった。 手順 先に完了させておくこと PC側のObsidianのインストール PC側のObsidianでコミュニティプラグイン「Git」のインストール Obsidian同期用のgitリポジトリの作成 GithubでPersonal access tokenを発行する モバイル端末からリポジトリにアクセスするためのPersonal access tokenを発行する。 githubにログイン 自分のアイコンをクリックし、メニューから「Settings」を選択 下にスク
#Git subtreeとは 外部のリポジトリを現在のリポジトリに取り込むことができる。 Git上のプロジェクトを他のプロジェクトでも使用したいときに利用する。 Git subtreeコマンドは、取り込んだリポジトリを編集することで、取り込み先のリポジトリも編集可能にする。 ###Git subtreeとGit submodule #####Git subtree →外部リポジトリを現在のリポジトリのものとして取り込み、手を加えていくときに使用する。 #####Git submodule →外部リポジトリを現在のリポジトリの外のものとして取り込み、今後編集しない時に使用する。 #Git subtreeの使い方 ##サブディレクトリへの登録方法 ###前提 Gitで新プロジェクトを作成済み。 以下の作業は、新プロジェクト内で行うこと。 ###手順 1.取り込みたいリポジトリを、外部リポジトリ
この記事は 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
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
はじめに 開発を進める中で「既にコミットしたファイルを後からバージョン管理の対象から外したい」という状況に直面することがあります。 たとえば、機密情報を含むファイルを誤ってコミットした場合や、ビルド生成物をリポジトリに含めたくなくなった場合などです。 こうした場合、.gitignoreファイルを使っても、すでに追跡されているファイルはその対象外となりますので、別のアプローチが必要になります。 この記事では、その方法をステップバイステップで説明します。 手順1 .gitignoreにファイルを追加 最初のステップは、バージョン管理から外したいファイルやディレクトリを.gitignoreファイルに追加することです。 これにより、これらのファイルが今後のコミットで無視されるようになります。
こんにちは、CAMPFIREエンジニアのishimizuです。 これまで20年近くエンジニアをしてきて今年大きく開発スタイルを変革した事がありましたので経験談を踏まえてまとめていこうかなと思っています。 突然ですが、皆さんgitのコマンドは何をよく使っていますか？ webエンジニアに限らずエンジニア稼業をしていれば、当然毎日使うgitコマンドですが、git commitやgit pushは欠かせないと思います。 私も毎日git pushやgit commitを打ちまくっています。git mergeやgit cherry-pickも人よりはよく使うかも知れません。 git rebaseとかはよく分からないので使わないようにしています。 ブランチの歴史がおかしくなったら1から作り直して必要なコミットを古いものからcherry-pickして新たに歴史作るほうが絶対に早いし安全です git rev
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
起こったこと gitを使って開発をしている際に、text_HOME.svgというファイル名をtext_home.svgに変更したところnothing to commit, working tree cleanと言われました。 どうやらファイル名の変更がGitに差分として認識されていないよう。 実験 同じような状況を再現してみます。 ディレクトリrename_testに実験用のファイルtext.txtが存在しており、working treeには何もない状態です。 それでは、test.txtをTest.txtにリネームしてみます。 普通にmvコマンドを使ってtext.txtをリネームしてもgitは差分を認識してくれません。 git mvコマンド 次はgit mvを使用してファイルをリネームしてみます。 今度はファイル名の変更が差分として認識されました🙌 参考 ファイルのリネームはgit mv
（commit or stash + checkoutすらめんどいことだって、あるんですよ・・） そもそもリポジトリと作業ディレクトリの違いって？ gitリポジトリには、コミットされている内容やブランチなどの全ての情報がつまっています。一方で作業ディレクトリは、リポジトリ内のあるcommitの内容を、ファイルとして書き出したものになっています。 git-new-workdirコマンド gitリポジトリに紐づく新たな作業ディレクトリを作成します。 ただし、デフォルトでPATHが通っていません。Fedoraあたりなら /usr/share/doc/git-1.7.10.2/contrib/workdir/git-new-workdir に、homebrewなら /usr/local/Cellar/git/1.7.12.4/share/git-core/contrib/workdir/git-n
また例によって他の方の例の通りにやっても自分の希望通りにはできなかったので、自分なりの試行錯誤も込めて。 目的 複数のGitリポジトリを一つにまとめたい。 まとめた後、元のリポジトリは削除し統合したリポジトリで運用したい。 ローカルリポジトリ間で統合させたい（いろいろ試行錯誤したかったため） ディレクトリ構成も綺麗にしておきたい。 参考の方法ではディレクトリ構成が希望通りに行かなかったり、 ディレクトリ構成は上手くいってもリポジトリが希望通りにマージされなかったりしたので その辺りを対処した手法になります。 構成 parent_repo（親リポジトリ、新規に作成） ├child_repo1 ├child_repo2 └child_repo3 Finder上で見るとまとめた後は以下のような構成になります。 作業の前に 元のリポジトリにあるブランチはmasterにマージしておくなど、綺麗な状態
はじめに こんにちは、良い技術ブログが書けるよう日々試行錯誤しているエヌです。 この記事では「bareリポジトリを利用したローカルでgit管理を行う方法」についてを書いています。 GitHubなどをのサービスを使いリモートリポジトリと連携して履歴管理などを行ってますが、個人的な資料もgitで管理したくて、ローカルだけでgit管理できないのかなぁと思ったのがこの記事を書いたきっかけです。 以前に似たような記事を書きましたが、今回はbareリポジトリを利用してgit cloneができるような管理を行っていきたいと思います。この方法だと例えば社内でサーバーを立ててチームでGitを使う、ということもできるようになります 自分に向けた備忘録も目的ではありますが、「サーバーとか要らなくて個人PCだけで履歴の管理が行えるようにしたい」な人の一助になれば嬉しいです。 Note bareリポジトリとは何か、
■はじめに（公開資料の説明） バージョン管理システムのスタンダードである「Git」。 前回、社内研修で使った資料のうち、前半部分である「領域とコマンド」の用語説明と概念図を公開しました。 この記事では、その続きである「ブランチモデルと識別子」の説明で使った用語説明と概念図を公開します。 また、こちらもアトラシアンのBitbucketとSourcetreeを使用する前提での内容となっています。 あくまで研修で使用した資料ですので、説明としては不足していたり、あくまで正確性よりも概念を示すだけの部分があると思いますが、これからGitの社内研修をするにあたって何か資料の参考になるものをお探しの方に役立てていただければと、以下に公開します。 それでは、どうぞ！ ↓ ●ブランチモデルと識別子 ▼ブランチ プロジェクトの変更履歴（コミットの重なり）を分岐させて枝分かれさせたもの。 「main」（旧名「
リポジトリのディスク容量を削減する 開発を何年も継続し続けるとリポジトリもそれなりの規模になる。エンジニアの心理としてはリポジトリを整理したくなるもので、５種類の方法を紹介する。 方法 過去へのアクセス 削減度 作業の手軽さ git-gc ◎ 50%～ ◎ partial-clone ◎ 90%～ ◯ shallow-clone ◯ 90%～ ◯ logic-compress ◯ 90%～ △ reborn ✕ 100% ◯ その１：git gcを用いる これは最も簡単でそれなりの効果が得られる手段だ。通常Gitはfileをsnapshotして全て保存しているが、git gcを発動するとバイナリfileに差分保存することでディスク容量を圧縮する。オプションを付ける事でさらに圧縮率を上げる事が可能。 programmingforever.hatenablog.com その２：クローンサイズを
はじめに gitコマンドの挙動を覚えるためには、ひたすらに実践するのが効果的です。 ただ、githubなどにリモートリポジトリを作成すると、ターミナルだけでgitコマンドの実行をすることが難しく、勉強するのにめんどくささがつきまといます。 そこで、ローカル環境にリモートリポジトリを作成することで、ターミナルだけでgitの練習ができる環境を構築します。 ローカルにリモートリポジトリを作成するとは リモートリポジトリについては、gitのドキュメントに以下の記述があります。 リモートリポジトリとは、インターネット上あるいはその他ネットワーク上のどこかに存在するプロジェクトのこと リモートリポジトリとは、githubやAWSのcodecommitなど、ローカル環境ではないところを指すような印象を持ちますが、ローカル環境というネットワークを使えば、ローカルリポジトリとリモートリポジトリをローカル環境
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く