gitで、.jsを.tsに一括で置換したいときは以下のスクリプトでいけます。置換元ファイルを絞り込みたい場合は、適宜1行目のfindコマンドを書き換えます。

for i in $(find . -iname "*.js"); do
  git mv "$i" "$(echo $i | rev | cut -d '.' -f 2- | rev).ts";
done

以下を参照。

Git: Rename or move all files at once
https://stackoverflow.com/questions/9151920/git-rename-or-move-all-files-at-once/9151943#9151943

こんにちは！！
アロハな男、やすのりです

今回は、GitとGitHubについて学んだので、自分で忘れない様にという意味も込めて使い方を簡潔に纏めていこうかなと思います！！

GitHubって何？

そもそもGitHubって何なの？よくエンジニアの人が使ってるらしいけど？？
わけわかめ

って感じでしたが、簡潔に書くと
『自身で作成したコードを他人が見られる様に公開する為のツール』
のことです。

個人制作のアプリケーションなら自身のPC内だけで完結できますけど、チーム開発等になるとそういうわけにもいきません。
複数人で作業をするためにもコードを他人が見られる様に公開して、更に公開したコードにコメントまでもらえたり！！
あらまぁ便利

どうやって作成したコードを公開してコメントをもらったりするの？

それでは大まかな流れをざっくりと説明すると

1.GitHub上で作成したファイル等を選択してローカルリポジトリを作成する。
2.作成したローカルリポジトリの状況をコミットする。
3.コミットし終えたら、GitHub上にプッシュしリモートリポジトリを作成する。

以上！！

ね？簡単でしょう？
...いやわからん
しかし大丈夫！これから1つずつ工程を見ていきましょう！！

GitHubにリポジトリを作成する(ローカル編)

GitHubのアカウントは説明が無くても作成できると思いますし、ここでは省きます！

まずはGitHub上に作成したファイル等の更新履歴を保管しておく為の箱を準備します。
それが先ほどから出てきていたリポジトリになります！
リポジトリには'ローカル'と"リモート"の2種類があり、それぞれ'自身のPC用'と"外部サーバー用"という認識で大丈夫です！！

それでは実際にリポジトリを作成していきましょう！！
GitHub Desktopの初期画面の『Add an Existing Repository from your Hard Drive...』をクリックします。

すると下の様に、保存したいファイル・ディレクトリはどこにありますか？と聞いてくるので、保存してあるディレクトリを選択して『Add Repository』ボタンをクリックしましょう。
今回は『git-app』というファイル名の物を選択しています。

すると下の画面に切り替わります。
これでローカル用のリポジトリが作成できました！！めちゃ簡単！！

GitHubにリポジトリを作成する(リモート編)

それでは次はリモートリポジトリを作成していきましょう！！
現在ローカルリポジトリという箱に作成していたファイルを入れる事はできました。
では、その入れたファイルの状態をローカルリポジトリに保存します。
この保存作業のことを『コミット(Commit)』と呼びます。
ポケモンで言うと主人公の名前と性別を決めたからとりあえずレポート書いとこ。
みたいなことですね

ローカルリポジトリの画面の左下に『Summary (required)』と書いてある入力欄がありますので、そこにどんな変更・修正を行ったのかをコミット名として書いていきましょう。
今回は最初の段階での保存なので『first commit』としておきましょう。
そしてコミット名を入力できたら『commit to master』というボタンをクリックしてください。
すると下の様な画面になりますので、真ん中あたりの『Publish repository』という青いボタンを押しましょう。
そして名前を入力する画面になりますが、ここでそのまま『Publish repository』ボタンを押さないでください！！
写真にある様に『Keep this code private』というチェックボックスのチェックを外しておきましょう！！
ここを外しておかないと、外部サーバー上で公開しても他人がファイルを変更・修正することができなくなってしまいます

さぁ、それではこれでリモートリポジトリが作成できたはずです。
GitHubへ移動してみて確認してみましょう！！
下の画面の様に作成したリポジトリがWeb上で確認できれば、作成成功です
ひとまずお疲れ様でした！！

ローカル・リモート両方のリポジトリが作成できましたので、これで多人数開発を行う準備ができました。
では、実際にデータを変更・修正して作業の流れを見ていきましょう！！...と言いたいところですがその前に1つ覚えておかないといけない事項があります。
それが『ブランチ』です。

ブランチって？

ブランチというのは、アプリケーション作成等の時にいきなりコードの変更・修正・追加をせずに失敗した時の保険用のファイルをコピーして作成しておく様なイメージです。
コピーに予め実装したい機能のコード等を書き、正常に動作できたらコピーを本筋のファイルへ統合させる。という作業をすることによってエラー発生等の不具合が起きた時に対処がしやすくなります。

このコピーを作成することを『ブランチを切る』、コピーを本筋に統合することを『マージ(merge)』と呼びます。
また、本筋からコピーされたファイルのことを『トピックブランチ』、本筋のファイルを『マスターブランチ』とそれぞれ呼びますので、こちらも覚えておきましょう！！

実際にデータを変更・修正してみる

それではいよいよ実際にデータを触ってみましょう！！

まずはGitHub Desktop上部にある『Current Branch』をクリックし下の画面を表示させましょう。
表示させたら新しいブランチを作成する為に、『New Branch』をクリックして新しいブランチを作成しましょう！！

すると新しいブランチの名前を入力する欄が出てきましたね。
ここの名前はどういった機能を実装したいから新しいブランチを作成するのか？というのが一目見てわかる様な名前にしましょう。
名前を入力したら『Create Branch』をクリックして新しいブランチを作成しちゃいましょう

これでローカルリポジトリに『投稿画面作成』という名前の新しいブランチが作成されましたね！！
でも、これだけでは自身のPC内でしか作成されていません。
そんな時は...？
そう！！リモートリポジトリに反映させる為にプッシュです！！
下の様な画面になっているはずなので『Publish branch』をクリックしてリモートリポジトリに反映させちゃいましょう！！

そうしたら、次は実際にエディタでコードを変更・修正します！！
今回はもう変更した後のGitHubの画面からはじめます。
真ん中の画面に実際に変更したコードが表示されていますね。(緑色が追加したコードになります。)
それでは、この内容を『投稿画面作成』というブランチ上にコミットしていきます。
方法は、上で説明していたので割愛します！！

この調子で投稿画面を作成するのに必要なコミットを全て終えたのが下の画像になります。
左側の『History』をクリックすると今までコミットしてきた内容の履歴が表示されます。
この一覧のことを『コミットログ(Commit Log)』と呼びます。
さて、それではこの新しくコミットした一覧達もリモートリポジトリへ反映させましょう！！
こちらも方法は上で説明しているので割愛です！！

リモートリポジトリへ反映させたら次は他の人に自身が書いたコードを見てもらい本筋に統合しても大丈夫かどうかを判断してもらいましょう。
その為に行うのが『プルリクエスト(Pull Request)』です。

プルリクエストを出してコードを見てもらう又は他人のコードを見てコメントを書こう

リモートリポジトリへプッシュすると下の画面の様に『Create Pull Request』というボタンが表示されています。
ここをクリックすると他人へ自身のコードを見てもらう為の依頼作成画面へ移行します！！

移行するとした画面の様にコメントを入力する欄が出てきます。
ここに依頼文を入力しましょう、入力する際は『# What』と『# Why』を使用し、『一体何を作成したのか？』と『なぜそれを作成したのか？』ということを誰が見てもわかる様に記述します。
コメントを記入したら『Create pull request』を押して依頼を出しましょう

依頼文が作成されました。
『何を』『なぜ』作成したのかがわかりやすくなっていますね

それでは次はプルリクエストされた側になってコメントを書いてみましょう。
先ほどの画面の真ん中少し上に『Files changed』というボタンがありますのでそこをクリックすると下の画像の様に変更したコードの一覧が表示されます。
表示されたコードを見て問題があった場合はその箇所だけにコメントを残すことができます。
下の画像の青い+ボタンを押すとボタンが表示されている行に向けてのコメント欄が出てきますので、修正内容等を記述しましょう。

また、修正箇所だけでは無くプルリクエスト全体に向けてのコメントも残すことができます。

コメントを残すと下の画像の様にプルリクエスト全体と修正箇所へのコメントが両方表示されているのがわかりますね。
これはわかりやすい

それでは指摘された箇所を修正した場合の流れを見ていきましょう。
修正し、それをリモートリポジトリへ反映させたら、先ほどの修正箇所へのコメントへ修正した旨の返事を記述しコメントを残しましょう。
こうすることによって修正依頼をかけた人に修正が無事に終わったことを報告することができます。

依頼をかけた人は修正内容を再度確認して問題ないかどうかをチェックします。
その上で問題が全て解決されていればその旨もコメントで伝えてあげましょう！！
下の画像で『LGTM』と書いてあるコメントがそれに当たります。
QiitaでもLGTMのボタンがあったけど意味をわかっていませんでした

それではいよいよ枝分かれさせていたブランチを本筋に統合させましょう！！
統合させるにはコメント欄の下にある『Merge pull request』というボタンをクリックします！！

クリックすると『Merge pull request』という表示が『Confirm merge』と切り替わりますので、それを再度クリックします。
これで本筋に統合が完了しました！！

統合したらブランチはもう必要ありませんので『Delete branch』をクリックして削除しちゃいましょう！！

さぁこれでデータの更新が終了しましたね。
でも、今度はリモートリポジトリにしか反映されていませんので、ローカルリポジトリにも変更を反映させないといけません。
その際に使用するのが『プル(Pull)』です。
最後の仕上げです、頑張りましょう

リモートリポジトリの内容をローカルリポジトリへ反映させる

これまでで枝分かれさせたブランチの内容をリモートリポジトリの本筋に統合することができました。
それでは最後の仕上げにローカルリポジトリの本筋にもブランチの内容を統合させましょう！！

GitHub Desktop上で『Current Branch』をクリックし『master』を選択しましょう。
選択したら横の『Fetch origin』をクリックしましょう。
これによってリモートリポジトリ上で本筋に変更が無かったかを確認します。

今回は当然データを変更しているので、本筋に変更がありました。
その場合、下の画像の様に『Pull origin』ボタンが現れます。

このボタンをクリックすることでローカルリポジトリに内容が反映されます！！

いやぁ〜長かった...
全然簡潔にまとめられませんでした...

でも、文字に起こすことで自分の中でも落とし込みができた様な気がします！！

よし、この調子でどんどんGitHubを使ってアプリケーション作成頑張ります

最後までお付き合いいただき、ありがとうございました！！

TL,DR

ghq の v1 でなくなった look コマンドをデフォルメして復活させる の zsh 版+αです

変更点

• command cd だと動かなかったので cd に
• ghq は command ghq に
• 部分一致した上で peco を起動できるように

Code

ghq() {
    if [[ $1 == "look" ]]; then
        if [[ -n $2 ]]; then
            repo_name="$2"
            exact_matched=$(command ghq list --full-path --exact "$repo_name")
            if [[ -n "$exact_matched" ]]; then
                cd "$exact_matched"
            else
                cd $(command ghq list --full-path "$repo_name" | peco)
            fi
        else
            cd $(command ghq list --full-path | peco)
        fi
    else
        command ghq "$@"
    fi
}

Gitを使ったことがない人向けにチーム開発でコードがマージされるまでの流れ（利用するコマンド）をまとめてみたいと思います。

Gitをつかったソースコードの管理とは

Gitはソースコードのバージョン管理を行うためのツールです。
会社での開発の場合、複数の人がソースコードの変更を行います。
なので、

• ソースコードを共有できるようにしておくこと
• 誰がいつどこに変更を加えたか確認できること
• 製品のリリース等に合わせてバージョンが管理できること

が必要になります。
なので、gitとgit レポジトリと言われるgithub, gitlabなどを利用してソースコードをみんなで管理できるようにしています。

大体下記のような流れで開発が行われていきます。

1. 編集するコードを自分のPCにダウンロードする(clone)
2. 変更を加える
3. レポジトリにアップロードしてマージをしてマージをしてもらう要求（pullRequest）
4. 加えた変更に対して、詳しい人（上司、先輩など）がレビューを行い、修正→レビューを繰り替えす（コードレビュー）
5. OKが出たらコードの変更を受け入れる（マージ）

チーム開発を行うときのコード修正の流れ

会社に開発者として配属された場合は既に開発中のコードがあって、そこに手を加えていく場合が多いと思うので、既にレポジトリ、コードがある前提で解説します。

git をコマンドラインで使えるようにする。

使っているOSに合わせてgitをダウンロード、インストールしてコマンドプロンプトやターミナルで使えるようにします。
コマンドプロンプトやターミナルで

git --help

と打って「コマンドが見つかりません」的なメッセージが表示された場合はこの手順が必要です。利用できるコマンドの一覧が表示された場合は既にインストール済みです。

インストールされていない場合は、以下のサイトからダウンロードし、インストーラーに従ってインストールします。
https://git-scm.com/

gtihubからローカルにフォルダを落としてくる

「このアプリケーションのXXを修正して。レポジトリのURLはXXXだから」
みたいな感じで仕事が振られるのではないでしょうか。
とりあえずそのURLにアクセスしてみます。
画面のどこかに「code」(またはcloneなど)というボタンがあるはずなので、そこに表示されているURIをコピーします。
画面はgithubのものです。gitlab等でも同様にソースコードのcloneをするためのボタンが存在するはずです。

コマンドプロンプトで、ソースコードをコピーしたいディレクトリに移動してcloneを行います。

git clone {{上記URL}}
例）git clone git@github.com:account-name/repo-name-sample.git

このコマンドの後、カレントディレクトリ（今コンソールで見ているディレクトリ）に落としてきたソースの名前のフォルダがあるはすです。
なかったらなにかに失敗していると思いますので、エラーメッセージを確認してください。

ブランチの変更

コードを落として来たらまずブランチを変更したほうがいいです。
git cloneした時点で大体masterブランチやdevelopブランチなどという一番メインで使っているブランチに設定されていることが多いです。
そのブランチはみんながソースコードをダウンロードしたり、製品出荷に使われたりする大事なものなので、勝手に変更を加えると上司に怒られちゃいます。
ブランチの変更は

cd {{さっきクローンしたソースのフォルダ名}}
git checkout -b {{新しく作るブランチの名前}}
例）git checkout -b sample
もしくは
git branch {{新しく作るブランチの名前}}
git checkout {{新しく作るブランチの名前}}
例）git branch sample
   git checkout sample

git checkoutはブランチを切り替えるときに使うコマンドで、上記の用に-bをつけると新しくブランチ作ることになります。
git branch は新しいブランチを作るときに使うコマンドです。

ブランチの名前はチームでルールがあることが多いです。（修正するバグの概要、課題管理番号、通し番号など）
周りの人に確認してみましょう。

ソースコードの編集

バグ修正とか新機能追加とか与えられた仕事を頑張ってください。
修正を行うとき、キリがいいタイミングで定期的に下の「編集したファイルの確認」〜「レポジトリにPush」までを行うことをおすすめします。

• 自分のPC上で行った編集を定期的にレポジトリにバックアップすることができるのでローカルのフォルダが壊れたときに安心
• コミットログ（変更を行った際のメッセージ）がわかりやすい

というメリットがあります。（ここらへんはチームや個人の癖やルールがあると思うので、他の人のやり方を見るのがいいと思います。）

編集したファイルの確認

編集が終わったら修正点を確認します。

git status　

自分が変更するつもりではなかったものが修正の中に入ってしまっていないか確認しましょう。

修正したファイルのコミット準備

コミットというのは「今回修正したファイルはこれです！」という提出意思表示のようなものです。
修正をコミットする準備として、確認したファイルを今回の修正の範囲としてアップロードしますよ、という宣言的なものをします。

git add . 
もしくは
git add {{修正をコミットするファイルのパス}}

git add .の場合はgit statusに表示されたすべてのファイルをコミットすることになります。
いろんなファイルに修正は加えたけど特定のファイルだけをコミットしたい場合はgit add {{修正をコミットするファイルのパス}}を使いましょう。

コメントをつけてコミット

コミットするときに何を変更するかコメントをつけておくことをおすすめします。

git commit -m "コメントしたい内容を書き込む"

コメントの付け方はチームによってルールがある場合があるので他の人のものを参考にしましょう。

レポジトリにPush

コミットしてもまだレポジトリには反映されていません。
下記のようにgit pushすることで、レポジトリに反映され、他の人達にも確認できる状態になります。

git push origin {{作ったブランチの名前}}
例）git push origin sample

レポジトリからpull Request(Merge Request)を提出

レポジトリの画面に移動して、Pull Request（MergeRequest）を提出します。
Pull Request（MergeRequest）というのは、「masterブランチ（もしくは他のリリースブランチなど）に私の修正を入れてください！」という修正要望です。この要望をレポジトリの管理者が受け入れると晴れて修正が反映されることになります。
(Pull RequestとMargeRequestは同じようなものですが、GitHubというレポジトリを使っているか、GitLabというレポジトリをつかっているかによって名称が異なります。)

以下githubの場合の手順です。（他のレポジトリでもだいたい同じ流れです）
先程pushした自分のブランチを表示し、画面右側にあるPull Requestボタンを押します。

コメントや、Reviewerを指定して、pullRequestを提出します。

レビューと修正

Reviewerからコメントが送られてきたら「ソースコードの編集」から「レポジトリにPush」までの手順を繰り返します。
最終的にマスタブランチ（もしくはその他ターゲットブランチ）に修正がマージされたらお仕事完了です！

困ったときのいろいろ

いろいろ変更加えたらわけわからなくなったのでリモートレポジトリPushしてある状態にもどしたい！

git fetch origin

合わせたいブランチにreset
git reset --hard origin/{{合わせたいブランチ名}}
例）git reset --hard origin/sample

マスタブランチに他の人の習性がマージされている！（マスタブランチが自分がPullしたときの状態より新しくなっている！）

masterブランチに切り替える
git checkout master

masterを最新の状態にする
git pull origin master

自分の作業ブランチへ切り替える
git checkout {{作業ブランチ名}}
例）git checkout sample

mergeコマンドでmaserブランチの内容を取り込む
git merge origin master

蛇足

githubとかgitbucketとかgitlabとか似たような名前があるけど何？

gitはソースコードを管理するツールの名前、githubとかgitbucketとかgitlabはレポジトリ（保管場所）の名前です。

その他チームごとの運用体制

この他タグの運用とか、CIの仕組み（コードの品質を保つための仕組み）などチームによってルールがある場合が多いです。

Gitを使ったことがない人向けにチーム開発でコードがマージされるまでの流れ（利用するコマンド）をまとめてみたいと思います。

Gitをつかったソースコードの管理とは

Gitはソースコードのバージョン管理を行うためのツールです。
会社での開発の場合、複数の人がソースコードの変更を行います。
なので、

• ソースコードを共有できるようにしておくこと
• 誰がいつどこに変更を加えたか確認できること
• 製品のリリース等に合わせてバージョンが管理できること

が必要になります。
なので、gitとgit レポジトリと言われるgithub, gitlabなどを利用してソースコードをみんなで管理できるようにしています。

大体下記のような流れで開発が行われていきます。

1. 編集するコードを自分のPCにダウンロードする(clone)
2. 変更を加える
3. レポジトリにアップロードしてマージをしてマージをしてもらう要求（pullRequest）
4. 加えた変更に対して、詳しい人（上司、先輩など）がレビューを行い、修正→レビューを繰り替えす（コードレビュー）
5. OKが出たらコードの変更を受け入れる（マージ）

チーム開発を行うときのコード修正の流れ

会社に開発者として配属された場合は既に開発中のコードがあって、そこに手を加えていく場合が多いと思うので、既にレポジトリ、コードがある前提で解説します。

git をコマンドラインで使えるようにする。

使っているOSに合わせてgitをダウンロード、インストールしてコマンドプロンプトやターミナルで使えるようにします。
コマンドプロンプトやターミナルで

git --help

と打って「コマンドが見つかりません」的なメッセージが表示された場合はこの手順が必要です。利用できるコマンドの一覧が表示された場合は既にインストール済みです。

インストールされていない場合は、以下のサイトからダウンロードし、インストーラーに従ってインストールします。
https://git-scm.com/

gtihubからローカルにフォルダを落としてくる

「このアプリケーションのXXを修正して。レポジトリのURLはXXXだから」
みたいな感じで仕事が振られるのではないでしょうか。
とりあえずそのURLにアクセスしてみます。
画面のどこかに「code」(またはcloneなど)というボタンがあるはずなので、そこに表示されているURIをコピーします。
画面はgithubのものです。gitlab等でも同様にソースコードのcloneをするためのボタンが存在するはずです。

コマンドプロンプトで、ソースコードをコピーしたいディレクトリに移動してcloneを行います。

git clone {{上記URL}}
例）git clone git@github.com:account-name/repo-name-sample.git

このコマンドの後、カレントディレクトリ（今コンソールで見ているディレクトリ）に落としてきたソースの名前のフォルダがあるはすです。
なかったらなにかに失敗していると思いますので、エラーメッセージを確認してください。

ブランチの変更

コードを落として来たらまずブランチを変更したほうがいいです。
git cloneした時点で大体masterブランチやdevelopブランチなどという一番メインで使っているブランチに設定されていることが多いです。
そのブランチはみんながソースコードをダウンロードしたり、製品出荷に使われたりする大事なものなので、勝手に変更を加えると上司に怒られちゃいます。
ブランチの変更は

cd {{さっきクローンしたソースのフォルダ名}}
git checkout -b {{新しく作るブランチの名前}}
例）git checkout -b sample
もしくは
git branch {{新しく作るブランチの名前}}
git checkout {{新しく作るブランチの名前}}
例）git branch sample
   git checkout sample

git checkoutはブランチを切り替えるときに使うコマンドで、上記の用に-bをつけると新しくブランチ作ることになります。
git branch は新しいブランチを作るときに使うコマンドです。

ブランチの名前はチームでルールがあることが多いです。（修正するバグの概要、課題管理番号、通し番号など）
周りの人に確認してみましょう。

ソースコードの編集

バグ修正とか新機能追加とか与えられた仕事を頑張ってください。
修正を行うとき、キリがいいタイミングで定期的に下の「編集したファイルの確認」〜「レポジトリにPush」までを行うことをおすすめします。

• 自分のPC上で行った編集を定期的にレポジトリにバックアップすることができるのでローカルのフォルダが壊れたときに安心
• コミットログ（変更を行った際のメッセージ）がわかりやすい

というメリットがあります。（ここらへんはチームや個人の癖やルールがあると思うので、他の人のやり方を見るのがいいと思います。）

編集したファイルの確認

編集が終わったら修正点を確認します。

git status　

自分が変更するつもりではなかったものが修正の中に入ってしまっていないか確認しましょう。

修正したファイルのコミット準備

コミットというのは「今回修正したファイルはこれです！」という提出意思表示のようなものです。
修正をコミットする準備として、確認したファイルを今回の修正の範囲としてアップロードしますよ、という宣言的なものをします。

git add . 
もしくは
git add {{修正をコミットするファイルのパス}}

git add .の場合はgit statusに表示されたすべてのファイルをコミットすることになります。
いろんなファイルに修正は加えたけど特定のファイルだけをコミットしたい場合はgit add {{修正をコミットするファイルのパス}}を使いましょう。

コメントをつけてコミット

コミットするときに何を変更するかコメントをつけておくことをおすすめします。

git commit -m "コメントしたい内容を書き込む"

コメントの付け方はチームによってルールがある場合があるので他の人のものを参考にしましょう。

レポジトリにPush

コミットしてもまだレポジトリには反映されていません。
下記のようにgit pushすることで、レポジトリに反映され、他の人達にも確認できる状態になります。

git push origin {{作ったブランチの名前}}
例）git push origin sample

レポジトリからpull Request(Merge Request)を提出

レポジトリの画面に移動して、Pull Request（MergeRequest）を提出します。
Pull Request（MergeRequest）というのは、「masterブランチ（もしくは他のリリースブランチなど）に私の修正を入れてください！」という修正要望です。この要望をレポジトリの管理者が受け入れると晴れて修正が反映されることになります。
(Pull RequestとMargeRequestは同じようなものですが、GitHubというレポジトリを使っているか、GitLabというレポジトリをつかっているかによって名称が異なります。)

以下githubの場合の手順です。（他のレポジトリでもだいたい同じ流れです）
先程pushした自分のブランチを表示し、画面右側にあるPull Requestボタンを押します。

コメントや、Reviewerを指定して、pullRequestを提出します。

レビューと修正

Reviewerからコメントが送られてきたら「ソースコードの編集」から「レポジトリにPush」までの手順を繰り返します。
最終的にマスタブランチ（もしくはその他ターゲットブランチ）に修正がマージされたらお仕事完了です！

困ったときのいろいろ

いろいろ変更加えたらわけわからなくなったのでリモートレポジトリPushしてある状態にもどしたい！

git fetch origin

合わせたいブランチにreset
git reset --hard origin/{{合わせたいブランチ名}}
例）git reset --hard origin/sample

マスタブランチに他の人の習性がマージされている！（マスタブランチが自分がPullしたときの状態より新しくなっている！）

masterブランチに切り替える
git checkout master

masterを最新の状態にする
git pull origin master

自分の作業ブランチへ切り替える
git checkout {{作業ブランチ名}}
例）git checkout sample

mergeコマンドでmaserブランチの内容を取り込む
git merge origin master

蛇足

githubとかgitbucketとかgitlabとか似たような名前があるけど何？

gitはソースコードを管理するツールの名前、githubとかgitbucketとかgitlabはレポジトリ（保管場所）の名前です。

その他チームごとの運用体制

この他タグの運用とか、CIの仕組み（コードの品質を保つための仕組み）などチームによってルールがある場合が多いです。

はじめに

gitサーバのユーザ毎アクセス管理が手軽にできるgitolite。巷にはセッティング例の記事はあるが、gitoliteのほぼ全ての操作は「鍵ペアを作る」とか「コミットする」という、手慣れた人にとっては当たり前の操作の集まりなので、具体的な手順よりも必要な要件を書いた方が話が早いのでは？

というわけで、メモ代わりの記事です。初回インストールの記憶で書いているので、ミスはあるかも。再セットアップすることがあれば、直すこともあるかも？

インストール先のサーバ環境はCentOS7だけど、おそらくyumが使えれば他でも大差ないでしょう。

インストール

前提

まさかgitが入ってないことはないよね？

管理用鍵ペアを作る

ssh-keygen等で管理者用の鍵ペアを作成しておく。サーバ側で必要なのは公開鍵。秘密鍵は管理ユーザがリモートアクセスで使用する（サーバでは不要）。

yum install & コミッタ設定

EPELを有効にした状態で「yum install gitolite3」。この操作で、gitolite操作用のユーザ「gitolite3」が自動的に作成される。このユーザで初期化時に自動的にコミットされる際の用のコミッタ設定もしておく（多分必須）。こんな感じ

# yum install gitolite3
# su - gitolite3
$ git config --global user.name ユーザ名
$ git config --global user.email メールアドレス

コミットするファイル名で日本語を使うための設定とかを仕込んでいる記事もみたけど、どれだけ重要なのかはよくわからない。

初期化

上記の作業でユーザgitolite3になっているので、先に作成した公開鍵を使って、gitolite3初期化をする。

$ gitolite setup -pk 管理用公開鍵ファイル

これだけでサーバ側の作業は終わり。gitliteに「gitolite-admin」というリポジトリができているので、以降はリモート側から、主にリポジトリへのコミットで管理を行う。

管理

管理用アカウントからのアクセス

管理用アカウントからのアクセスの要件は「管理用秘密鍵を使って」「ユーザgitolite3で」アクセスすることだ。なので、例えば.ssh/configに以下のようなエントリを追加しておいて

Host           gitoliteadmin（好きな名前をどうぞ）
HostName       ホスト名やIPアドレスなど
User           gitolite3
IdentityFile   ~/.ssh/秘密鍵ファイル名

「ssh gitoliteadmin」とやってみよう。もちろん、sshコマンドのオプションえ上記の情報をセットしてもOK（OKなんだけど、結局git操作でconfigへのエントリ追加はほぼ必須になる）。ログインメッセージが出て切断されれば成功だ。

hello gitadmin, this is gitolite3@*** running gitolite3 3.6.12-1.el7 on git ***

 R W    gitolite-admin
 R W    testing

管理用リポジトリをクローンする

上記のアクセス情報で管理用リポジトリ「gitolite-admin」をクローンできる。
gitコマンドからは

git clone gitoliteadmin:/gitolite-admin

などで可能だが、お好きなgitクライアントでどうぞ。

ユーザ追加

ユーザの追加は、追加したいユーザの鍵ペアの公開鍵をgitolite-adminリポジトリに追加（コミット）するだけでいい。

例えば、「秘密鍵：git-user1.pem、公開鍵：git-user1.pub」があったとすると、git-user1.pubを（クローンした）gitlite-admin/keydirに置いて、git commit & pushしてあげる。秘密鍵はユーザが保持して、アクセスに使用する。

大事なのは、「この公開鍵ファイル名がアクセス制御のユーザ識別子となること」だ。なので、公開鍵を登録する場合にはファイル名に気をつけよう。ファイル名が「git-user1.pub」であれば、ユーザ識別子は「git-user1」となる。

リポジトリ追加・権限設定

初期状態では、gitlite-admin/conf/gitolite.confが以下のような内容になっているはずだ。

repo gitolite-admin
    RW+     =   gitadmin

repo testing
    RW+     =   @all

このファイルに「repo 新規リポジトリ名」という行と「RW+ = 」というアクセス権限の行を追加して、ユーザ追加と同様、git commit & pushしてあげる。それだけ。もしかしたらサーバでgit initするより手軽？

repo gitolite-admin
    RW+     =   gitadmin

repo testing
    RW+     =   @all

repo new-repository
    RW+     =   @all

権限設定は「RW+ =」の後に、アクセス許可したいユーザ識別子あるいはグループを設定する。複数のユーザやグループを設定したい場合はスペース区切りで並べる。グループは同じファイルに「@group1 = git-user1 git-user2」などとして定義する。初期状態で「@all」というグループが設定されている。権限の種類は「R (read only)」「RW (read/write)」「RW+（全部可能）」の3種類。

@group1 = git-user1 git-user2

repo gitolite-admin
    RW+     =   gitadmin

repo testing
    RW+     =   @all

repo new-repository
    RW+    = gitadmin
    RW     = @group1
    R      = git-user3 git-user4

ユーザでの利用

ユーザからのアクセスについても、基本は管理者と同じ。要件は「ユーザ用秘密鍵を使って」「ユーザgitolite3で」アクセスすること。.ssh/config例としてはこんな感じ...と思ったけど、管理用と全く変わらん（秘密鍵が違うだけ、だからね）。

Host           gitolite（好きな名前をどうぞ）
HostName       ホスト名やIPアドレスなど
User           gitolite3
IdentityFile   ~/.ssh/秘密鍵ファイル名

これまた管理者と同じで、ssh gitolite、とやると、使えるリポジトリ一覧が表示される。試しに「testing」をクローンしてみよう。

git clone gitolite:/testing

「warning: You appear to have cloned an empty repository.」という警告が出るが（誰も何もコミットしてなければ）、気にしない。

既存リポジトリの移行

gitoliteを使い始めるケースの大半では、生のgitで運用していたリポジトリを移行したいはずだ。この作業は主にリモート側で行う。これは管理ネタの1つだが、ユーザ追加した後にやった方がいいだろうなので、ここに書く。

まずは、管理アカウントで上述の「リポジトリ追加」を行う。移行の場合でも操作は変わらない。新規リポジトリができたら、リモート側（既存リポジトリがある）で、「gitサーバの追加」をして「git push」するのが基本となる。

前提としては、リモート側でユーザアカウントにて移行したいリポジトリにいるとする。リポジトリ名を「repo1」とすると

git remote add gitolite ssh://gitolite/repo1 # gitサーバ追加
git push gitolite master # 基本情報+masterのpush
git push gitolite --all # master以外のブランチpush
git push gitolite --tags # タグ

となる。これで既存リポジトリの内容がgitolite内リポジトリとして登録される。移行リポジトリが多い場合にはシェルスクリプトを作るなり、何でもどうぞ。

なお、この操作で、手元の.git/configには「origin」に加えて「gitolite」が追加されているはず。このままでもいいかもしれないが、もし「元のリポジトリへのアクセスは不要」「gitoliteではなくoriginとしたい」ような場合には、gitoliteからクローンし直すか、.ssh/configを編集してすればいいかと（自分は後者をやった）

最後に

わかってしまえば、セッティングは1分もかからないレベル（リポジトリの移行を除く）。

説明では主にgitコマンド使ってるけど、各種commit&pushとかはsourcetreeとか使っても快適にできるよ。

会社のgithubアカウントと個人のgithubアカウントを使っていたが、個人のサブアカウントが欲しくなり、pushするまでに少し悩んだので、メモとして残しておく。

手順

1. 新しいemailアドレスでgithubアカウントを作成する

2. ssh接続するためのkeyを生成する

~/.ssh へ移動し下記コマンドで鍵を生成

$ ssh-keygen -t rsa -C {サブアカウントのemailアドレス} -f サブアカウントのkey名(任意)

3. ~/.ssh/config に下記フォーマットで秘密鍵のパスを指定する

Host github-sub #=> ここは好きな名前でOK
  HostName github.com
  IdentityFile ~/.ssh/sub_rsa
  User git
  Port 22
  TCPKeepAlive yes
  IdentitiesOnly yes

4. 新しいgithubアカウントページに公開鍵を登録する

githubのweb画面のプルダウンからsettings => SSH and GPG keysを選択

そこに2でkeyを生成した時に作られる.pubの方のkey情報を貼り付け

4. 接続確認

ターミナルで先ほど記述したHostの名前でssh接続する

$ ssh -T <HOST>

Hi アカウント名! You've successfully authenticated, but GitHub does not provide shell access.
と返ってくると接続成功

5. 新しいリポジトリを作成する

6. ローカル環境に新しいプロジェクトを作成

1. git init
2. git config --local user.name アカウント名
3. git config --local user.email メールアドレス
4. 変更を加えて、git add & git commit
5. git remote をセットする時に、下記のようにoriginを設定する

$ git remote set-url origin Host名:アカウント名/リポジトリ名.git  

最後にgit push --set-upstream origin master
をすると無事pushができる。

概要

.gitignoreファイルを使い、指定のファイルをgit hubにアップしないようにする方法です。

rubyでbitcoinの自動売買システムを作成しています。ただ、bitflyerのAPI_KEYをgit hubにアップすると、セキュリティ上まずいです。色々調べると、.gitignoreファイルで対処可能であることが分かったので、記録しておこうと思います。

ruby on railsだと、環境変数でgit hubの管轄外にできることは知っていたのですが、今回は別の方法で。

手順

手順はざっとこんな感じです。

1 .gitignoreファイルをアプリケーション直下に作成
2 git statusで状況確認
3 .gitignoreファイルに除外したいファイルを記述

1.gitignoreファイルをアプリケーション直下に作成

アプリケーションの直下に「.gitignore」ファイルを作成します。
拡張子と勘違いされて、保存する前に警告が出ますが、「.gitignore.」で保存すればいいみたいです。それと合わせて、bitflyerのAPI_KEYを記述するkey.rbの作成します。

2 git statusで状況確認

git statusはcommitされていないファイルを確認するみたいのものです。
（間違っていたらすみません笑)
すると、先ほど作成した2つのファイルが確認できます。これをこのままリポジトリにpushするとAPI_KEYが公開されてしますので、「key.rb」を隠したいと思います。

$ git status

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .gitignore
        key.rb

nothing added to commit but untracked files present (use "git add" to track)

3 .gitignoreファイルに除外したいファイルを記述

API_KEYの書いているkey.rbファイルを.gitignoreに記述すれば、git hubからの除外に成功です。

key.rb

API_KEY = "ここにkeyが書いています"
API_SECRET ="secret keyが書いています"

gitignore.

key.rb