この記事はこれから初めての個人開発を行う方に向けたものです。環境はDebian系のLinuxOS(Ubuntuとか)を想定しています。
Gitの必要性や用語を細かく説明するので、適宜飛ばし読みしてください！
開発に必要な「バージョン管理」
プログラム開発を行う中で、何かを制作して「はいおわり」ということはほぼありません。必ずといっていいほどバグは存在し、バグとは行かないまでも修正点というものは残っています。時代にそぐわない機能やアルゴリズムが使われていたならば、大幅に改修を行う必要があるでしょう。その証拠（？）に、広く利用されているOSでさえ、頻繁にバージョンの更新が行われています。
バージョン更新を行う際、更新の意図、つまりは「何を何故どのように修正したか」を明確にする必要があります。これは、ある程度制作物が出来上がる以前にも同じことが言えます。制作過程で「変更の記録」を行うことで、次に作業に取り掛かる際の手引きになるでしょう。
そうした取り組みをサポートしてくれるツールとして、GitやGitHubというものがあります。
GitとGitHub
チームだろうと個人だろうと、究極的には開発の流れは次の二つの工程のループです。
①コード、ファイルを変更（追加・編集・削除）する
②行った変更を記録する
Gitを利用することで、変更の記録が用意になるだけでなく、後から変更の履歴を見ることもできます。
Gitはあくまでローカル環境でのバージョン管理ですので、異なる端末間で利用できなかったり、行った更新を他者に伝えることが難しいという問題があります。そこで、GitHubを用いて、クラウド上にソースコードと変更記録をアップして、Gitの環境をクラウド上に反映するという手法を取ります。クラウド上でバージョン管理できれば、ソースを別の端末でダウンロードして編集したり、他者と共有することも可能になりますね。
プライベート（非公開設定）も簡単にできますので、インターネット上にアップすることに不安を抱えている方もご安心を！
実はgitには変更の記録のほかにも「リポジトリ」などといった開発をサポートするための様々な概念・機能が存在しています。次は、その「リポジトリ」について説明します。
リポジトリ
Gitを扱う上で重要なのは「リポジトリ」という概念です。リポジトリというのはざっくり言いますと、目的ごとに分けたプロジェクトのコピーの集合体です。そしてそのコピー達を「ブランチ」といいます。分かりづらいと思うので、大きく二つのパターンに分けて図で考えていきます。
パターン① リリース環境と開発環境の二つに分ける
ブランチを作成することで、そのブランチのみに変更を加えることができます。この画像の場合ですと、リリース用のmasterブランチに触れずに開発用のdevelopブランチを編集できます。「developブランチのプロジェクトでじっくり開発を行って、ある程度形になったときにmasterブランチに反映させる。」ということができます。ちなみに個人開発の場合はこの形式をとっているという方も多いと思います。
パターン② 開発環境を更に機能ごとの実装環境に分ける
例えば次のようなプロジェクトがあったとします。
あえてチーム開発を前提として考えますが、画像のような場合、1人1アプリケーションを担当すれば楽そうです。ですが、同じプロジェクトファイル内で開発するのは非効率ですよね。というわけで、↓のように、developブランチを更に分け、機能ごとに開発していきます。
featureブランチでの作業で機能の実装を終えたら、developブランチに反映・・・という感じ。これで、より細やかな開発が実現できています。変更の記録も、具体的にどこに修正を加えたのか見やすいですよね。
ブランチの意義
あえてはじめにブランチの意義を説明しませんでしたが、ここまで読み進めていただいたならばそれもあながちわかってきていると思います。単純に作業を分割できて便利ですし、細かく分ければ編集履歴が見やすくなります！（細かすぎるのも問題ですが・・・）
さらに、GitHubを使ってクラウドで管理することで、アプリケーションの統合作業も容易になることでしょう！
リポジトリの場所
最初のほうの説明で、ローカル環境でのバージョン管理をGitで行い、それをGitHubを利用してクラウド上に反映するという旨の文章を書きました。すなわち、リポジトリは「ローカル環境」と「クラウド環境」に存在しています。それぞれを「ローカルリポジトリ」、「リモートリポジトリ」といいます。
加えてもう一つ単語を覚えましょう。念仏のように唱えている「変更の記録」ですが、これを「コミット」といいます。
まとめて図解してみます。
まずローカル環境の作業ブランチにて行った作業（加えた変更）をローカルリポジトリにコミットし、それをリモートリポジトリに反映させる。これがリポジトリとブランチを扱う上での超基礎手順となります。
ではGitの基礎の基礎を理解したところで、実際に扱ってみます。
Gitで個人開発
では実際にGit、GitHubを利用してみましょう。
ちなみにGitHubのアカウント作成に関しては、@okumurakengo様の【2019年1月現在】GitHubアカウント作成方法、Gitの導入に関してはGitのインストールあたりが参考になるかと思います！
リポジトリの作成
ログイン状態で左上のねこちゃんマークを押すとこの画面に来るので、そこでNewをクリック。
↓のような画面に遷移すると思います。
・Repository name：リポジトリの名前です。制作するプロジェクトのタイトルでもあるので、慎重に決めましょう。
・Description：このプロジェクトについての説明を記入できます。
・Public or Private：大抵はPrivate(非公開)でいいかと思います。お金もかかりません。もちろん公開したい場合はPublicを選択すればできます。
・Initialize this repository with a README：README（解説メモみたいなもの）を作るかどうか決めます。後でも作れるのでチェックを入れなくてもOKです
これらを入力し終えたら「Create repository」でリポジトリを作成できます。
さて、いろいろ出てきましたが、↓の部分に注目しましょう。
ここには、ローカル環境でのリポジトリ作成からリモートリポジトリの更新までの手続きが記述されています。とはいえ準備作業が必要ですのでやっていきます。
ローカルリポジトリの作成
Gitをinstallしていない方はinstall。
$ apt-get install git
↑の画像に書かれている「git init」コマンドでローカルリポジトリを作成できるのですが、現在のディレクトリがローカルリポジトリとなってしまうため、ローカルリポジトリ用のディレクトリを作ることを強く推奨します。
$ mkdir PersonalWork
$ cd PersonalWork
↑のチュートリアル？的なものでは、初めての制作ファイルとしてREADMEを作っていますが、なんでもいいです。
$ echo "print('banana chips')" >> banana.py
ではローカルリポジトリを作成しましょう。
$ git init
Initialized empty Git repository in ~/PersonalWork/.git/ #一部省略
コマンドラインを確認すると、$マークの後ろに(master)と書かれていると思います。（位置は環境依存）これは、現在作業中のブランチを示しています。
ローカルリポジトリに変更を加え、記録する（add, commit）
次に、「git add」コマンドで、「これを変更（作成、編集、削除）」しました！ということを宣言します。詳しく言うと、「コミットの対象」を指定します。
(master) $ git add banana.py
ちなみに、以下のようにすると、まとめてaddできます。
(master) $ git add .
ではaddした対象をローカルリポジトリにコミットしてみましょう！
(master) $ git commit -m "Create banana.py"
-mオプションで、最後の文のような「コミットメッセージ」を書くことができます！このコミットメッセージに、変更内容を記しますので、しっかりと書くようにしましょう。
変更をリモートリポジトリに送信する(push)
ローカルリポジトリに対する作業は終えたので、接続するリモートリポジトリの設定作業を行います。これはあくまで設定作業ですので、毎回やる必要はありません。
(master) $ git remote add origin https://github.com/<userID>/PersonalWork.git
ここでIDとパスワードを求められると思います。GitHubのIDとパスワードを入力しましょう。
・remote add：利用するリモートリポジトリを設定するコマンド
・origin：リモートリポジトリのデフォルト名、変更可。毎回URLの指定をするのは面倒ですから、ニックネームを付けちゃおうということです。
・最後のURL：利用するリモートリポジトリのURL
詳しくは、こちらの「リモートリポジトリの追加」の項に書かれています。
利用するリモートリポジトリは決定しましたので、先ほどコミットした内容をリモートリポジトリに反映させていきましょう。
(master) $ git push origin master
このコマンドによって、リモートリポジトリ（origin）に、masterブランチの内容がpush(送信)されました。
ではリモートリポジトリをGitHubで確認してみましょう。
↑の画像のようにできていたならば、初めてのcommit&pushは完了です！
さて、もし異なる端末間で共通のリモートリポジトリを使っていた場合、今行った作業の逆、すなわち「リモートリポジトリの内容をローカルリポジトリに送信・反映」する作業が必要になりますよね。その場合も考えていきましょう。
リモートリポジトリの変更を受信する(pull)
GitHubのリポジトリページで、「Create new file」をクリックして、リモートリポジトリ上に新しいファイルを作っていきます。
以下のコマンドで、リモートリポジトリにおける変更を、ローカルリポジトリに反映することができます。
(master) $ git pull origin master
(master) $ ls # 変更を確認
apple.py banana.py
ローカルとリモート、それぞれのリポジトリ間のやりとりはこれでだいたいおっけーです。
他にもリポジトリに関する多くのコマンドが存在し、チーム開発の現場では頻用されますが、初心者が覚えることについてはこれで十分だと思います。
ブランチの作成と移動（branch, checkout）
masterブランチばかり使っていてはせっかくのバージョン管理が煩雑になりますから、開発用のブランチを作成して、そちらで作業を行うようにしてみましょう。
まず、ローカルリポジトリ内に新しいブランチを作成します。これを「ブランチを切る」というそうです。
(master) $ git branch develop
developと書いたところには、作成するブランチ名を入れます。
作成したブランチを確認します。
(master) $ git branch
develop
* master
気づくと思いますが、*マークがついているブランチが、現在いるブランチです。
次に、作成したブランチに移動します。
(master) $ git checkout develop
(develop) $ git branch
* develop
master
()の中身が変わって、ブランチを確認するとdevelopに*マークがついていますね。これで移動は完了しています。
ちなみに、以下のようにするとbranchとcheckoutをいっぺんに実行できます。
(master) $ git checkout -b develop
さて、新しいブランチを作成し、そのブランチに移動できました。早速開発用のブランチに何かつくって、リモートリポジトリに反映させてみましょう。
(develop) $ touch niku.py
(develop) $ ls
apple.py banana.py niku.py
やり方は覚えていますでしょうか？？？addしてcommitしてpush！
(develop) $ git add niku.py
(develop) $ git commit -m "create niku.py"
(develop) $ git push origin develop
GitHubで反映されているか確認してみます！
あれ！？！？！？！？？と動揺することはありません。
「Branch:master」の部分をクリックして、ブランチ一覧をみると、「develop」が追加されているかと思います。
確認してみましょう。
先ほどcommit&pushした内容が反映されているかと思います！
ここまでの作業をまとめると、下図のようになります。
忙しい人向け
あなたが作業を始める前にすること
$ git pull origin <ブランチ名>
あなたが作業を終えた後にすること
$ git add <変更を加えた対象>
$ git commit -m "do"
$ git push origin <ブランチ名>
作ったローカルリポジトリをリモートリポジトリとリンクさせたい
$ git init #ローカルリポジトリを作っている場合は必要無し
$ git remote add origin <リモートリポジトリのURL>
新しい作業用ブランチを作ってリモートリポジトリに反映したい
$ git checkout -b <作成するブランチ名>
$ git push origin <作成したブランチ名>
# ファイルを作った場合は、適宜add,commit,pushしてください！
まとめ
以上で、GitやGitHubについて、最小限の取り扱いが可能になったかと思います。他にもmergeとか、困ったときのコマンド集など調べてみるといろいろあるみたいなので頑張りましょう～～～～～！
筆者も初級者なので、間違っている部分があれば教えてください＞＜！