現象 ある日MacのSourceTreeでレポジトリを開こうとしたら急に 'git status' failed with code -1:'launch path not accessible ' 'git log' failed with code -1:'launch path not accessible ' とか表示されて操作できなくなった。 TerminalからはCloneもPull/Push全てgitコマンドが動いたので最悪の事態ではなかったけども焦った。 原因 原因はTerminal用のgitを別途インストールした作業の過程でSourceTreeの設定として利用するgitがアクセス不能になっていたためっぽい。 解決方法 SourceTree->環境設定->Git でGitのバージョンでエラーメッセージが出ていたら同じ症状。 内臓のGitに戻すか、今回はシステムのGitを改め
SourceTreeにGitLabアカウントを登録する際につまづいたポイントの覚え書き。 概要 SourceTreeにGitLabアカウントを登録する際にパスワードの入力が必要となる。GitLabアカウントのパスワードを入力するも認証に失敗するため調べたところ、アクセストークンをパスワードとして入力しなければならないことが判った。 環境 macOS 10.14.2 SourceTree 3.0.1 手順 GitLab - アクセストークンの作成 GitLabにログインして Settings へ進み、Access Tokens タブをクリックする。 リポジトリのread/writeを許可するため、以下の情報を設定して Create personal access token をクリックし、アクセストークンを作成する。 Name: トークン名 Expires at: トークンの有効期限 Sco
表題の通り。GitってSourceTreeとか実際に使いながら理解すれば簡単なんだけど、ネットで検索するだけど全然理解できないんですよね…。 「git rebase -i ブランチ名」は間違ってコミットした時に使いやすい 逆に言うと、複数あるコミットを一気に一つにまとめたい！という要望には適応しにくい。なんかこの辺が混在した情報が多い気がするんですよね。例えばリベースって pick 12ca2a5 トップ直した pick 8nfa9fa 詳細直した pick vdia9ag お問い合わせ直した pick re98a7u プライバシーポリシー直した pick fgyr8ae プライバシーポリシー直した pick 7ghagfa 新着情報直した # Rebase bdd3996..bd66e17 onto bdd3996 # # Commands: # p, pick = use commit
たまに作業しようと思うと、いつもやり方を忘れてるのでしっかりメモ。 1. SourceTreeでブランチを開く 今回は、上から3つのコミットを1つにまとめる。 2. まとめる対象の1つ前のコミットを選択 まとめる対象のコミットの、1つ前のコミットを選択。 1つ前重要。 3. 『子を対話形式でリベース』 右クリックで表示されるメニューから、『〜〜の子を対話形式でリベース』を選択。 4. スカッシュ対象を追加 一番上のコミットを選択した状態で『過去を含めてSquashする』を選択。1回押すたびにコミットが1つ追加になるので、まとめたいコミットが全て追加になるまで繰り返す。 5. メッセージを編集 まとめられたあとのコミットメッセージを修正しておく。 6. 完了 謎のコミットが消えてすっきりに。
GitLabのPull Requestのコツがつかめてきたので、簡単に説明してみます。 とりあえずContributing Guidelinesをよく読みましょう。決まりを守らない人は嫌われて相手にされません。 あとは、Pull request guidelinesに従いましょう。 GitLabプロジェクトをフォーク フィーチャーブランチを作成 テストとコードを書く 複数のコミットが含まれる場合はsquashで一つのコミットにまとめる フォークにコミットをpush Pull requestを投稿 投稿したpull requestに関係するissuesを検索しpull requestのコメント欄に記述する 2.について、後日もう再度pull requestを送る場合は、ブランチを切る前に git remote add upstream https://github.com/gitlabhq/
B! 70 0 0 0 Gitのsubmoduleがいつもイマイチ良くわからなくなるので 自分なりのまとめ。 レポジトリにsubmoduleの追加 submoduleのあるレポジトリをcloneする submoduleの更新 submoduleの削除 ignore = dirty Submoduleのプロトコルの変更 レポジトリにsubmoduleの追加 git submodule addで追加。 $ git submodule add [email protected]:rcmdnk/evernote_mail.git ./submodules/evernote_mail addすると.gitmoduleというファイルがまだ無い場合は作られ、その中に [submodule "submodules/evernote_mail"] path = submodules/evernote_mai
Git を使った開発では、サブモジュールを使うことによって、他のプロジェクトを自分のコードベースに取り込めるようになります。それも、他のプロジェクトの履歴を分離しつつ、あなたのプロジェクトの履歴と同期できるようになるのです。これはベンダーライブラリ問題や依存関係問題を解決する便利な方法です。git に関してはいつもそうですが、このアプローチもかなり自己流なのでうまく出来るようになるまで少しばかり研究することをお勧めします。submodules に関する好例や詳しい説明はすでに公開されているので、ここでまた繰り返すのはやめることにします。この記事では submodule という機能を最大限に活用するのに役立つであろういくつかの面白い情報を共有したいと思います。 目次 コアコンセプト 考えられるワークフロー 初めての人向けの役に立つコツ サブモジュールを自分のフォークしたリポジトリで置き換える
こんにちは、okutani(@okutani_t)です。Gitのサブモジュール（submodule）についてイマイチよく分かっていなかったので、備忘録も兼ねて記事にしてみました。 Gitのサブモジュール機能を使うと、プロジェクトで管理しているGitリポジトリとは別に、独立したリポジトリをプロジェクトに含ませることができます。 サブモジュールを含んだプロジェクトでは、プッシュ・プルをおこなってもサブモジュール側のリポジトリには影響がない、といった特徴があります。 他の特徴としては、サブモジュールはあくまで特定コミットを示すポイントを追加したディレクトリに埋め込むものです。 本記事ではGitのバージョンは1.8.5以上を対象としています。それ以下のバージョンでは使えないコマンドなどあるので注意してください。 では、さっそくGitのサブモジュールの使い方を見ていきましょう。 参考Git のサブモ
はじめに プロジェクトを進めていくと、「あっ！ この機能、別のプロジェクトに流用できる！」と気づく瞬間ってありますよね。でも、不用意に特定のファイルだけをコピペしちゃうと、片方でその機能を更新してももう片方に反映されません。同じ機能を使っているので、ここはgitで一元管理したいところですよね。 それを可能にしてくれるのがサブモジュールです。この記事では、既存のリポジトリからサブモジュールを切り出して、複数のプロジェクトで共有する方法を紹介します。 具体的には、以下のような状態から 以下のような状態にするということです。 ここでは GitHub との連携を念頭に置いて説明していきますが、 GitLab でも同じようにできます。 ステップ0：前提 例として、以下のような状況を考えます。 $ tree . ├── project_a │ ├── main_a.py │ ├── submo
サブモジュールのディレクトリを変更するのにハマったのでメモ。 EX 環境: git version 2.12.2 サブモジュールの追加 $ git submodule add git@my_module.git 追加した my_module を vendor/my_module に移動させたい。 1. ディレクトリを変更する方法 .gitmodules を開いて[submodule] と path= の2箇所のパスを変更 [submodule “vendor/my_module”] path = vendor/my_module url = git@module.git $ git add .gitmodules サブモジュールを移動させる $ mk dir vendor $ mv -vi my_module vendor/my_module 旧サブモジュールのGit管理対象から除外する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
