--- title: "Sourcetreeの使い方｜インストールから認証・カスタムアクションまで" url: "https://www.issoh.co.jp/tech/details/17494/" published: 2026-09-08 updated: 2026-09-08 categories: ["開発"] publisher: "株式会社一創" --- # Sourcetreeの使い方｜インストールから認証・カスタムアクションまで SourcetreeはAtlassianが無償で配布しているGitのGUIクライアントで、公式製品ページは「A free Git & Mercurial client」と説明しています。日本語の解説記事は「コマンドを覚えずに済む」という入口で終わっているものが多く、実務で引っかかるのはその先です。WindowsとmacOSでバージョン系列が違う、同梱Gitの版が古いまま残る、GUIが裏でどのgitコマンドを打っているのか分からない、Linux版が無いためチームで統一できない。この記事では入手から初回起動、リモート接続、履歴の書き換えと復旧、カスタムアクションでのgit直叩き、Git LFSとサブモジュールの詰まりどころ、採用しない条件までを扱います。版番号と数値は2026年9月8日時点の公式リリースノートとサポート文書の記載です。 ## まとめ｜Sourcetree導入前に確認する3点と2026年9月時点の現行バージョン 先に結論を。導入前に決めるのは、①配布対象のOSがWindowsとmacOSだけで足りるか、②同梱Gitで進めるかシステムGitに寄せるか、③GUIで完結させるかコマンド併用を前提にするか、の3点です。 版の現在地から。公式ダウンロードページの表示は、Windows版3.4.31（2026年6月9日公開）、Mac版4.2.18\_313でした。3系と4系に分かれているのはOS別の系列という理由で、機能差ではありません。同梱Gitは3.4.25でGit 2.51.0、Git LFS 3.7.0へ上がっています。 費用はゼロ。非公開リポジトリでも制限は付きません。GitKrakenの無料枠が「ローカルリポジトリと公開リモートのみ」に限られるのと比べると、受託開発でクライアント指定の非公開リポジトリを扱う場面ではSourcetree側に分があります。 ただし公式が配布しているのはWindowsとmacOSのインストーラだけで、Linuxクライアントはありません。開発機にLinuxデスクトップが混ざるチームでは、GUIを標準手順に据える前提そのものが崩れます。 ## WindowsとmacOSへSourcetreeをインストールして初回起動を通す手順 入手そのものに詰まる要素は無いので、版の見分け方と初回起動時の確認事項に絞ります。 ### Windows 3.4.31とmacOS 4.2.18で異なるバージョン系列の確認 入手先は[Atlassianの製品ページ](https://www.atlassian.com/software/sourcetree)で、上部のMac用ダウンロードボタンの下に「Also available for Windows」という導線が並びます。2026年9月8日時点の表示は、Mac版が4.2.18\_313、Windows版が3.4.31でした。 この番号差は系列が違うだけです。Windows版は[Windows専用のリリースノート](https://product-downloads.atlassian.com/software/sourcetree/windows/ga/ReleaseNotes%5F3.4.31.html)で3.4系として更新が続き、直近は3.4.31（2026年6月9日）、3.4.30（2026年3月7日）、3.4.29（2026年2月26日）です。3.4.30ではコミット履歴が更新されない不具合とShowRemoteBranch／AllBranchesビューの不具合が直りました。3.4.29はBitbucket Cloudの非推奨となったCross-Workspace APIを置き換える変更を含むため、古い3.4系のままだとリモート一覧の挙動が壊れる可能性があります。 配布前に「最低ライン」を決めておくと後の問い合わせが減ります。Bitbucket Cloudなら3.4.29以降、GitLabのグループ配下を一覧から選ぶなら3.4.31以降が目安です。 ### 初回起動でAtlassianアカウントを登録し埋め込みGitの版を確かめる手順 初回起動ではAtlassianアカウントでの登録を求められます。Bitbucketを使っていないチームでも登録自体は避けられません。アカウント作成が承認制の社内環境では、ここを配布前に通しておかないと初日に全員が止まります。 登録が済んだら、真っ先に同梱Gitの版を見てください。Sourcetreeは自前のGitバイナリを抱えており、それが古いと、コマンドで動く手順書がGUI経由で動かない食い違いが起きます。パスは[公式サポート文書](https://support.atlassian.com/sourcetree/kb/using-embedded-git-or-system-git-in-sourcetree/)に明記されています。 ``` # Windows（埋め込みGitの版を確認） "%LOCALAPPDATA%/Atlassian/SourceTree/git_local/bin/git.exe" --version # macOS（埋め込みGitの版を確認） /Applications/SourceTree.app/Contents/Resources/git_local/bin/git --version # システム側のGitと突き合わせる git --version ``` 2つの出力がずれていたら、どちらを使うかを先に決めてください。Windows版には Options の Git タブに「Update Embedded Git」という更新機能があり、同梱側を上げる手段が用意されています。 ## リモートリポジトリを登録してクローンからプッシュまで一往復させる作業 次は実際のリポジトリを繋ぎ、コミット周りの操作を対応コマンドへ翻訳するところまでを扱います。 ### BitbucketとGitHub・GitLabのアカウント追加とHTTPS認証の設定 リモートアカウントの追加は Remote タブから行い、ホスティング種別（Bitbucket／GitHub／GitLab）と認証方式を選びます。HTTPSの場合、パスワード欄に入れるのはアカウントのパスワードではなく各サービスが発行するアクセストークンです。GitHubは2021年にパスワード認証を止めているため、Personal Access Tokenを貼る流れになります。 入力したトークンはOSの資格情報ストアに預けられます。どのストアが使われているかは[git-configのリファレンス](https://git-scm.com/docs/git-config)にある credential.helper の値で判別できます。トークンを更新したのに古い認証で弾かれ続ける症状は、ここに残った資格情報が原因です。 GitLabを使うチームには、3.4.31で入ったグループ単位の表示が効きます。それ以前の版にはRemote Repositoriesビューにリポジトリが出ない・検索できない不具合がありました。運用面の差は[GitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準](https://www.issoh.co.jp/tech/details/4219/)で整理しています。 ### ファイル・ハンク・行単位のステージとコミット取り消しの操作対応表 Sourcetreeの実利は差分の粒度です。公式製品ページも「Stage and discard changes by the file, hunk or line」と書いていて、ファイル単位だけでなくハンク単位・行単位でステージを切り分けられます。コマンドなら `git add -p` で対話的に選ぶ場面が、クリックで済みます。 ただしGUIに閉じたままだと、レビューで「その操作が履歴に何をしたのか」を説明できません。よく使う操作は対応コマンドに置き換えて覚えておきます。 | Sourcetreeの操作 | 対応するgitコマンド | 作業ツリーへの影響 | | ----------------------- | -------------------- | --------- | | Stage File / Stage Hunk | git add / git add -p | 変更なし | | Unstage | git restore –staged | 変更なし | | Discard | git restore | 編集内容を破棄 | | Reset（Soft） | git reset –soft | 変更を残す | | Reset（Hard） | git reset –hard | 編集内容を破棄 | | Reverse commit | git revert | 打ち消しを追加 | 取り違えると痛いのはDiscardとReset（Hard）で、どちらも未コミットの編集が消えます。確認ダイアログは出ますが、stashしていない編集は戻せません。コミット粒度が荒れたときの整理は[git commitが多すぎる時の対処法｜squash・fixupでコミット履歴をまとめる手順と粒度の基準](https://www.issoh.co.jp/tech/details/2506/)にまとめてあります。 ## Git-flowとインタラクティブリベースでブランチ履歴を組み替える設定 Sourcetreeはgit-flowを同梱していて、公式製品ページも「Smart branching with Sourcetree and Git-flow」と機能に挙げています。 ### git-flow初期化でfeatureとreleaseブランチが増える履歴の変化 ツールバーの Git flow ボタンで初期化ダイアログが開き、develop／feature／release／hotfix のプレフィックスを決めて開始します。以後は「Start New Feature」でブランチが切られ、「Finish Feature」でdevelopへのマージとブランチ削除までが1操作にまとまります。 便利さの裏返しで、Finish時の挙動を把握しないまま押すと履歴が想定と変わります。既定ではfeatureブランチがマージ後に消えるため、後からそのブランチだけを見返したい運用とは噛み合いません。少人数でmainとfeatureの2本で足りているチームに、developとreleaseを増やすためだけにgit-flowを持ち込むのは過剰です。ブランチ本数を増やさず並行作業を回すなら、[Git Worktree（ワークツリー）とは｜使い方・削除(add/remove/prune)とSubmoduleとの違い](https://www.issoh.co.jp/tech/details/7018/)で扱っている作業ツリーの分離が合います。 ### インタラクティブリベース後にpushで弾かれたときのreflog復旧手順 Sourcetreeは対話的リベースをGUIで提供しており、3.4.27（2025年12月4日）でこの機能に改善が入りました。コミットの並べ替え・squash・メッセージ書き換えがドラッグ操作でできる反面、書き換えた履歴はリモートと食い違うのでpushが拒否されます。 force push に飛びつく前に、戻せる状態を確保してください。リベース前のコミットはreflogに残っています。 ``` # 直前までのHEADの移動履歴を確認する git reflog --date=iso # リベース前の位置に戻す（Nは reflog の該当エントリ番号） git reset --hard HEAD@{N} # 共有ブランチを上書きする場合は他者の追加を守る git push --force-with-lease origin feature/xxxx ``` 共有ブランチに `--force` は使いません。`--force-with-lease` なら、自分が最後に見た時点からリモートが進んでいた場合に拒否されるため、他のメンバーのコミットを吹き飛ばす事故を防げます。Sourcetreeのpushダイアログにも force オプションのチェックはありますが、共有ブランチではコマンド側で lease 付きに切り替えてください。 ## 埋め込みGitの切り替えとカスタムアクション登録で作業を自動化する手順 ここからが初心者向け解説では触れられない実務設定です。同梱Gitの扱いとカスタムアクションを押さえると、GUIを使いながらコマンドの再現性を保てます。 ### オプション画面で埋め込みGitとシステムGitを入れ替える判断基準 切り替えはWindowsが Tools の Options から Git タブ、macOSが Preferences の Git タブです。公式サポート文書では、Windows側に「Use Embedded Git」と「Use System Git」、macOS側に「Reset to Embedded Git」と「Use System Git」の選択肢があると案内されています。実パスはWindowsが `%USERPROFILE%/AppData/Local/Atlassian/SourceTree/git_local/bin`、macOSが `/Applications/SourceTree.app/Contents/Resources/git_local/bin` です。 どちらを選ぶか。手順書やCIがシステムGitのバージョン前提、あるいは `.gitconfig` へ社内共通の設定を流し込んでいるなら、システムGitに寄せてください。開発機ごとに版がばらけて統一できないなら、同梱Gitのまま揃えたほうが再現性は上がります。一番まずいのは混在の放置で、同じリポジトリでGUIとターミナルの挙動が食い違います。 この種のばらつきは開発体制を引き継ぐ場面で表に出ます。既存プロジェクトの保守を引き取る、内製チームへ移す、といった局面の運用整備は[保守運用 / 内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で承っています。 ### カスタムアクションにgit.exeとパラメータを登録して定型作業を短縮 カスタムアクションは、任意の実行ファイルとパラメータを登録してメニューから呼び出す機能です。設定場所はWindowsが Tools の Options から Custom Actions、macOSが Preferences の Custom Actions で、Add を押して内容を入れます。3.4.27ではショートカット割り当ても追加されました。 [公式サポート文書](https://support.atlassian.com/sourcetree/kb/using-git-in-custom-actions/)には、ステージされていない .txt ファイルをすべて追加する例と、ステージ済みのファイルを固定メッセージでコミットする例が載っています。実行ファイルに同梱Gitのパスを指定すれば、システムGitの有無に関係なく同じ動作になります。 ``` # カスタムアクションの登録内容（Windows・同梱Gitを直接指定） Menu caption : Stage all text files Script to run: %USERPROFILE%/AppData/Local/Atlassian/SourceTree/git_local/bin/git.exe Parameters : add --all -- *.txt # 実行結果を確認する（ターミナル側） git diff --cached --name-only ``` 使いどころは絞ってください。プロジェクト固有の整形コマンド、コミット前のlint、社内規約に沿ったブランチ名の生成といった「毎回同じ引数で叩くもの」を登録します。引数が毎回変わる操作をここに入れても事故が増えるだけなので、コマンドラインに残します。GitHub側の操作をまとめて自動化するなら、[ghコマンド（GitHub CLI）とは？インストール方法と使い方・主要コマンド一覧](https://www.issoh.co.jp/tech/details/3547/)で扱っているCLIを呼び出す形が扱いやすいです。 ## Git LFSとサブモジュール入りリポジトリでGUI操作が詰まる箇所と回避 大きなバイナリと外部リポジトリの参照が絡むと、GUIの表示と実際の状態がずれます。 ### git lfs installの実行漏れで起きる巨大差分とその戻し方 公式製品ページは「Sourcetree supports Git LFS」と明記しており、Repository メニューから追跡対象を管理できます。ただし[Git LFS](https://git-lfs.com/)のフックがユーザー環境に入っていない状態でクローンすると、ポインタファイルではなく実体が入ったり、逆に中身が空のポインタだけが手元に来たりします。 ``` # フックの導入と追跡対象の登録 git lfs install git lfs track "*.psd" git add .gitattributes # 実体がLFS管理下にあるか確認する git lfs ls-files # ポインタだけ来ている場合に実体を取り直す git lfs pull ``` 厄介なのは、`.gitattributes` をコミットする前に大きなファイルを普通にコミットしたケースです。この時点で実体が履歴に入るため、後からtrackを追加しても過去分は残ります。気づいた時点で `git lfs migrate` による履歴の書き換えか、ブランチを切り直すかの判断になります。同梱Gitを使っているなら、Git LFSも3.4.25以降で3.7.0系が入っているため、フック側の版が古くて動かない線は薄いでしょう。 ### サブモジュールの更新がGUIに出ないときのコマンド併用と確認手順 サブモジュールはサイドバーのSubmodulesから追加・更新できます。公式製品ページも依存関係の管理手段として挙げていますが、親リポジトリが記録している参照先コミットと手元のディレクトリ状態がずれたとき、GUI上は「変更あり」とだけ出て原因が読めません。 ``` # 初回クローン後や参照先が動いたときに揃える git submodule update --init --recursive # 親が記録している参照先と手元の差を見る git submodule status # 親リポジトリ側で参照先の更新をコミットする git add path/to/submodule git commit -m "submodule: bump reference" ``` サブモジュールの実体はディレクトリですが、親リポジトリが持っているのはコミットハッシュ1つだけです。この構造を分かっていないと「サブモジュール内で作業してコミットしたのに、親をpushしても他の人に反映されない」という定番の詰まりに落ちます。混同されやすい作業ツリーとの違いは[Git worktreeの使い方｜基本コマンド・削除・移動と並行開発・GUI連携を解説](https://www.issoh.co.jp/tech/details/10306/)と[git-worktreeのコマンド仕様](https://git-scm.com/docs/git-worktree)で確認できます。 ## Sourcetreeを採用しない条件とGitKrakenとの選び分けの基準 無料で機能も揃っているぶん既定の選択肢になりやすい一方、配らないほうがよい状況がはっきりあります。ここは条件付きで言い切ります。 ### Linuxクライアント不在でOS混在チームが統一できない場面の見送り判断 公式ダウンロードページが提供しているのはmacOS版とWindows版だけで、Linux版のインストーラはありません。開発機にLinuxデスクトップを使うメンバーがいるチームでは、Sourcetreeを標準手順の前提に据えるのを見送ってください。一部だけGUI、残りはコマンドという状態は、手順書が二重化して保守できなくなります。 代替はエディタ内蔵のGit機能です。VS CodeのソースコントロールビューはWindows・macOS・Linuxで同じ操作になるため、OS混在でも手順書が1本で済みます。Sourcetreeを配るのは、開発機がWindowsとmacに閉じていて、かつ行単位ステージや履歴グラフを日常的に使う場合に限ります。 ### 無料枠の条件で比べたGitKraken Communityとの機能差と選定基準 比較で最初に見るのは価格ではなく、無料枠が非公開リポジトリを許すかどうかです。GitKrakenは[価格ページ](https://www.gitkraken.com/pricing)で無料のCommunityプランを「ローカルリポジトリと公開リモートのみ」と定義し、マージコンフリクトの出力エディタや複数リポジトリの一括fetch、対話的リベースを公開リポジトリ限定としています。受託開発では扱うリポジトリのほぼ全部が非公開なので、この条件は実質的に有料前提を意味します。 | 観点 | Sourcetree | GitKraken Community | | ------- | --------------- | ----------------------- | | 費用 | 無料 | 無料 | | 非公開リモート | 制限なし | 対象外 | | 対応OS | Windows / macOS | Windows / macOS / Linux | | 対話的リベース | GUI対応 | 公開リポジトリのみ | | Git LFS | 対応 | プランにより差 | 選定はこう切ります。WindowsとmacOSだけのチームで非公開リポジトリを扱うならSourcetree。Linuxを含むならGitKrakenの有料プランかVS Code内蔵。コミット数が数十万規模まで育って履歴グラフの描画が待ち時間になるなら、GUIを日常操作から外してコマンドへ寄せます。「無料だから全員に配る」という決め方は、後からOS要件と性能の両方で行き詰まります。 ## よくある質問 Sourcetreeの導入と運用でよく検索されている質問に答えます。 ### Sourcetreeは無料で商用のプライベートリポジトリにも使えますか？ 使えます。公式製品ページはSourcetreeを「A free Git & Mercurial client」と説明しており、リポジトリの公開・非公開による制限は示されていません。有料プランや座席数の上限も無いため、クライアント指定の非公開リポジトリでもそのまま使えます。ただし初回起動時にAtlassianアカウントでの登録を求められるので、アカウント作成が承認制の環境では配布前に手続きを済ませてください。 ### SourcetreeにLinux版はありますか？代わりに何を使えばよいですか？ ありません。公式ダウンロードページが提供しているのはmacOS版とWindows版のインストーラだけです。Linuxで同等の操作をするなら、VS Codeのソースコントロールビュー、GitKraken（Linux対応・非公開リモートは有料）、lazygitのようなターミナルUIが選択肢になります。OSが混在するチームでは、GUIを標準手順に据えずコマンド前提の手順書へ統一するほうが保守は楽です。 ### Sourcetreeが起動しない・リポジトリが開けないときは何を見ますか？ まず版を見てください。Windows版3.4.29はBitbucket Cloudの非推奨APIを置き換える変更を含むため、それ以前の版ではリモート一覧が正しく動かない場合があります。3.4.30ではコミット履歴が更新されない不具合とShowRemoteBranch／AllBranchesビューの不具合が、3.4.31ではGitLabリポジトリが表示・検索できない不具合が直りました。既知不具合と症状が一致するなら更新が先です。一致しないなら、同梱Gitとシステムのgitを両方 `--version` で叩き、どちらで再現するか切り分けます。 ### SourcetreeのGit本体を新しいバージョンに上げる方法はありますか？ 2通りあります。Windows版なら Options の Git タブにある「Update Embedded Git」で同梱Gitを更新できます。もう1つは公式サポート文書の手順で「Use System Git」に切り替え、OS側のGitを使わせる方法です。切り替え先はWindowsが Tools の Options から Git タブ、macOSが Preferences の Git タブで、macOSには「Reset to Embedded Git」で戻す選択肢もあります。同梱Gitは3.4.25でGit 2.51.0・Git LFS 3.7.0へ上がっており、本体更新だけでも版は前進します。 ### SourcetreeとGitHub Desktopはどちらを新人に配ればよいですか？ 扱うホスティングで決めます。GitHubだけを使い、コミットとプッシュ以上をしないならGitHub Desktopのほうが画面が単純で覚える要素も少なくて済みます。Bitbucketやセルフホストが混ざる、行単位ステージや対話的リベースを教える、git-flowを運用に入れる、といった場合はSourcetreeです。どちらもLinux版が無い制約は共通なので、開発機のOSを先に確認してください。 ## 関連記事 - [Git worktreeの使い方｜基本コマンド・削除・移動と並行開発・GUI連携を解説](https://www.issoh.co.jp/tech/details/10306/)：GUIと作業ツリーの分離を組み合わせる操作。 - [Git Worktree（ワークツリー）とは｜使い方・削除(add/remove/prune)とSubmoduleとの違い](https://www.issoh.co.jp/tech/details/7018/)：git-flowを入れる前に検討する並行作業の手段。 - [git commitが多すぎる時の対処法｜squash・fixupでコミット履歴をまとめる手順と粒度の基準](https://www.issoh.co.jp/tech/details/2506/)：対話的リベースで履歴を整える粒度の基準。 - [GitHubとGitLabの違いを比較｜CI/CD・セキュリティで選ぶ判断基準](https://www.issoh.co.jp/tech/details/4219/)：リモート追加の前に済ませるホスティング選定。 - [ghコマンド（GitHub CLI）とは？インストール方法と使い方・主要コマンド一覧](https://www.issoh.co.jp/tech/details/3547/)：カスタムアクションから呼び出す自動化の実体。 --- 出典: [Sourcetreeの使い方｜インストールから認証・カスタムアクションまで]()（株式会社一創）