visual studio Codeを起動

を押す。（このアイコンがバージョン管理システムの管理ツール）

変更したファイルが↓画像の赤枠部分に表示されます。

管理対象フォルダにファイルを追加した例

＋を押して、ステージに乗せる

＋で追加したtest.htmlがSTAGED CHANGESに入った。

チェックマークをクリックしてコミット。

テキスト入力粋が表示されるので、コミットメッセージを記述してエンターキーを押す。

「・・・」を押すと、メニューが出てきます。PullとPushを行います。

前置き

新しい環境でSourceTreeを使うとき、毎回パスワードを聞かれるのを止めるのどうやるんだっけ・・・となるので、それを解決するためのまとめになります。

やりたいこと

SourceTreeでクローンやフェッチをすると毎回パスワードを聞かれるのを止めたい。

前提条件

• SourceTreeでGitHubを使う
• GitHubの2段階認証を有効にしている
• GitHubが推奨しているHttpsを使いたい
• GitHubのアクセストークンは発行済み状態

環境

• macOS Mojave 10.14.4
• SourceTree 3.2.1

手順

基本的な手順はGitHub公式に載っています。
https://help.github.com/en/articles/caching-your-github-password-in-git

ざっくり言えば、キーチェーンにパスワードを保存する設定に変えれば良いとのことです。

「Xcode Command Line Tools」のインストール

「Xcode Command Line Tools」が入ってない場合はインストールします。
ダウンロードは https://developer.apple.com/download/more/ からできます。AppleIDが必要です。

$ git credential-osxkeychain

のコマンドが通ることを確認します。

キーチェーンに保存する設定

以下のコマンドを叩きます。成功しても特に何か表示されることはありません。

git config --global credential.helper osxkeychain

SourceTreeでクローンする

アカウントの環境設定

SourceTreeの環境設定を開き、アカウントタブを選択します。
以下の設定内容でアカウントを追加します。

ホスト：GitHub
認証タイプ：Basic
ユーザー名：適当でもいいみたい（？）
パスワード：GitHubのアクセストークンを入力
プロトコル：HTTPS

クローンする

初回クローンするときに、キーチェーンにアクセスするためのログインパスワードを聞かれるので入力します。（パスワード無しなら聞かれないと思います）
これでパスワードがキーチェーンに保存されるので、クローンやフェッチをしてもパスワードは聞かれなくなります。

…それでもまだパスワードを聞かれる場合

キーチェーンやSourceTreeに正しくないパスワードが保存されている場合があるようです。
この場合、正しいパスワードを入力しても変更されないみたいです。
そのため、キーチェーンアクセスから "github" を削除したり、SourceTreeのアカウントを一度削除してから、↑の手順を行えば解決しました。

参考URL

https://stackoverflow.com/questions/38489022/sourcetree-keeps-asking-for-github-password
https://stackoverflow.com/questions/11067818/how-do-you-reset-the-stored-credentials-in-git-credential-osxkeychain

PullRequestとMergeの話

登場人物A, B。

Aが適当なフォルダをGitで管理し、GitHubへ公開。
Bがclone。
AはBへのpush権限を振る。ただ、mergeはAしか出来ない様にする。
Bがmasterブランチのままファイルを変更。コミットする。
もちろん、Bはmasterへpushできない。(※1)
ただ、この状態でdevelopブランチをBが作って、移動する。
そのdevelopブランチでもファイル変更・コミットをする。
Bはmaster以外のブランチは作れるし、push出来るので、pushは成功した。
Bは続けて、develop->masterのmergeをPullRequestとして申請。
Aが受諾。

この時、面白いのが、Bの※1のコミットは、pushできなかったが、
PullRequestの受諾によって、developブランチ経由で、masterにも、※1のコミットが記録される。

Git(Github含む)でのあれこれのメモです。

• Githubリポジトリにtagの追加/削除を行いたい

Githubリポジトリにtagの追加/削除を行いたい

// 追加
$ git tag {tag_name}
$ git push origin {tag_name}

// コミット指定
$ git tag {tag_name} {commit_hash}

// 削除
$ git tag -d {tag_name}
$ git push origin :{tag_name}

// ローカルのタグリスト
$ git tag -l

// タグを打ったコミットを確認
$ git show {commit_id}

// リモートのタグリスト(commitID含む)
$ git ls-remote --tags

参考

https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E3%82%BF%E3%82%B0
https://stackoverflow.com/questions/25984310/how-to-see-remote-tags

序文

gitに対してエイリアス貼っていましたが

alias g='git'

g checkoutまで記述した後に「ブランチ名」の補完(オートコンプリート)が聞いていたのに、gitのバージョン更新したあたりから効かなくなってしまった。

結果

vim ~/.bash_profile
これまでは、この記述だけで補完できていたのに

source /usr/local/etc/bash_completion.d/git-prompt.sh
source /usr/local/etc/bash_completion.d/git-completion.bash

補完効かなくなったので
よくよく調べたら関数の実行まで必要みたいだったので記載したら無事に補完されるようになった。

source /usr/local/etc/bash_completion.d/git-prompt.sh
source /usr/local/etc/bash_completion.d/git-completion.bash
__git_complete g __git_main

Jenkinsでデプロイした際に・・・
Gitのマージエラーなどで１回ビルド失敗した後、再度ビルドすると
「ビルド成功した！・・・あれ、ソース反映されてない？」
ってことがたまにあるかと思います。

そういうときはデプロイ先のサーバにログインし、
以下のgitコマンドを打ちます

git checkout -f

作業ツリーやインデックスの変更やもろもろ残ってたとしても
全て破棄して強制チェックアウトする！！！
というおまじないを使ったあとに、再度ビルドするときちんと反映されます

Git初心者が最低限覚えるべきだと思ったこと

gitを使っていく中で、最低限必要だと思った知識をまとめてみました。

そもそもGitとは

プログラムソースなどの変更履歴を管理するバージョン管理システム。
簡単に言うと、複数人で作業するときに使うとても便利なもの。

• 他人の作業が可視化される
• 分担して作業がしやすい

Gitの事前知識

• リポジトリ･･･貯蔵庫（ファイルやディレクトリの状態を保存する場所）
• ローカルリポジトリ･･･自分のところに作られるリポジトリ
• リモートリポジトリ･･･ネットワーク上に存在する自分以外のリポジトリで複数人でも管理することができる
• ブランチ･･･複数の作業を並行して行うために分岐して履歴の流れを記録していく
• コミット･･･変更を記録すること
• プルリクエスト･･･自分がした変更をリポジトリに取り込んでもらうように要求すること
• ワーキングツリー･･･作業中の場所
• インデックス･･･コミットの対象となるファイル等を置く場所（ステージともいう）

作業の流れ

1. Git用のディレクトリを作成
   リモートリポジトリが存在しない場合は2.へ
   リモートリポジトリが存在する場合は3.へ
2. git init
   gitリポジトリにする
3. git clone
   リモートリポジトリの内容を自分のマシンに複製する
4. git branch
   ブランチをすべて表示する
   ＊が付いているブランチが自分がいるブランチ
5. git branch 好きなブランチ名
   好きなブランチ名でブランチが生成できる
   ※作業する内容に即したブランチ名にする！
6. git branch
   ブランチができたか確認する
7. git checkout これから作業するブランチ名
   ブランチの切り替えをする
8. git branch
   ブランチの切り替えができたか確認する
9. 作業する
10. git status
    変更状態を見る
    赤色がワーキングツリーにあるもの
    - modified...修正したファイル
    - deleted...削除したファイル
    - Untracked files...新規作成したファイル
11. git diff
    変更したファイルのソースコードを確認
12. git add ファイル名
    選択したファイルをインデックス（ステージ・エリア）に上げる
13. git status
    変更状態を見る
    緑色で表示されていればインデックスに上がっている
14. git commit -m "メッセージ"
    追加・変更したファイルをローカルリポジトリに登録する
15. git log
    作業ブランチの履歴を見る
16. git push origin 作業したブランチ名
    リモートリポジトリに変更を反映する
17. Githubのページを開いてプルリクエストを出す

また作業をしたい時

1. git checkout master
2. git pull origin master
   リモートリポジトリの内容をローカルリポジトリに取り込む
3. 作業の流れの3.から始める

Gitのマージ

忘れやすいのでメモ

名称	内容
BASE	共通先祖の内容、3wayの時はここにマージ結果を格納する?
LOCAL	手元つまりマージ前の現ブランチでの内容、2wayの時はここにマージ結果を格納する?
REMOTE	マージ相手のブランチの内容

3-way mergeになるのは、共通先祖があるとき(普通はある)

履歴の連続性のないマージや、元が別のファイルなのにrenameで同じになったなどでのコンフリクトからのマージの発生などでは3wayは適切じゃないらしい(最近のvimdiffはよしなにそれらを処理できるとのこと)

winmergeの3wayも一応できてるかな?

...今のgitのwinmergeのデフォルトだと、3wayマージ設定を生かせないらしく、ちょっと酷いことになる。
各種の3way設定をちゃんと設定しないとだめ¹

---

1. Git で WinMerge するときの設定+α - Qiita の設定はOK、-t winmerge だとREMOTEにコンフリクトした現ファイルが入ってしまう(2way/3wayどちらの条件でも) ↩

TR;DR

git log --date=<format>
git show --date=<format>
git branch --format='%(authordate:<format>)'

の<format>部分を調べた際に、探すのに時間かかってしまったのでメモ

ドキュメント

git branchのドキュメントの--format見ると、git-for-each-refと同じって書いてある

--format
A string that interpolates %(fieldname) from a branch ref being shown and the object it points at. The format is the same as that of git-for-each-ref[1].

git-for-each-refのドキュメント見ると、日付の形式はgit-rev-listを見てねって書いてある

As a special case for the date-type fields, you may specify a format for the date by adding : followed by date format name (see the values the --date option to git-rev-list[1] takes).

git rev-listのドキュメントにやっと書いてあった

ただし、独自の形式にする場合は
--date=format:...はシステムのstrftimeに送るからパラメータはそっち見てねってあるので

strftime を見ないといけない

サンプル書式

$ git branch --format='%(authordate)'
Tue Aug 27 19:34:50 2019 +0900

$ git branch --format='%(authordate:relative)'
16 hours ago

$ git branch --format='%(authordate:local)'
Tue Aug 27 19:34:50 2019

$ git branch --format='%(authordate:iso)'
2019-08-27 19:34:50 +0900

$ git branch --format='%(authordate:iso-strict)'
2019-08-27T19:34:50+09:00

$ git branch --format='%(authordate:rfc)'
Tue, 27 Aug 2019 19:34:50 +0900

$ git branch --format='%(authordate:rfc2822)'
Tue, 27 Aug 2019 19:34:50 +0900

$ git branch --format='%(authordate:short)'
2019-08-27

$ git branch --format='%(authordate:raw)'
1566902090 +0900

$ git branch --format='%(authordate:unix)'
1566902090

$ git branch --format='%(authordate:default)'
Tue Aug 27 19:34:50 2019 +0900

独自フォーマット

$ git branch --format='%(authordate:format-local:%Y-%m-%d %H:%M:%S)'
2019-08-27 19:34:50

:humanは使えなかった

$ git --version
git version 2.17.1

$ git branch --format='%(authordate:human)'
fatal: unknown date format human

恐らくバージョンによるもので、version 2.21.0 から追加された模様です。
--date=humanについての表記がver 2.20.0にはなく、ver 2.21.0 からはありました。

　はじめに

herokuを使ってデプロイができたので、その方法を記録として残しておく。

　準備

gemfileの設定

Gemfile

# sqlite

sqliteをコメントアウト

Gemfile

group :production do
  gem 'pg'
end

上記コードはgemfile最下部に記載

環境ごとのデータベースの設定変更を行う
開発時にはmysql使用、本番環境(heroku)ではPostgreSQL(pg)を使用
環境にあうように設定

ターミナル

bundle install

config/datebase.ymlの設定

config/database.yml

production:
  <<: *default
  adapter: postgresql  #postgreSQLに接続
  encoding: unicode    #文字コード
  pool: 2              #データベース接続可能上限数

config/environments/production.rbの設定

config/environments/production.rb

  config.assets.compile = true
# falseとなっているのでtrueにする

binフォルダ内の設定

binフォルダ内の各ファイル.rb

    #!/usr/bin/env ruby #ここに記載のバージョンを削除

Git

gitにコミットをしておく

heroku

herokuに登録しておく

会員登録後、
https://devcenter.heroku.com/articles/heroku-cli
上記から個人の使用にマッチするものをダウンロード

ターミナル操作

$heroku login

上記コマンド入力後に下記コマンドが表示されるので適当にキーを叩く

Press any key to open up the browser to login or q to exit:

ターミナル上に上記画像の表示が現れ、自動でブラウザが開かれるのでlog inする

ログイン後、再びターミナルへ

$heroku create アプリ題名

デプロイ

$git push heroku master

デプロイ成功後に下記コマンドの実行

heroku run rails db:migrate

上記コマンド入力後に先程、実行した下記コマンドで表示されるurlにログインすれば、自分の作成したアプリが表示されるはず！！

$heroku create アプリ題名

補足

git push heroku master時にCould not find 'bundler'のエラーが発生しました。

私は色々とググった結果
rubyとbundlerのバージョンをあげることで解決しました。

最後に

コマンドの一覧やデプロイ時のエラー対処方法なども調べてまとめていきたいです。
デプロイは凄い大変なイメージがありましたがherokuでのデプロイは操作が簡単、userのやることが少なくて楽だという印象を受けました。

参考記事

https://qiita.com/amuyikam/items/989300248f471020ca18
https://qiita.com/tktcorporation/items/0ef8c930fc18ce72c301

TL;DR

サーバ側 Windows の ssh ログインシェルを Git bash に変更し、フルパスの前に /mntを付けて clone する。

URLの具体例

git clone ssh://hidao@192.168.0.254/mnt/c/users/hidao/repo/app.git

検証環境

サーバOS: Windows10 Pro 64bit ver. 1903
Git: 2.18.0.windows.1
sshd: OpenSSH_7.7p1, OpenSSL 1.0.2o 27 Mar 2018（アプリと機能のオプション機能で追加したもの）

クライアントOS: Windows10 Home 64bit ver. 1903
Git: 2.19.0.windows.1
ssh: OpenSSH_7.7p1, OpenSSL 1.0.2p 14 Aug 2018（アプリと機能のオプション機能で追加したもの）

特殊な事情

Windows10 のアプリと機能からインストールできる sshd では、デフォルトシェルが cmd.exe です。

ただし、cmd では git clone ssh:// 時に UNIX 形式のパス指定ではリポジトリに到達できないため（原因不明）、ログインシェルを Git bash に変更する回避策を取ります。

また、Git bash はドライブを /mnt の下にマウントしているため、リモートから URL を指定する場合に /mnt の追加が必要になります。

ハマりポイント

1. ssh のログインシェルがデフォルトの cmd.exe では、一般的な URL 表記法ではリポジトリに到達できない。
2. ssh のログインシェルを Git bash に変更すると、Git bash をローカルで使っているときと異なり、フルパスの先頭に /mnt を追加する必要がある。

付録：ssh のログインシェルを Git bash に変更する PowerShell コマンド

下記コマンドを実行し、bash のパスを調べます。

入力

Get-Command bash | Format-Table -AutoSize -Wrap

出力

CommandType Name     Version        Source
----------- ----     -------        ------
Application bash.exe 10.0.18362.239 C:\WINDOWS\system32\bash.exe

次に、出力で得られた Source のパスを含むコマンドを管理者権限で下記要領にて実行します。

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\system32\bash.exe" -PropertyType String -Force

以下のような出力が得られれば、ログインシェルの変更に成功しています。

DefaultShell : C:\WINDOWS\system32\bash.exe
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE
PSChildName  : OpenSSH
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

TL;DR

サーバ側 Windows の ssh ログインシェルを Git bash に変更し、フルパスの前に /mntを付けて clone する。

URLの具体例

git clone ssh://hidao@192.168.0.254/mnt/c/users/hidao/repo/app.git

検証環境

サーバOS: Windows10 Pro 64bit ver. 1903
Git: 2.18.0.windows.1
sshd: OpenSSH_7.7p1, OpenSSL 1.0.2o 27 Mar 2018（アプリと機能のオプション機能で追加したもの）

クライアントOS: Windows10 Home 64bit ver. 1903
Git: 2.19.0.windows.1
ssh: OpenSSH_7.7p1, OpenSSL 1.0.2p 14 Aug 2018（アプリと機能のオプション機能で追加したもの）

特殊な事情

Windows10 のアプリと機能からインストールできる sshd では、デフォルトシェルが cmd.exe です。

ただし、cmd では git clone ssh:// 時に UNIX 形式のパス指定ではリポジトリに到達できないため（原因不明）、ログインシェルを Git bash に変更する回避策を取ります。

また、Git bash はドライブを /mnt の下にマウントしているため、リモートから URL を指定する場合に /mnt の追加が必要になります。

ハマりポイント

1. ssh のログインシェルがデフォルトの cmd.exe では、一般的な URL 表記法ではリポジトリに到達できない。
2. ssh のログインシェルを Git bash に変更すると、Git bash をローカルで使っているときと異なり、フルパスの先頭に /mnt を追加する必要がある。

付録：ssh のログインシェルを Git bash に変更する PowerShell コマンド

下記コマンドを実行し、bash のパスを調べます。

入力

Get-Command bash | Format-Table -AutoSize -Wrap

出力

CommandType Name     Version        Source
----------- ----     -------        ------
Application bash.exe 10.0.18362.239 C:\WINDOWS\system32\bash.exe

次に、出力で得られた Source のパスを含むコマンドを管理者権限で下記要領にて実行します。

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\system32\bash.exe" -PropertyType String -Force

以下のような出力が得られれば、ログインシェルの変更に成功しています。

DefaultShell : C:\WINDOWS\system32\bash.exe
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE
PSChildName  : OpenSSH
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

はじめに

gitを使う最大の利点は、バージョン（履歴のようなもの）管理することによって、（コミットした）過去のどこへでも戻ることができることではないでしょうか？
この仕組みがあることで、安心して開発を進めることができますよね。

そこで、タイムマシーンに乗って、過去にタイムトラベルするスーパー安全な方法をスーパーシンプルにまとめます。

注：この記事は、MacのTime machine とは一切関係ありません。

３ステップ

gitで過去の状態に戻りたい場面には主に次の二つがあると思います。

1. プログラムに不具合が出たため、過去のある状態に戻ってリスタートしたい
2. ただ単に過去のある状態を確認するためだけに戻りたい（確認後、現在の状態に戻ってくる）

1 の場合は、git reset --hardで乱暴に戻っても問題ないですが、2 の場合は、それでは少々乱暴（危険）なので、違うコマンドを使うことでかなり安全に作業できます。この記事では、2 の、単に確認のために過去に戻りたい場合の対処法を示します。

前提として、過去へ戻る前は、masterブランチにいるとします。

1. コミット履歴を確認する

git reflogを使うと、HEADの移動履歴を確認できます。git logでは、commit履歴のみ表示しますが、git flogでは、commitに加えて、checkout、pull、reset、rebaseなどの履歴（つまりは、HEADの移動履歴）も表示することができます。

❯ git reflog
.
.
8827928 (origin/develop) HEAD@{43}: pull origin master: Fast-forward
8281683 HEAD@{44}: checkout: moving from master to develop
306e3db HEAD@{45}: pull origin master: Fast-forward
3369a69 HEAD@{46}: commit: fix typo
f00081c HEAD@{47}: commit: create README.md
9c898f1 HEAD@{48}: commit: third commit
d2fafdb HEAD@{49}: commit: second commit
eddfbf5 HEAD@{50}: commit: fist commit

2. 目的の移動ポイントを指定してgo back!

では、移動したい箇所（ハッシュ値）を指定して、過去に戻りましょう。
下記のようにgit checkout ハッシュ値、あるいは、git checkout HEAD@{46}のようにHEADを指定すると、過去にgo back! することができます。

❯ git checkout 3369a69

3. 確認が済んだら現在にgo back!

masterプランチに戻りましょう。

❯ git checkout master

おわり。

プロローグ

データサイエンスをやると、必ず耳にするのがkaggleという、世界中のデータサイエンティストがしのぎを削って予測精度を競うデータサイエンスの競技会コミュニティです。
kaggleは日本でどんどん知られるようになり、参加するためのハードルはどんどん下がってはいるものの、エンジニアのバックグラウンドがないと競争力を高めにくいところがいまだに多くあります。その一つがgithub(gitのウェブサービスの一つ)です。

この記事を通して、kaggleで競争力を上げるため条件の一つである試行錯誤のサイクル加速をするためのツール、githubの活用に焦点を当てます。githubでできる事、できないこと、とりあえず使えるようにするために最低限必要な前提をかいつまんでご紹介します。ある意味自分の備忘と学びの記録としても作っているため、網羅性と体系だった整理については担保できませんが、自分と同じようにエンジニアのバックグラウンドでない人がkaggleに参加するときに、githubをうまく活用するための助けになればよいと思います。

なぜkaggleでGithubを使うか、その前提

コンペを進める中で様々な試行錯誤をしながら、常に再現性を担保しなければなりません。そこで重要なのが、計算をさせる為のPython、jupyter notebook、Rなどのコードのバージョン管理です。それを便利に実現してくれるのがgithubです。

gitの概要

githubの前に、おおもとのgitの概念についてです。「gitとは」で検索すればいくらでも情報は出ますが、簡単に説明します。gitはlinuxの開発者がチームで開発をするときに、メンバー間でプログラムソースコードのバージョン管理に使用された分散型の管理システムです。githubはそのような管理システムのウェブサービスの一つです。法人向けにはgitlabなどがあります。

便利なところ

-当たり前ですが、いちいちファイル名を変えるなどせずにバージョン管理がしやすい。
-コードの使いまわしがやりやすくなるので、新たな開発プロジェクトに着手しやすい。
-githubを使うと、いつでもどこでも自分・他人のプログラムコードを参照・共有できる。

不便なところ

-ちょっとしたコマンドが必要。
-clone, pull, push, branch, fetchなどいろいろ門外漢にはなじめない概念があり、且つそれらが平易な言葉で説明されていない。（エンジニアにはわかるかもしれないが…）
-git, github, gitbucketといろいろあり、ローカルで使用する場合、クラウド上のインスタンスで使用する場合と様々なシチュエーションがあるためまとまった情報源がない。

githubでよく使う言葉

色々言葉はありますが、私はとりあえず下の3つの重要な概念さえわかればkaggleではなんとかなると思います。あとは必要に応じて調べればいいです。

clone

言葉の通り、クローンすることで、他人が開発した環境やディレクトリ群をそのまま自分の環境にダウンロードして持ってくることです。

commit

バージョンを変えたとき、gitに「変更したよ」と宣言するときに使います。commitをしないとバージョン変更が認識されないです。ゲームでいう所の「セーブ」の事です。

push

githubでは、ローカルで開発し、マスターをウェブ上の「リモート」と言われるところで管理します。変更をcommitによって宣言しただけではリモートでは変更は反映されません。変更したことをリモートに伝える事がpushです。ここで重要なのが、この時にローカルからリモートへのデータ転送が生じることです。転送するファイルサイズが100MBを超えるとエラーになります。また、グラフやログが記録されているjupyter notebookのipynbファイルはサイズが大きいとgithubのウェブページで見る時に重くて何回リフレッシュしても見られないことも発生しうるので要注意です。

とりあえず使えるようになるには

githubを例に、ローカルの環境をgitで管理できるようにするまでを見てみます。

$ mk dir directory_name　#gitで管理したいディレクトリを作る

#github上でレポジトリを新規作成する

$ echo "kaggle_starter" >> README.md　
#空のディレクトリでは認識されないので、
#READMEファイルを作成します。

#後述するが、無駄にファイルを作りたくない時は以下でも可。
#echo -n > .gitkeep

$ git init 
#ディレクトリをgitで認識させる範囲として初期化します。
#ですので、この階層より上の階層ではgitのコマンドは認識範囲外なので反応しません。

$ git add README.md　
#ファイル管理する為には管理対象として追加する必要があります。

$ git add -A 
#管理範囲内全ての管理対象をcommitの対象に追加するときに使用します。

$ git commit -m "first commit" 
#ディレクトリ内の変化を一回セーブすることをgit用語でコミットと言います。
#コメントを付け加えることもできます。

$ git remote add origin https://github.com/[アカウント名]/[レポジトリー名].git 
#ウェブ上のgithubにローカルの変化を反映させます。
#SSH設定していない場合は、このあとgithubのアカウント名とパスワードの入力が求められます。

あとは、コードのバージョン変更を反映させたい度に、以下をおまじないのように使えばよいです。

$ cd {gitで管理対象になっているディレクトリ}
$ git add -A
$ git commit -m "何かしら変更に関するコメント"
$ git push -u origin master

gitはファイルしか管理してくれない

とりあえずgithubを使ってファイルのバージョン管理をするようになり、使い始めて数カ月でやっとわかったことです。githubは何ができるかはいくらでも情報があったのですが、これは結構初めに言ってほしかったことです。github(というかgit)ではファイルのない空のディレクトリは管理してくれないのです。
それまで、フォルダを切ってディレクトリを作成して、ソースコードを配置していたので、特に問題にならなかったのですが、何回かコンペに参加するうちに、共通するフォルダ構造をあらかじめ整理して使いまわせるしようと思いました。
そこでまだソースコードを配置していない、空のフォルダ構成だけがあるディレクトリをpushしようとしていました。結果は変化はなく、更新がリモートつまりgithub上のレポジトリに反映されず、エラーメッセージで調べてもcommitしていないから、addしてないからという当たり前の事しか出てこなかったのです。

このようなときは、「.gitignore」というファイルで、githubで管理したいファイル、管理したくないファイルを定義したものを配置する必要があります。例えば、ファイルサイズが大きく、バージョン管理する必要がない、インプットデータや処理済みデータがあるinputやoutputのフォルダにあるファイルは全て無視し、逆にまだファイルがないがフォルダとして認識させたいものがあるときの.gitignoreのファイルの中身は以下のようになります。

/input/*
/output/*
/submission/*
!.gitkeep

「!.gitkeep」は「.gitkeep」というファイルは無視しないということですので、「.gitkeep」というファイルを空のフォルダに配置すればgitが認識してくれます。認識させたいフォルダのディレクトリで、echo -n > .gitkeepとコマンドを打てばファイルが作成されます。
なお、.gitignoreファイルをコマンドラインで作成するとき以下のようにすればよいです。

$ vi .gitignore #viエディダで.gitignoreファイルを開く
##以下はエディダ内での編集##
i #「i」と打って、insert mode　にして編集する
/output/*
/submission/*
!.gitkeep
## 「Esc」+ 「:」 + 「wq」とキーを入力して上書き保存する

最後に

kaggleに参戦するにあたってgithubを使った方がよい理由、良し悪し、そして重要な前提について簡単に紹介しました。
手軽なバージョン管理による便利なコードの使いまわしで、試行錯誤や開発サイクルを早め、いつでもどこでも、自他ともに活用できるのがgithubの良さです。
他人のリモートにある環境をcloneでそのまま持ってきて、ローカルで開発し、変更をセーブしたいときはcommitした上で、リモートに反映するためにpushします。
また、githubには管理したいディレクトリの中でしか機能せず、ファイルしか認識しないため、空のフォルダは認識しません。そのため、.gitignoreや.gitkeepなどを作成するなど工夫が必要です。
以上を意識してgithubを使いこなしていきましょう！