GitHubでソースコード管理するハンズオン

## イントロ

プログラムでもドキュメントでも、なにか書き物をしていると、**ある時点の状態を保存**しておいたり、そもそも**バックアップをとって**おきたくなったりしますよね。またプログラムのソースコードだと**修正方針1と2をそれぞれ別にとっておきたい**とか、**このコード改修は次のリリースに入れないから別で保存しておきたい** 、なんてこともあります。

こういったいわゆる**書き物をバージョン管理したいニーズ**にこたえるシステムとして、**Git (とそのWEB上のサービスGitHub ) という仕組み**があるので、その使い方を紹介します。

また、Git/GitHubは通常コマンドを使って操作するのですが、初見の方にはなかなか敷居も高いですよね。なので今回は、**GUIでGitを操作できる SourceTreeというアプリケーション**を使っていきます。

操作説明はSourceTreeを前提としていますが、すでにGitを扱う環境がある方は「[やってみる](https://qiita.com/masatomix/items/a3f99a1700a835e845dd#%E3%82%84%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B)」から操作していただければとおもいます。

本記事をハンズオンするには、**受信可能な E-mail アドレスが必要**なので、準備しておきましょう。


## 本ハンズオンの概要

- GitHubのアカウントを作成して、**GitHubをつかえる状態**にします
- SourceTreeというアプリケーションをインストールして、つかえる状態にします
- GitHubでリポジトリを作成し、**SourceTreeから操作(クローン、コミット、プッシュ、フェッチ、プル)**してみます
- ブランチをつくって、**プルリクエストでマージ**してみます


## Gitって

さてGitって具体的にどんなモノ？リポジトリってなに？などいろいろあると思いますが、そういった説明はすでにたくさんの情報がネットにあるので、説明はここでは割愛します。(ハンズオン中心ですゴメンナサイ)

初めてGitを触るヒトは「[サル先生のGit入門](https://backlog.com/ja/git-tutorial/)」このサイトがわかりやすくてとてもオススメです。特にはじめの

- Gitを使ったバージョン管理
https://backlog.com/ja/git-tutorial/intro/01/

- 履歴を管理するリポジトリ
https://backlog.com/ja/git-tutorial/intro/02/

- 変更を記録するコミット
https://backlog.com/ja/git-tutorial/intro/03/

- ワークツリーとインデックス
https://backlog.com/ja/git-tutorial/intro/04/

あたりは、とてもわかりやすいです。


## 操作するための準備

### GitHubへのサインアップ

GitHubはGitのサーバをホスティングするWEBのサービスです。アカウントが必要なのでまずはアカウント作成から。

https://github.com/ 右上のリンクより、サインアップを開始します。
![101](https://imgur.com/c6px3jQ.png)

適当(適切) に ユーザ名やアドレス/パスワードなどを入力して「Create account」をクリック。
![102](https://imgur.com/ZLrYzBi.png)

うまくいったようです。アンケートにこたえて、「Complete setup」をクリックします。
![103](https://imgur.com/j9nfQre.png)
![104](https://imgur.com/Ibw9qLq.png)

メールの所有者であることを確認するためのVerification mailが飛ぶので、それを処理すれば、セットアップ完了です。
![105](https://imgur.com/GkikNIc.png)



### WEB画面でリポジトリ作成

つづいて**WEB画面からリポジトリを作成**します。ログイン状態で、右上の「New repository」を選択。
![106](https://imgur.com/205g6nV.png)

リポジトリの名前はここでは「``hello2020``」としました。はじめからREADMEは作っておきましょう[^1]。

さいごに「Create repository」をクリック。
![107](https://imgur.com/Bms7LYO.png)

[^1]: メインのブランチ(master branch)をあらかじめ作ってくれるなどの効果があるので...。

「``hello2020``」というリポジトリが作成できたようですね。
![108](https://imgur.com/LLLjrjQ.png)


リポジトリはこのように

- WEB上で新規作成して、それをローカル(PC上)にCloneしてつかう
- ローカル上いろいろ作成したコード群があるとして、ローカル側でリポジトリを作成して、それをリモート(WEB)に公開する

などいくつかやり方があります。**今回は前者**を用いました。

### SourceTreeのインストール(とAtlassianアカウント作成)

https://www.sourcetreeapp.com/ よりインストーラをダウンロードし、起動します。

SourceTreeをつかうために**Atlassianのアカウントを作る必要がある**ようなので、まずはアカウント作成。
![000](https://imgur.com/AVQV6m3.png)


Atlassianにサインアップするためのアドレスなのでこの際なんでも良いんですが、用意した**GitHubで使うアドレスを使う**ことにします。
![001](https://imgur.com/r8YTFHc.png)

フルネームやパスワードを設定し「Sign Up」をクリック
![002](https://imgur.com/p9f0Gn9.png)

アドレスにメールが飛んだはずなので、本人確認してください。
![003](https://imgur.com/BDSt2mG.png)

あとはユーザ名を指定して、続行 をクリックで、サインアップ完了です。
![004](https://imgur.com/OZaQD2s.png)


さてインストーラに戻って「Bitbucket」を選択して次へ[^2]。

[^2]: この辺もなんというかBitbucketは使わないんだけど、、作成してる感じです、、。

![005](https://imgur.com/R0axITG.png)

ブラウザ画面での操作待ちになっています。ブラウザも起動したと思うので、、
![006](https://imgur.com/pNRPHnA.png)

こちらでログイン後、下記の認可画面でOK(アクセスを許可する) をクリック。
![006_1](https://imgur.com/H86UmW3.png)

ようやく、アカウント作成とログインが完了しました。次へ。
![007](https://imgur.com/JPJwrXb.png)

ツールとしてGitをインストールをチェック。次へ。
![008](https://imgur.com/vuSoQNp.png)

インストール完了です。
![009](https://imgur.com/b4ObtwH.png)

先ほどの情報が入っているので、そのまま次へ(チェックボックスはどちらでも)。
![010](https://imgur.com/CVf4LNo.png)

SSH用のキーの取り込みをするか、を聞かれるのですがとりあえず「いいえ」で。
![ssh001](https://imgur.com/uFyA7s4.png)

長かったですが、ようやくSourceTreeの起動ができました。
![011](https://imgur.com/IOWUtdR.png)



普通にSourceTreeを起動したいだけなんですけどね。めんどくさいです。

またまた、**環境によってはスタートメニューに「SourceTree」が登録されない**ようなので、今のうちに、タスクバーを右クリックして「**タスクバーにピン留めする**」をしておいた方がよさそうです。
![task](https://imgur.com/4q4UZcY.png)

ココまでで、

- GItHubへのサインアップ
- SourceTreeツールのインストール

が完了しました。おつかれさまでした。

### SourceTreeとGitHubアカウントの紐付け

SourceTreeが起動したので、GitHubを操作するために**先ほど作成したGitHubアカウントをSourceTreeに登録**していきます。

「アカウントを追加」をクリック
![200](https://imgur.com/gA3EuGf.png)

サービスを「GitHub」プロトコルを「HTTPS」、認証は「OAuth」で「トークン再読み込み」をクリック
![201](https://imgur.com/jNShggY.png)

トークンをとるためにGitHubの認証をします。
![202](https://imgur.com/HG42J7s.png)

「Authorize atlassian」をクリック
![203](https://imgur.com/XrvAO82.png)

認証完了です。この画面はとじてOKです。
![204](https://imgur.com/Ld2LGjz.png)

SourceTreeのアプリに戻ってみると、トークンが取れていることが分かります。OKをクリック。
![205](https://imgur.com/50UIEfl.png)

SourceTree上でGitHubアカウントが確認できました。先ほど作成したリポジトリも表示されていますね。
![206](https://imgur.com/mrPUv69.png)

ようやく準備が完了です。おつかれさまでした。



## やってみる

### リポジトリをクローン

SourceTreeをつかってクローンをおこないます。「hello2020」の右下の Clone をクリック
![206](https://imgur.com/mrPUv69.png)

リポジトリはすでに選択された状態(赤枠内)なので、Clone先のPCのフォルダなどを確認しつつ「クローン」をクリック。
![207](https://imgur.com/zgtw74j.png)


クローン完了です。先ほどWEB画面で作成していたREAME.mdなどが確認できると思います。
![208](https://imgur.com/Kp7BRKC.png)


### はじめてのコミットとプッシュ

右上の「Explorer」アイコンをクリックすると、クローンしたディレクトリがエクスプローラで表示されるので、適宜操作してコミットするファイルを作成してください。下記画面は「``sample.txt``」を作成した図です(まちがってsample.txt.txt になっちゃってますけど、、)。

さて、**このファイルをコミットしたのち、サーバリポジトリへプッシュ**していきます。

まずは該当ファイルを選んで「+」をクリックして、Indexへステージさせます。わかりにくい言い回しですが、ようするに「**コミットしたいファイル(たち)を選んでいる**」だけですね。
![209](https://imgur.com/D6Q8W87.png)

ステージされました。つづいて、それらのファイル(今回は1つですが) をコミットする際のメモ「**コミットログ**」を記載して「コミット」をクリック。
![210](https://imgur.com/Dz478Ey.png)

ローカルのリポジトリへコミットされました。**サーバのリポジトリにはまだ反映前**なのでツールバーのアイコンや左部のmasterの右に「**差分があるよ**」というマークが付いているのが分かります。

さて、差分をサーバに反映させるために、ツールバーの「プッシュ」をクリック。
![211](https://imgur.com/Ni89w2w.png)

masterブランチが選択されています(ブランチについては後述)。そのまま「プッシュ」をクリック。
![212](https://imgur.com/DyUqpc6.png)

環境によってはなにやら下記のダイアログが表示されるようなので、credential helperを「wincred」にして「Always use this from now on」のボックスにチェックを入れて「Select」を選択。
![ssh002](https://imgur.com/cDIQrRA.png)

認証を求められる場合もあるようで、その場合はGitHubのアカウント情報を入力します。今後は表示されなくなる(と思う!)のでご安心ください。
![214](https://imgur.com/hfTbrlw.png)

プッシュが正常に終了すると「完了しました」と表示されます。このダイアログは閉じてしまいましょう。
![215](https://imgur.com/QYs9u3w.png)

サーバにプッシュが完了したようなので、ブラウザで先ほどのリポジトリを見てみると、**sample.txt がサーバのリポジトリ上にもコミットされている**のが分かります。
![216](https://imgur.com/JfcucXs.png)

ここまでの作業を整理すると、Gitの仕組みは

- サーバ上のリポジトリを「クローン」して**ローカルにリポジトリをコピー**してくる
- ローカル上で対象ファイルを修正して、**ローカルのリポジトリに「コミット」**する
- ローカルのリポジトリの更新内容を**サーバ上のリポジトリへ「プッシュ」**することで、サーバへ情報を反映させる

となっていることが分かります。この**ローカルのリポジトリで更新(コミット)をしているあいだは、サーバとの通信が発生しない**ところが、他のバージョン管理ツールたとえば Subversion とかとの大きな違いです。**分散型**バージョン管理ツールとよばれるゆえんですね。

### 修正、コミット、再度プッシュ

つづいて、PC上でファイルを修正し、コミット/再度プッシュを行ってみましょう。

テキストファイルを修正した後、**SourceTreeの「ファイルステータス」をクリックしてみると**、修正を検知して差分ファイルが表示されます。**右上部にはファイルの変更点**(削除箇所が赤、追加箇所が緑、など) が表示されているので、修正内容を確認しておきましょう。

さてコメントを入れてコミットですが、今回はためしに「変更をすぐに origin/masterにプッシュする」をチェック入れてコミットしてみましょう。**コミットからプッシュまでを一度に行ってくれ**て便利です。自分はコミットとプッシュは丁寧にやりたい派なので、使いませんけど :-)
![re_push001](https://imgur.com/oXBw7mW.png)

コミットとプッシュが正常に終了したようです。一応WEB画面も確認しておいてください。
![re_push002](https://imgur.com/bMR6a9J.png)

### サーバ上の変更の取り込みのフェッチ、プル

さて、他のPCとかからプッシュされたコミットの情報[^3]は、ローカルに取り込まなければいけませんよね。

[^3]: つまり他のローカルリポジトリからプッシュされた情報

そのとき使う機能が「フェッチとプル」です。**フェッチはサーバ上のリポジトリ情報の変更をチェックする機能**、**プルは実際に変更点をローカルリポジトリに反映させる機能**です。厳密には微妙に違うんですが、だいたいそんな意味と覚えておけばOKです。

参考: [GitHub/ローカル・リモートブランチとoriginのはなし](https://www.masatom.in/pukiwiki/GitHub/%A5%ED%A1%BC%A5%AB%A5%EB%A1%A6%A5%EA%A5%E2%A1%BC%A5%C8%A5%D6%A5%E9%A5%F3%A5%C1%A4%C8origin%A4%CE%A4%CF%A4%CA%A4%B7/)

フェッチとプルをやってみます。別PCからコミット&プッシュしたいところですが、PCが一つしかない場合もあるでしょうから代替案をとります。
実はGitHubは、サーバ上のリポジトリをWEB画面上でそのまま修正してコミット&プッシュできるので、それを代替案とします。

つまり流れは

- WEB画面上で**修正・コミットしてサーバ上でリポジトリを更新**します。
- PC上のSourceTreeで**サーバ上の変更をフェッチとプルで取り込み**ます。

となります。

GitHubの画面で、編集する``sample.txt``をクリック。
![f001](https://imgur.com/7Ciw4kh.png)

エンピツマークをクリックして編集モードにします。
![f002](https://imgur.com/LKDurny.png)

編集したことが分かるように適当に文字列を追加するのと、あとはコミットログを記載して「Commit changes」をクリック。
![f003](https://imgur.com/tssraw2.png)

コミットされたので、リポジトリ名のリンクで始めのページに戻ります。
![f004](https://imgur.com/Adse3Np.png)

画面のログを見ると、コミットされていることがわかりますね。 

WEB上でのサーバリポジトリの更新作業は以上です。
![f005](https://imgur.com/DjJYtEA.png)

つづいてPC上のSourceTreeで、サーバリポジトリの変更内容をフェッチ&プルします。

まず初期状態は、**「ローカルのmaster」の状態を表すmasterブランチ**と **「リモートのmaster」の状態を表す origin/master ブランチ**が、おなじコミット(図中 の``cea341e``)を指しています。

サーバ上の更新をチェックするため「フェッチ」をクリックします。
![f006](https://imgur.com/XKuxqYS.png)

ダイアログが出てくるのでそのままOKをクリック。
![f007](https://imgur.com/7yh22so.png)

正常終了したようですね。先ほどは**masterブランチと origin/masterブランチがおなじコミット**を指していましたが 、今見てみると**origin/masterが一つ次のコミットを指していて、サーバのリポジトリだけがひとつ進んでいる**ことが分かります。というわけで、ローカルのリポジトリに取り込むためにツールバーの「プル」をクリックします。
![f008](https://imgur.com/QY1oI99.png)

ダイアログが出てくるので、そのまま「プル」をクリックします。
![f009](https://imgur.com/qifPt0P.png)

正常終了したようです。ふたたび**masterとorigin/masterがおなじコミット**を指している状態になりました。
![f010](https://imgur.com/3cLylKR.png)

サーバリポジトリで更新されたファイルをPC上で開いてみても、更新が反映されているようですね。
![f011](https://imgur.com/Mle1kxI.png)

うまくいきました。

フェッチとプルで、自分のローカルリポジトリの更新するほうほうは以上です。






### ブランチを作って、複数バージョンを管理する

ブランチ機能は、はじめの説明にも書いた **修正方針1と2をそれぞれ別にとっておきたい** みたいなケースで使います。**ブランチという枝分かれ機能**をつかうことで、複数の修正方針を同時にバージョン管理できるってことです[^4]。

[^4]: 当たり前といえばそうですが、バージョン管理システムには大抵この機能が備わっています。

このハンズオンはブランチをあまり意識・説明しないでここまでやってきましたが、じつはずっと「masterブランチ」に対して更新を行っていました。プッシュする先の指定に「masterブランチ」ってのが出てきたり、フェッチとプルのときもmaster, origin/masterなどが出てきましたね。



さて、やってみます。流れは

- masterブランチから、**develop1ブランチ、develop2ブランチを作成**します
- develop1ブランチに切り替えます。**develop1ブランチで ``sample.txt`` を修正し、コミット**します
- develop2ブランチに切り替えます。``sample.txt``が「**develop1でのコミット前に戻っている**」事を確認します
- **develop2ブランチで、``sample.txt``を修正し、コミット**します。
- develop1/develop2ブランチを切り替えて、コードが複数バージョン管理できていることを確認します。
- それぞれのブランチをプッシュすることで、サーバのリポジトリ上でも複数バージョン管理できていることを確認します。
- masterブランチに切り替えて、どちらのバージョンも反映されていないことを確認します。

まずは別のブランチの作成です。SourceTreeで、ツールバーの「ブランチ」をクリック。
![m001](https://imgur.com/TZtBpKp.png)

ダイアログが表示されます。masterブランチから枝分かれするブランチを作成するので、

- 現在のブランチが「master」
- 新規のブランチは「develop1」
- コミットが「作業コピーの親」
- 新規ブランチを作成して、チェックアウトは「チェックはずす」

として「ブランチを作成」をクリックします。
![m002](https://imgur.com/VXKRPOF.png)

ブランチが作成されたとおもいます。

ちなみに「**develop1をmasterからブランチさせる**」の意味は「**masterが指しているコミット番号``f45b88d``に、別名のブランチ名develop1をつける**」という意味です。なので上記の画面でコミットを「指定のコミット」を選んで、その右部でコミット番号``f45b88d``を指定してブランチしてもOKです。

また「新規ブランチを作成してチェックアウト」の**チェックアウトの意味は、新規作成したブランチを選択状態にするか**、です。



さておなじ操作で develop2も作成します。結果、下記のように**masterブランチとおなじコミットにdevelop1/develop2という名前がつけられ**ました。
![m003](https://imgur.com/MHOckr8.png)

さて、develop1へ選択しているブランチを切り替えます。**切り替えることを「チェックアウト」といいましたがSourceTreeの左部のブランチ名をダブルクリック**することで、チェックアウトができます。
![m004](https://imgur.com/VW9skfm.png)

さて、``sample.txt``  を修正しコミット&プッシュします(サーバリポジトリ上にはdevelop1がまだないので、プッシュ時に、リモートブランチの表示が空のままになってたりしますが、適宜チェックを入れてください)。



下記の通り、**develop1(やサーバのorigin/develop1)のコミットが、ひとつ進んだ状態**になります。
![m005](https://imgur.com/3JFxv1w.png)

つづいてdevelop2をクリックしてブランチをチェックアウト(切替)します。この時点で``sample.txt``  が**develop1のコミット前に戻っている**ことを確認しつつ、
![m006](https://imgur.com/0uFWs1L.png)

``sample.txt``  を修正してコミットしてプッシュすると、、下記の通り**develop1とは別に枝分かれしながら、develop2がひとつ進んだ状態**になりました。
![m007](https://imgur.com/27BvUEa.png)

以上で、**master(が指しているコミット``f45b88d``)を分岐点として、develop1 と develop2が枝分かれして並行にバージョン管理された状態になっている**ことが分かりました。ブランチを master/develop1/develop2にパチパチ切り替えてみて``sample.txt``がそれぞれバージョン管理されていることを確認してみてください。



### ブランチからマージする

さて、develop1/develop2 のうちの一つを、masterブランチに反映させます。ある**ブランチの修正内容を他のブランチに反映させる機能が「マージ」**です。

マージ機能は

- ローカルリポジトリ間でコマンドやSourceTreeをつかってマージする「マージ」機能 
- サーバのリポジトリ間で「マージしてください」というリクエストを投げることでサーバ上でマージする「プルリクエスト」機能

があります。後者はGitの標準機能ではなく**GitHubなどWEB上のホスティングサービスが持つ機能**[^5]なのですが「マージの依頼」と「マージの承認」という役割分担が**ソースコードの品質管理上とても便利**なので、今回はこちらを使ってみます。

[^5]: ほぼすべてのWEBサービス(GitHub,Gitlab,BitBucketなどなどすべて、名前は違うけど同じ機能を持っています)

やってみます。

先ほどのdevelop2ブランチの修正を、masterブランチにマージしてみます。流れは以下の通り:

- WEB上で、develop2ブランチからmasterブランチへ、プルリクエストを投げてみます
- WEB上で、そのプルリクエストを承認します。
- サーバ上でdevelop2ブランチの内容がmasterブランチに反映されたことを確認します
- SourceTree上でフェッチして、更新があることを確認し、プルで取り込みます。
- ローカルリポジトリのmasterブランチに、develop2での修正が取り込まれていることを確認します。

WEBを開いて、上部の「Pull Requests」をクリックします。
![p001](https://imgur.com/aWX4W9L.png)

プルリクエストの一覧画面が(0件ですが)表示されるので「New pull request」をクリック。
![p002](https://imgur.com/lsQ98G3.png)

プルリクエストですが、今回は「**develop2  "から"  master "へ" マージ**」したいので、下記のように「base: master」「compare: develop2」と設定します。
![p003](https://imgur.com/gF9S1mZ.png)

画面の下部にコードの比較画面が現れました。master と develop2の差分がずらっと表示されています(といっても今回は``sample.txt``だけですが。)。またプルダウン右に「Able to merge」と出ていますが、**競合が発生しなかったので自動でマージできますよ**、といった意味ですね。

Create pull request をクリックすると、下記の通りコメントを記載する画面が表示されるので、コメントを入力し「Create pull request」をクリックします。
![p004](https://imgur.com/JjgozON.png)

プルリクエストを投げることができたようですね。
![p005](https://imgur.com/wfFjQ6e.png)

このまま「Merge pull request」をクリックして承認するので構わないのですが、せっかくなので最初から。

上部の Pull request リンクに小さく「1」と付いて、プルリクエストが出ていることが分かります。それをクリックします。
![p006](https://imgur.com/yFyDhQZ.png)

プルリクエストの一覧が表示されるので、該当するリクエストをクリック。
![p007](https://imgur.com/lqufCiC.png)

先ほどとおなじ画面が表示されるので 「Merge pull request」 をクリック。
![p008](https://imgur.com/CyLtLuW.png)

マージを承認する場合は「Confirm merge」、拒否する場合は下にコメントを入れて「Close pull request」とします。今回は「Confirm merge」をクリックします。
![p009](https://imgur.com/heRNFnj.png)

マージが完了しました。develop2ブランチはマージされたので、もう削除してもOKです。「Delete branch」をクリックすることでブランチの削除ができます(今回はそのままにしておきました)。
![p010](https://imgur.com/QJ9WS77.png)

さて、サーバリポジトリ上でのマージが完了しました。マージは「**マージするコミットが行われた**」ということなので、マージされたmasterブランチは、そのぶんのコミットがされているはずです。ローカルのリポジトリに**サーバリポジトリの更新分を取り込むのは「フェッチ&プル」**でした。フェッチ&プルで、masterブランチのコミットが進んでいることを確認しましょう。

SourceTreeをひらいて「フェッチ」をクリック。
![p011](https://imgur.com/TEKGytr.png)

結果を見てみると、、
![p012](https://imgur.com/mo9WXnv.png)

サーバリポジトリのmasterブランチの状態をあらわす **origin/master が「Merge pull request ... from develop2」というコメントが付いたコミットが行われて、他のブランチよりも進んで**います。またそのコミットには、develop2 が取り込まれた線(？)が付いているのが分かります。develop2の内容が取り込まれているってことですね。
![p012_](https://imgur.com/G3GBD5W.png)

最後に**「チェックアウト(左のmasterのダブルクリックでしたね)」でmasterブランチに切り替え**た後「プル」で取り込んで、下記の通りローカルのmasterブランチへの反映が完了です。
![p013](https://imgur.com/SU4v4wZ.png)

プルリクエストによる他のブランチのマージが完了しました。おつかれさまでした。

## まとめ

- GitHubをつかえる状態にしました。
- SourceTree上で、GitHubを操作して**クローン、コミット、プッシュ、フェッチ、プル**できることを学びました。
- masterとは別のブランチを作成して、**複数バージョンのコードを管理できる**ことを学びました
- 別のブランチの修正を**プルリクエストによってmasterにマージ**できることを学びました。

おなじブランチ上で、先にコミット&プッシュがされた場合、コミットの競合が発生するのですが、その対処法については割愛しました( 対処法としてはrebaseする、mergeする、そもそも競合が起きないようにbranchで開発してあとでmergeする、などなど)。

ほかにもいくつかTIPSがありますが、またの機会に。
以上、おつかれさまでしたー。


## RPA/UiPath界隈のヒト向け

ワークフローのバージョン管理にGit/GitHub はいかがでしょうか。
Gitなどのバージョン管理ツールがないと、フォルダごと日付をつけてコピペするとかになると思いますが、Gitを使うことでカッチリとバージョン管理ができます。
最近のUiPath StudioではGitのサポートも充実してきました。UiPath Studioがあれば SourceTreeなどを使う機会はないかもしれませんが、よろしければGit/GitHubの使い方入門として読んでみてください。


## 関連リンク

- [サル先生のGit入門](https://backlog.com/ja/git-tutorial/)
- [デザイナのためのGit入門](https://www.slideshare.net/dsuket/git-16343460)
- [こわくない Git](https://www.slideshare.net/kotas/git-15276118)
- [GitHub/ローカル・リモートブランチとoriginのはなし](https://www.masatom.in/pukiwiki/GitHub/%A5%ED%A1%BC%A5%AB%A5%EB%A1%A6%A5%EA%A5%E2%A1%BC%A5%C8%A5%D6%A5%E9%A5%F3%A5%C1%A4%C8origin%A4%CE%A4%CF%A4%CA%A4%B7/)
- [Git の仕組み (1) - こせきの技術日記](https://koseki.hatenablog.com/entry/2014/04/22/inside-git-1)