要約 この記事では、GitHubへSSH接続する方法をまとめました。 大まかな手順としては、ローカルPCで秘密鍵 / 公開鍵を作成し、公開鍵をGitHubへ保管すれば完了です。 ただ、そもそも「SSHって？」といった基本的な内容も案外忘れてしまうと思います。 そこで、記事の前半ではSSH接続の概観を、後半ではSSH接続を実現する手順をまとめました。 GitHubへのSSH接続の概観 SSHの概観 SSH(Secure Shell)とは、リモートでコンピューターにアクセスするためのプロトコルです。 コンピューターの認証を行うために、公開鍵暗号を利用しています。 公開鍵暗号の方式には、「RSA」「DSA」「ECDSA」「EdDSA」があります。 ※こちらの記事によると、パフォーマンスやセキュリティを重視する場合は「EdDSA」が推奨されています。 なので、今回は現在一般的な「RSA」ではなく「EdDSA」を使用してSSH接続を行ってみようと思います。 GitHubへのSSH接続の概観 ローカルPCからGitHubへのSSH接続の概観を、以下の図にまとめてみました。 上図において、GitHubへSSH接続するには ①秘密鍵と公開鍵を作成（Git Bash を使用して行います） ②公開鍵をサーバー側へ保管（GitHubのwebサイト上で行います） ③接続要求（Git Bash を使用して行います） の3つの手順が必要です。 以下の章では、これら3つの手順についてまとめていきます。 手順①：秘密鍵と公開鍵を作成 (1) Git Bashを開く ※インストールしていない場合は「Git for Windows」からインストールします。 (2) SSHキーを作成する 以下のテキストを張り付けて、Enterキーをクリックします。 $ ssh-keygen -t ed25519 -C "your_email@example.com" ※メールアドレスは自分のGitHubメールアドレスに置き換えてください。 ※GitHubアカウントを作成していない場合は「GitHub」にサインアップします。 ※ed25519 は、「EdDSA」の実装のひとつです。 Enterキーをクリックして実行すると、以下のようなテキストが表示されます。 入力したメールアドレスを使用して公開鍵 / 秘密鍵を作成していることを示します。 > Generating public/private ed25519 key pair. (3) 作成したSSHキーを保存する 以下のメッセージが表示されたら、Enterキーをクリックします。 Enter a file in which to save the key (/c/Users/you/.ssh/id_ed25519):[Press enter] (/c/Users/you/.ssh/id_ed25519)の部分は、SSHキーを保存するデフォルトのファイル場所です。 特にファイル場所を変更する必要なないので、このままEnterキーをクリックします。 (4) パスフレーズの設定 以下のメッセージが表示されたら、パスフレーズを入力します Enter passphrase (empty for no passphrase): // 1回目 Enter same passphrase again:　// 2回目(確認用) GitHubへ接続する際に使用するので、必ず保管しておいてください。 以上で、＜手順①：秘密鍵と公開鍵を作成＞は完了です！ 手順②：公開鍵をサーバー側へ保管 (1) 公開鍵をクリップボードにコピーする Git Bash で以下のテキストを張り付けて、Enterキーをクリックします。 $ clip < ~/.ssh/id_ed25519.pub 作成した公開鍵 id_ed25519.pub をクリップボードにコピーしています。 (2) 公開鍵をGitHubへ保管する GitHubの「SSH and GPG keys」を開きます。 New SSH Keyをクリックします。 以下の画像のような画面に切り替わります。 ・Title：お好きな名称を入力します。 ・Key：(1)でクリップボードにコピーした内容を張り付けます。 入力が完了したら、Add SSH Keyをクリックします。 以上で、＜手順②：公開鍵をサーバー側へ保管＞ は完了です！ 手順③：GitHubへ接続確認（接続要求） (1) GitHubへSSH接続 Git Bash で以下のテキストを張り付けて、Enterキーをクリックします。 $ ssh -T git@github.com Enterキーをクリックして実行すると、以下のようなテキストが表示されます。 ここで、手順①の(4)で設定したパスフレーズを入力します。 Enter passphrase for key '/c/Users/you/.ssh/id_ed25519': 接続に成功すると、以下のようなテキストが表示されます。 Hi You! You've successfully authenticated, but GitHub does not provide shell access. 以上で、＜手順③：GitHubへ接続確認（接続要求）＞は完了です！ 参考リンク EdDSAについて SSHの公開鍵暗号には「RSA」「DSA」「ECDSA」「EdDSA」のどれを使えばよいのか？ エドワーズ曲線デジタル署名アルゴリズム_wikipedia GitHubへのSSH接続について GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ 新しい SSH キーを生成して ssh-agent に追加する SSH認証に最強の「Ed25519鍵」を使おう

追記と補足 Twitterにて諸先輩方からご指摘を頂いたのでそのやりとりを載せます。（許可もいただいてます） 僕はGitのpre-commitでPHPの静的解析するみたいなのは、あまりおすすめしないです。強く反対もしないですけど。— tadsan (@tadsan) April 26, 2021 コード整形や一定レベルのエラー検出 はIDEの解析で可能なのでその時点で直すのが一番いいと思うんですが、PHPStanなどのツールによる解析はどのタイミングで行うのが一番いいと思いますか？むしろIDEの解析が優秀ならPHPStanいらないんじゃ？という気もしてます— にしやま (@nsym__m) April 27, 2021 解析はコーディング中常時とPRに対するCIで行います。IDEも静的解析をしているので「IDEが優秀なら」と区切ることは無意味ですが、少なくとも現在のPhpStormはPsalmやPHPStanなどの検査能力と比べると検出される内容はやや貧弱です。 https://t.co/yIaFwmu7TA— tadsan (@tadsan) April 27, 2021 なるほど。「静的解析上問題のあるコードはプッシュすべきではない」という思想から今回のものを書いたのですが前提の思想が間違ってたのですね。リモートに上げること自体はOKで、その後PRで人の目が入る前提でその前処理としてCIで静的解析を行っておくべき、という理解であってますか？— にしやま (@nsym__m) April 27, 2021 はい。コミット単位やマージ前のコミットは不完全でもpushして構わないという立場です。もちろんこれは議論があるところですが、すべてのコミットの完全性を保ちながら作業するのはたいへんなので、僕はこまめにコミットしつつガンガンrebaseとforce pushします。— tadsan (@tadsan) April 27, 2021 あとこの辺も コミットが億劫になり、「まあいっか」で複数の変更を1コミットでまとめて行うようになり、クソコミットグラフになりがち— D.Horiyama (web技術) (@d_horiyama_web) April 26, 2021 Git の pre-commit でのPHPの静的解析に賛成しないというのは言っちゃえば音楽性の違いというだけなんだけど、とはいえ新卒の立場に立ってみるとローカルでコミットすらできないのとpushしたあとCIに怒られるのだと、おそらくPRの差分をメンバーと共有しながら確認できる後者の方がいい。— tadsan (@tadsan) April 27, 2021 PHPStanの検査が通ることよりも書いたプログラムが通る事実の方が大切。静的解析ツールには擬陽性があるので検査を通らなければコードが間違ってるとまで言うことはできない。— tadsan (@tadsan) April 26, 2021 上記の通りで、おっしゃる通りだと思ったので今はCIの時に静的解析意見が変わってます。 意見が変わったというか、 記事を書いていた時におぼろげながら浮かんできたんです。46という数字が。持っていた違和感が言語化されたような感じですね。 ただ、せっかく慣れないシェルスクリプト書いたしまぁ使えないわけではないので下の部分も残してはおきます。 あくまでもこの下は「こういうこともできるよ。でももっといい運用があるから特別推奨はしないよ。」程度の気持ちで読んでください。 PHPer向けのpre-commitスクリプト Gitに上げる前に静的解析する為に作りました。 ※Laravel想定なので、他のフレームワークの場合はphpstanの設定周りで若干読み替えてください。 pre-commitとは 設定した状態でgit commitを実行するとコミットの前にこのスクリプトが走り、内容に問題があるとコミットが中止されます。(適当) 構成 phpstan(larastan) php -l(phpstan成功時に実行) phpstanがどの程度検出できるか正直わからないので念の為 php-cs-fixer 特定ディレクトリ以下などを対象に実行してしまうと改修範囲が膨大になり導入コストが上がってしまう為、 既存プロジェクトなどへの導入コスト低減の為コミット対象のファイルにのみ実行させている。 pre-commitファイル シェルは慣れてないので書き方はよくないかもです。 もっと良い書き方があればコメントいただけると幸いです。 特にエラー判定のあたりは正直「本当にこれでいいのか？」と思いながら書いてます...。 あと後半は概ねデフォルトのまんま。 ↓がpre-commitのファイルです。 #!/bin/sh if git rev-parse --verify HEAD >/dev/null 2>&1 then against=HEAD else # Initial commit: diff against an empty tree object against=`git hash-object -t tree /dev/null` fi phpfiles=`git diff --name-only --diff-filter=d $against | grep \.php` if [ "$phpfiles" != "" ]; then echo '####\033[32m check phpstan \033[m####' echo '####\033[32m check php-cs-fixer \033[m####' echo '####\033[32m check php -l \033[m####' echo # ディレクトリ定義 ROOT_DIR=`git rev-parse --show-toplevel` # エラー定義 errorStan=false errorCs=false errorL=false for file in `git diff-index --name-status $against -- | grep -E '^[AUM].*\.php$'| cut -c3-` do # phpstan実行 全ファイルにチェックすると既存ファイルにエラーがある時コミットできないので、コミット対象のファイルのみチェックする phpstanCheck=`./vendor/bin/phpstan analyze --memory-limit=2G $ROOT_DIR/$file` # エラーがなければ'No errors'という文字列があるので、それがない場合にエラーと判断 echo $phpstanCheck | grep 'No errors' > /dev/null 2>&1 # $?には直前の実行結果が入る if [ $? != 0 ]; then echo "####\033[31m　phpstan failed!!!! \033[m####$phpstanCheck\n" errorStan=true else # php -lによるシンタックスチェック実行 app/配下以外だとphpstanが実行されない気がする？為入れてる syntaxCheck=`php -l $file` # エラーがなければ'No syntax errors'という文字列があるので、それがない場合にエラーと判断 echo $syntaxCheck | grep 'No syntax errors' > /dev/null 2>&1 if [ $? != 0 ]; then # シンタックスエラーのあった場合はエラー内容を出力 echo "####\033[31m php -l failed!!!! \033[m####$syntaxCheck\n" errorL=true fi fi # php-cs-fixer実行 --dry-run で修正はせずに引っ掛かったらコミットさせずに修正を促す # --path-modeをintersectionにすることで、Finderが無視されないようにする .tools/php-cs-fixer/vendor/bin/php-cs-fixer fix --path-mode=intersection --dry-run $ROOT_DIR/$file > /dev/null 2>&1 if [ $? != 0 ]; then echo "####\033[31m php-cs-fixer failed!!!! \033[m####\n $ROOT_DIR/$file\n" errorCs=true fi done # "phpstan", "php-cs-fixer", "php -l"のどれかに引っ掛かっていたらコミットを中断 if "${errorStan}"; then echo "####\033[31m　Commit fail\033[m please fix \033[31mphpstan errors\033[m ####" fi if "${errorL}"; then echo "####\033[31m　Commit fail\033[m please \033[31msyntax check\033[m ####" fi if "${errorCs}"; then echo "####\033[31m　Commit fail\033[m please run \033[31m\"tools/php-cs-fixer/vendor/bin/php-cs-fixer fix\"\033[m command ####" fi if [ $errorStan -o $errorL -o $errorCs ]; then exit 1 fi echo '####\033[32m phpstan, php -l, php-cs-fixer all completed!! \033[m####' fi # この下はほぼ`git init`で生成されたデフォルトのまま # If you want to allow non-ASCII filenames set this variable to true. allownonascii=$(git config --bool hooks.allownonascii) # Redirect output to stderr. exec 1>&2 # Cross platform projects tend to avoid non-ASCII filenames; prevent # them from being added to the repository. We exploit the fact that the # printable range starts at the space character and ends with tilde. if [ "$allownonascii" != "true" ] && # Note that the use of brackets around a tr range is ok here, (it's # even required, for portability to Solaris 10's /usr/bin/tr), since # the square bracket bytes happen to fall in the designated range. test $(git diff --cached --name-only --diff-filter=A -z $against | LC_ALL=C tr -d '[ -~]\0' | wc -c) != 0 then echo "####\033[31m ここでエラーの場合はコミットしたファイルに空白行に余分なスペースがある可能性があります。\033[m #### ####\033[31m もしどうしても解決できない場合は'git commit -m \"commit message\" --no-verify'でprecommitを無効化させてください。(非推奨) \033[m ####" cat <<\EOF #### Error: Attempt to add a non-ASCII file name. This can cause problems if you want to work with people on other platforms. To be portable it is advisable to rename the file. If you know what you are doing you can disable this check using: git config hooks.allownonascii true #### EOF exit 1 fi # If there are whitespace errors, print the offending file names and fail. exec git diff-index --check --cached $against -- Set up MacOS想定 Gitは導入済みな想定 Composerも導入済みな想定 静的解析に必要なライブラリの導入 各プロジェクトにphpstan(larastan)とphp-cs-fixerが導入されている前提なので、これらの導入が必要。 ここではLaravel想定なので、phpstanではなくlarastanを導入するが、Laravel以外の場合はphpstanを導入してください。下に導入方法も書いてますが、古い可能性もあるので以下リンクの公式のインストールガイドを参照してください。 nunomaduro/larastan phpstan/phpstan friendsofphp/php-cs-fixer phpstan(larastan)の導入 $ cd path/to/your/project $ composer require --dev nunomaduro/larastan # Laravel以外の場合 # $ composer require --dev phpstan/phpstan $ vim phpstan.neon # 好きなエディタでプロジェクトrootに以下を作成 ↓phpstan.neonです。ほぼ公式のまま。 # phpstan.neon(for larastan) includes: - ./vendor/nunomaduro/larastan/extension.neon parameters: paths: - app # The level 8 is the highest level level: 5 ignoreErrors: - '#Unsafe usage of new static#' excludePaths: checkMissingIterableValueType: false php-cs-fixerの導入 $ cd path/to/your/project $ mkdir -p tools/php-cs-fixer $ composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer $ echo .php_cs.cache >> .gitignore # .gitignoreに.php_cs.cacheを追記 $ vim .php_cs.dist # 好きなエディタでプロジェクトrootに以下を作成 ↓.php_cs.distです。 こちらはsuinさんのソースコードの“赤ペン先生”PHP-CS-Fixerのインストールと設定をありがたく流用させていただいていたような気がします。感謝。 .php_cs.distは長いので折りたたんでます。 <?php use PhpCsFixer\Config; use PhpCsFixer\Finder; $rules = [ 'array_syntax' => ['syntax' => 'short'], 'binary_operator_spaces' => [ 'default' => 'single_space', 'operators' => ['=>' => null] ], 'blank_line_after_namespace' => true, 'blank_line_after_opening_tag' => true, 'blank_line_before_statement' => [ 'statements' => ['return'] ], 'braces' => true, 'cast_spaces' => true, 'class_attributes_separation' => [ 'elements' => ['method'] ], 'class_definition' => true, 'concat_space' => [ 'spacing' => 'none' ], 'declare_equal_normalize' => true, 'elseif' => true, 'encoding' => true, 'full_opening_tag' => true, 'fully_qualified_strict_types' => true, // added by Shift 'function_declaration' => true, 'function_typehint_space' => true, 'heredoc_to_nowdoc' => true, 'include' => true, 'increment_style' => ['style' => 'post'], 'indentation_type' => true, 'linebreak_after_opening_tag' => true, 'line_ending' => true, 'lowercase_cast' => true, 'lowercase_constants' => true, 'lowercase_keywords' => true, 'lowercase_static_reference' => true, // added from Symfony 'magic_method_casing' => true, // added from Symfony 'magic_constant_casing' => true, 'method_argument_space' => true, 'native_function_casing' => true, 'no_alias_functions' => true, 'no_extra_blank_lines' => [ 'tokens' => [ 'extra', 'throw', 'use', 'use_trait', ] ], 'no_blank_lines_after_class_opening' => true, 'no_blank_lines_after_phpdoc' => true, 'no_closing_tag' => true, 'no_empty_phpdoc' => true, 'no_empty_statement' => true, 'no_leading_import_slash' => true, 'no_leading_namespace_whitespace' => true, 'no_mixed_echo_print' => [ 'use' => 'echo' ], 'no_multiline_whitespace_around_double_arrow' => true, 'multiline_whitespace_before_semicolons' => [ 'strategy' => 'no_multi_line' ], 'no_short_bool_cast' => true, 'no_singleline_whitespace_before_semicolons' => true, 'no_spaces_after_function_name' => true, 'no_spaces_around_offset' => true, 'no_spaces_inside_parenthesis' => true, 'no_trailing_comma_in_list_call' => true, 'no_trailing_comma_in_singleline_array' => true, 'no_trailing_whitespace' => true, 'no_trailing_whitespace_in_comment' => true, 'no_unneeded_control_parentheses' => true, 'no_unreachable_default_argument_value' => true, 'no_useless_return' => true, 'no_whitespace_before_comma_in_array' => true, 'no_whitespace_in_blank_line' => true, 'normalize_index_brace' => true, 'not_operator_with_successor_space' => true, 'object_operator_without_whitespace' => true, 'ordered_imports' => ['sortAlgorithm' => 'alpha'], 'phpdoc_indent' => true, 'phpdoc_inline_tag' => true, 'phpdoc_no_access' => true, 'phpdoc_no_package' => true, 'phpdoc_no_useless_inheritdoc' => true, 'phpdoc_scalar' => true, 'phpdoc_single_line_var_spacing' => true, 'phpdoc_summary' => true, 'phpdoc_to_comment' => true, 'phpdoc_trim' => true, 'phpdoc_types' => true, 'phpdoc_var_without_name' => true, 'psr4' => true, 'self_accessor' => true, 'short_scalar_cast' => true, 'simplified_null_return' => false, // disabled by Shift 'single_blank_line_at_eof' => true, 'single_blank_line_before_namespace' => true, 'single_class_element_per_statement' => true, 'single_import_per_statement' => true, 'single_line_after_imports' => true, 'single_line_comment_style' => [ 'comment_types' => ['hash'] ], 'single_quote' => true, 'space_after_semicolon' => true, 'standardize_not_equals' => true, 'switch_case_semicolon_to_colon' => true, 'switch_case_space' => true, 'ternary_operator_spaces' => true, 'trailing_comma_in_multiline_array' => true, 'trim_array_spaces' => true, 'unary_operator_spaces' => true, 'visibility_required' => [ 'elements' => ['method', 'property'] ], 'whitespace_after_comma_in_array' => true, ]; $finder = Finder::create() ->in([ __DIR__ . '/app', __DIR__ . '/config', __DIR__ . '/database', __DIR__ . '/resources', __DIR__ . '/routes', __DIR__ . '/tests', ]) ->name('*.php') ->notName('*.blade.php') ->ignoreDotFiles(true) ->ignoreVCS(true); return Config::create() ->setFinder($finder) ->setRules($rules) ->setRiskyAllowed(true) ->setUsingCache(true); ※これ以下のgitの設定については詳しくは公式ドキュメントを参照してください。 端末の全リポジトリに共通で設定する場合 {pre-commitファイルをダウンロード} $ mkdir -p ~/.config/git/hooks $ mv ~/Downloads/pre-commit ~/.config/git/hooks/pre-commit $ chmod +x ~/.config/git/hooks/pre-commit $ git config --global core.hooksPath '~/.config/git/hooks' 既にclone済みの特定のリポジトリにのみ設定する場合 {pre-commitファイルをダウンロード} $ cd path/to/your/project $ mkdir .git/hooks $ mv ~/Downloads/pre-commit .git/hooks/pre-commit $ chmod +x .git/hooks/pre-commit 既存のリポジトリには設定したくないが、これから新規にcloneするリポジトリは全て反映させたい場合 {pre-commitファイルをダウンロード} $ mkdir -p ~/.git_template/hooks $ mv ~/Downloads/pre-commit ~/.git_template/hooks/pre-commit $ chmod +x ~/.git_template/hooks/pre-commit $ git config --global init.templatedir '~/.git_template/hooks' 実行 こんな風になります。 ちなみに既知の不具合として、Sourcetreeで行うと色が微妙な感じになりますが、対応する予定はありません。 余談 本当はこれはエディタレベルでやってしまいたい。 VS CodeのintelephenseというPHPの拡張機能が優秀なのでみんな入れましょうね。 余裕ができたらGitLabのCI環境も整備したい。 素敵な静的解析ライフを！

初めに CentOS7系では、gitのバージョンが1.8系で古いため、エラーになるスクリプトがあることに最近気づいた @CinTAKE です。 gitは、コードの共同開発には欠かせない便利なツールですが、親切すぎる部分もあり、問題が発生したりする。その中から重大なものや、よく出くわすものを取り上げ、原因や対処法を解説する。 事例と対処 Windowsでの改行コード問題 前提 発生環境：Windows ### 現象 クローン、チェックアウトでコード類の改行コードがCRLFになってしまい。 そのままの状態でコミットされてしまうこともあり、bashのスクリプトなどが動かなくなる。 ### 原因 WindowsのGITでは、デフォルトインストールで、改行コードの自動変換が設定されている。 # 設定を確認する；core.autocrlf => true ?? # 設定の確認：グルーバル git config --list --global # 設定の確認：ローカル(グローバルより優先となる) git config --list --local 対処 まず、グローバル設定を変更し、ローカル設定がある場合は、そちらも変更する。 CRLFが必要な場合は、ローカルで「git config --local core.autocrlf false」とするか、VSCの設定を変更する。1 # 改行コードをコミット時にのみ CRLF=>LF に変換(それ以外の操作では無変換) # グローバル git config --global core.autocrlf input # ローカル git config core.autocrlf input 結果と予防 clone や checkout ではリポジトリのままで持ってくることができるようになった。Linux系での運用が中心の場合はこの設定がよいと思う。CIで改行コードチェッカーなどをかますのも防止に役立つかも。 終りに 昔のMacOSはCRのみだったなーーー。 親記事：WSL2とVSCで作るWindowsでのDocker内開発環境(2021年睦月) テンプレート ## 事象のタイトル ### 前提 - 発生環境： ### 現象 ### 原因 ### 対処 ### 結果と予防 Git for Windowsの改行コードの設定 ↩

目的 チェリーピックの方法を個人メモ的にまとめる 方法 コミットをピックしてきたいブランチに移動する。 下記コマンドを実行してチェリーピックを行う。 $ git cherry-pick ピックしたいコミットID

タイトル通りです。 私はgit初心者なので、.gitignoreというやつを書かないまま適当にGoogle driveとかと同じノリでGitHubを使っていて、そういうノリで生きてました (今でもGitHubのことをGoogle driveとかと同じノリだと思ってますが...)。 そういうわけで、たとえばtexをコンパイルしたときに出るゴミファイルもgithubに保存されてて、こういうのって人から見たら「あっこいつ.gitignore書いてねえな」って思われるんだろうなって思うと、なんか恥ずかしくなっちゃって、はい... それでなんか「掃除」しようと思ったのでやったっていう話です。 この記事は、やったことを自分用にメモするだけの記事です。 (Macで、OSは Big Sur バージョン11.2.3 です) やったこと とりあえず.gitignoreを作成：giboというやつを使うと良いらしい やりたいこと：すでにgit管理下にあるファイルのうち今作った.gitignoreで弾かれるものを弾きたい。 3つの場合にわけてますが、最後の場合で全てカバーされているとは思います。 関係するファイル名やフォルダ名に日本語を使っていない場合 まず日本語関係ないのでそれに関する設定をtrueにする (何もしてなければ最初からtrueになっているはず)： git config --global core.quotepath true (--localでやってもいい。その場合、変更は現在のリポジトリだけに適用される。) で、この記事にある通り、 git rm -r --cached `git ls-files --full-name -i --exclude-from=.gitignore` を実行すればok。 ・cf. git rmについて ・cf. git ls-filesについて 日本語を使っているけど (半角の) 空白文字は使っていない場合 念のため、gitの日本語の設定をする。この記事にあるように、 git config --global core.quotepath false を実行するとok。 次に、先ほどと同じように git rm -r --cached `git ls-files --full-name -i --exclude-from=.gitignore` を実行すればok。 日本語も (半角の) 空白文字も使っている場合 (私の場合) 念のため、gitの日本語の設定をする。先ほどと同じで git config --global core.quotepath false を実行するとok。 次に、拡張子.shで次のファイル (cf. シェルスクリプトについて) を作成 (zshの人は1行目でzshにする): #!/bin/bash git ls-files --full-name -i --exclude-from=.gitignore | while read line do git rm -r --cached $line done ここでは「テスト.sh」という名前にしておく。 このファイルを保存する場所はどこでもいいけど、現在のディレクトリから近い場所にいる方が相対パス書くときにめんどくさくなくていいんじゃないかな...(適当)。 次に、「テスト.sh」の権限の変更をする (cf. 権限について)。ターミナルで chmod u+x テスト.shの相対パス を実行する。 最後に、ターミナルで「テスト.sh」の相対パスをなんのコマンドもなしに入力し、returnを押せばok。 なんらかがばーーーっとなっていい感じになってくれます (すごい)。 参考文献 git関係： ・giboについて：giboで簡単に最適な.gitignoreを作成 ・日本語について：最低限しておくといいgitconfigの設定 ・あとからまとめて.gitignoreする方法 ・git rmについて：gitの管理対象から特定のファイル、ディレクトリを削除する ・git ls-filesについて：git ls-files シェル： ・権限について：Linuxの権限確認と変更(chmod)（超初心者向け） ・シェルスクリプト(Bash)入門。できること、基礎文法、業務自動化の方法を解説【事例あり】 ・初心者向けシェルスクリプトの基本コマンドの紹介 ・shスクリプトにおける引用符

M1Mac でターミナルを複製して、ロゼッタ版とM1版のターミナルを用意する機会があり、もしや、ターミナルを複製したら、それぞれのターミナルでデフォルトディレクトリを設定できるのではないかと思い検証してみた。 →結論としては出来ない。 確認手順 ターミナルを「複製」 参考) M1版Macでのコマンドライン開発環境の雑多なこと - Qiita 複製したターミナルの名前を変更（ex)"ターミナル_ProjectB"） オリジナルのターミナルの名前はそのまま（アプリ名を変更できなかった） オリジナルのターミナルにデフォルトディレクトリを設定する ターミナル/環境設定.../プロファイル/シェル/コマンドを実行に cd コマンドを入力 cd /Users/[USER_NAME]/MyApps/ProjectA 参考) ターミナル起動時に、ホームディレクトリではなく任意のディレクトリをデフォルトに設定する - Qiita オリジナルのターミナルを再起動して、デフォルトディレクトリが ProjectA になることを確認 →OK 複製したターミナルに別のデフォルトディレクトリを設定する cd /Users/[USER_NAME]/MyApps/ProjectB 複製したターミナルを再起動して、デフォルトディレクトリが ProjectB になることを確認 →OK 再度オリジナルのターミナルを再起動して、デフォルトディレクトリが ProjectA になることを確認 →残念、NG。どちらのターミナルを開いても、最後に設定したデフォルトディレクトリが有効になってしまう SourceTree の「端末」 デフォルトディレクトリを設定しても SourceTree の「端末」からターミナルを起動すると、きちんと（デフォルトディレクトリは無視されて）SourceTree で開いているリポジトリがデフォルトディレクトリとして表示される。さすが SourceTree は優秀だな。 [注意]コンテキストメニューの「フォルダに新規ターミナル」 デフォルトディレクトリを設定すると、コンテキストメニューの「フォルダに新規ターミナル」からターミナルを起動しても、デフォルトディレクトリの設定が有効になってしまう。 MacのFinderで開いているフォルダをターミナルでカレント・ディレクトリとして開く方法＆アプリまとめ。 | AAPL Ch. おわりに 普段ターミナルを使うのは殆どが Git 操作なので、デフォルトディレクトリを Git リポジトリに設定したら、Git を使うのがとても楽になったが、たまーに違うプロジェクトで Git を使う時に、コンテキストメニューの「フォルダに新規ターミナル」が使えなくなってしまった。 仕方がないので、その時は SourceTree の「端末」を使ってターミナルを起動しているが、これがなんとかならないかなぁとたまーに思っている私。 やはり、今後も優秀な SourceTree に頼ることになりそうだな。 そもそも SourceTree はどうやってデフォルトディレクトリを調整しているのかを軽く調べてみたが、ちょっとよく分からなかった。

症状 ブランチで変更したファイルを切り出したブランチからマスターブランチにマージしようとしたら、エラーが表示されて、マージできませんでした。 ターミナル git merge Already up to date. 翻訳すると、「すでに最新です。」 merge先がすでに最新であるという意味だと推察します。 解決方法 masterブランチに移動後に、mergeし直したら解決しました。 merge文の使い方の理解が浅かったようです。 git mergeを使用する際は、masterブランチに移動しないといけないようです。 #ヴランチをマスターに変更 git checkout master #firstbranchを指定して、マスターにマージする git merge firstbranch