git リポジトリにコミットするとき、署名を自動的に施す git config commit.gpgsign true すべてのリポジトリで、コミットするとき、署名を自動的に施す git config --global commit.gpgsign true 注意 利用する Git クライアントによっては有効に動作しない場合あり。おもに、 git クライアント自体に git プログラムが組み込まれている時。 例: - gitkraken (……他は知らないので提案ください)
git config commit.gpgsign true
git config --global commit.gpgsign true
利用する Git クライアントによっては有効に動作しない場合あり。おもに、 git クライアント自体に git プログラムが組み込まれている時。
例: - gitkraken (……他は知らないので提案ください)
Railsのインストール 過去の記事をご覧ください(Railsインストール) MySQLに変更する方法 過去の記事をご覧ください(DBをMySQLに変更) 日本語化 Rails5からはapplication.rbでは設定できないので注意しよう。新しいファイルを追加して以下のように設定しよう。ja.ymlに関しては同じように設定できる。 initializers/locals.rb I18n.config.available_locales = :ja I18n.default_locale = :ja Railsの基本的な概念 routeの設定 controllerの設定 modelの設定 ※viewは対応するコントローラーのアクションで定義された変数が使えてRubyが埋め込めることがわかればとりあえずいいと思うので省略。 GitHub関連 GitHubの使い方はこのあたりが良かった。ssh通信の公開鍵の登録についてはこのあたりが参考になった。また、パスワードなどの機密情報が書かれているファイルは、GitHubで公開することは避けよう(.gitignoreをいじれば同期するものを制限できる)。 Bootstrap Bootstrapは使い方はこのあたり、導入の仕方はこのあたりが参考になった。
過去の記事をご覧ください(Railsインストール)
過去の記事をご覧ください(DBをMySQLに変更)
Rails5からはapplication.rbでは設定できないので注意しよう。新しいファイルを追加して以下のように設定しよう。ja.ymlに関しては同じように設定できる。
application.rb
ja.yml
I18n.config.available_locales = :ja I18n.default_locale = :ja
※viewは対応するコントローラーのアクションで定義された変数が使えてRubyが埋め込めることがわかればとりあえずいいと思うので省略。
GitHubの使い方はこのあたりが良かった。ssh通信の公開鍵の登録についてはこのあたりが参考になった。また、パスワードなどの機密情報が書かれているファイルは、GitHubで公開することは避けよう(.gitignoreをいじれば同期するものを制限できる)。
.gitignore
Bootstrapは使い方はこのあたり、導入の仕方はこのあたりが参考になった。
手元のマシンでgitで管理しているファイルを別のマシンに送りたいと思ったときに、以下の3つが自分の中にはあった。 一旦リモートリポジトリにpushして別マシンからcloneする git reset --hardした後、zip圧縮して送る git clone project-name copy-of-project-nameした後、copy-of-project-nameを圧縮して送る ただ、どれも微妙な気がしていた。 そこでgit bundleというものを知ったので試した。 ざっくりいえば、gitリポジトリのある範囲の内容を1ファイルにまとめる的な事をやってくれるらしい。 手順 今回はmasterブランチの内容をまとめて持っていく感じで使う。 まず、masterブランチを対象に project-name.bundle というバンドルファイルを作る。 git bundle create project-name.bundle master これで同ディレクトリにproject-name.bundleというバンドルファイルができあがる。 これをリモートマシンへどうにかして送る。（scpとかftpとかUSBメモリとか） 受け取ったら以下のようにして取り込む。 # バンドルファイルからcloneする git clone project-name.bundle project-name # git cloneによりディレクトリが作られるので移動 cd project-name # HEAD(masterブランチ)をorigin/masterに移動し、ワーキングツリーもreset git reset --hard origin/master ちょっと違うのが、git clone直後のHEADは何も指してない状態になっている。つまりワーキングツリーも空っぽの状態になっている。（.gitしかない状態） なので、git reset --hard origin/masterで無理やりワーキングツリーの状態をorigin/masterの状態にする。なお、origin（リモート）はバンドルファイルを指している。 バンドルファイルの扱いは色々あるみたいで、これで良いのかはわからないけど、多分これが一番楽だと思います。 ただ、ある程度大きいプロジェクトだと辛いかもしれない。そもそも今時のプロジェクトはリモートリポジトリがあるはずですし、わざわざこんな方法は取る必要はないでしょう。 あと言うまでもないですが、信頼できるバンドルファイルに対して使いましょう。 その用途にgitはいらないのでは 「必要なファイルをコピーして送れるなら、わざわざgitを使わなくてもいいのでは」といえばそうなんですが、この方法は以下の点が良いです commitした時点の綺麗な状態を間違いなく作れるのが良い 履歴をさかのぼりたくなる時をカバーできる 逆に、もしここら辺にメリットに感じなかったら、この方法は使わなくてよいと思います。 参考にしました 7.12 Git のさまざまなツール - バンドルファイルの作成 ここではbundle create時にHEADを含めていたが、含めてもcloneした時点でワーキングツリーがmasterの時点になる事はなかった。.git/refs/heads/masterが無いのでそれが原因なような気はする。
手元のマシンでgitで管理しているファイルを別のマシンに送りたいと思ったときに、以下の3つが自分の中にはあった。
git reset --hard
git clone project-name copy-of-project-name
copy-of-project-name
ただ、どれも微妙な気がしていた。
そこでgit bundleというものを知ったので試した。 ざっくりいえば、gitリポジトリのある範囲の内容を1ファイルにまとめる的な事をやってくれるらしい。
git bundle
今回はmasterブランチの内容をまとめて持っていく感じで使う。
まず、masterブランチを対象に project-name.bundle というバンドルファイルを作る。
master
project-name.bundle
git bundle create project-name.bundle master
これで同ディレクトリにproject-name.bundleというバンドルファイルができあがる。 これをリモートマシンへどうにかして送る。（scpとかftpとかUSBメモリとか）
受け取ったら以下のようにして取り込む。
# バンドルファイルからcloneする git clone project-name.bundle project-name # git cloneによりディレクトリが作られるので移動 cd project-name # HEAD(masterブランチ)をorigin/masterに移動し、ワーキングツリーもreset git reset --hard origin/master
ちょっと違うのが、git clone直後のHEADは何も指してない状態になっている。つまりワーキングツリーも空っぽの状態になっている。（.gitしかない状態） なので、git reset --hard origin/masterで無理やりワーキングツリーの状態をorigin/masterの状態にする。なお、origin（リモート）はバンドルファイルを指している。
.git
git reset --hard origin/master
バンドルファイルの扱いは色々あるみたいで、これで良いのかはわからないけど、多分これが一番楽だと思います。
ただ、ある程度大きいプロジェクトだと辛いかもしれない。そもそも今時のプロジェクトはリモートリポジトリがあるはずですし、わざわざこんな方法は取る必要はないでしょう。
あと言うまでもないですが、信頼できるバンドルファイルに対して使いましょう。
「必要なファイルをコピーして送れるなら、わざわざgitを使わなくてもいいのでは」といえばそうなんですが、この方法は以下の点が良いです
逆に、もしここら辺にメリットに感じなかったら、この方法は使わなくてよいと思います。
7.12 Git のさまざまなツール - バンドルファイルの作成
ここではbundle create時にHEADを含めていたが、含めてもcloneした時点でワーキングツリーがmasterの時点になる事はなかった。.git/refs/heads/masterが無いのでそれが原因なような気はする。
.git/refs/heads/master
手元のマシンでgitで管理しているファイルを送りたいと思ったときに、以下の3つが自分の中にはあった。 一旦リモートリポジトリにpushして別マシンからcloneする git reset --hardした後、zip圧縮して送る git clone project-name copy-of-project-nameした後、copy-of-project-nameを圧縮して送る ただ、どれも微妙な気がしていた。 そこでgit bundleというものを知ったので試した。 ざっくりいえば、gitリポジトリのある範囲の内容を1ファイルにまとめる的な事をやってくれるらしい。 手順 今回はmasterブランチの内容をまとめて持っていく感じで使う。 まず、masterブランチを対象に project-name.bundle というバンドルファイルを作る。 git bundle create project-name.bundle master これで同ディレクトリにproject-name.bundleというバンドルファイルができあがる。 これをリモートマシンへどうにかして送る。（scpとかftpとかUSBメモリとか） 受け取ったら以下のようにして取り込む。 # バンドルファイルからcloneする git clone project-name.bundle project-name # git cloneによりディレクトリが作られるので移動 cd project-name # HEAD(masterブランチ)をorigin/masterに移動し、ワーキングツリーもreset git reset --hard origin/master ちょっと違うのが、git clone直後のHEADは何も指してない状態になっている。つまりワーキングツリーも空っぽの状態になっている。（.gitしかない状態） なので、git reset --hard origin/masterで無理やりワーキングツリーの状態をorigin/masterの状態にする。なお、origin（リモート）はバンドルファイルを指している。 バンドルファイルの扱いは色々あるみたいで、これで良いのかはわからないけど、多分これが一番楽だと思います。 ただ、ある程度大きいプロジェクトだと辛いかもしれない。そもそも今時のプロジェクトはリモートリポジトリがあるはずですし、わざわざこんな方法は取る必要はないでしょう。 あと言うまでもないですが、信頼できるバンドルファイルに対して使いましょう。 その用途にgitはいらないのでは 「必要なファイルをコピーして送れるなら、わざわざgitを使わなくてもいいのでは」といえばそうなんですが、この方法は以下の点が良いです commitした時点の綺麗な状態を間違いなく作れるのが良い 履歴をさかのぼりたくなる時をカバーできる 逆に、もしここら辺にメリットに感じなかったら、この方法は使わなくてよいと思います。 参考にしました 7.12 Git のさまざまなツール - バンドルファイルの作成 ここではbundle create時にHEADを含めていたが、含めてもcloneした時点でワーキングツリーがmasterの時点になる事はなかった。.git/refs/heads/masterが無いのでそれが原因なような気はする。
手元のマシンでgitで管理しているファイルを送りたいと思ったときに、以下の3つが自分の中にはあった。
現象 Mac用パッケージ管理ツールのHomebrew経由でGitを2.21.0(2月24日リリース)にアップデート。 GitHubからソースを落としてくるべく、git cloneを実行したら次のエラーが発生。 fatal: multiple updates for ref 'refs/remotes/origin/master' not allowed 解決方法 Gitのglobal設定が保持されている~/.gitconfigから[remote "origin"]に関する記述を削除したら解消。 ##### 変更前 ###### [user] email = ***** name = ***** [http] postBuffer = 2M [core] excludesfile = /Users/atsushiosawa/.gitignore_global editor = vim [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* ##### 変更後 ###### [user] email = ***** name = ***** [http] postBuffer = 2M [core] excludesfile = /Users/atsushiosawa/.gitignore_global editor = vim 最後に [remote "origin"]の設定が2.21.0のバージョンアップの際に追加されたのか、それとも旧来からある設定がこのバージョンアップで悪さをするようになったのかは不明。 とりあえずは問題なく動いているので良かったがモヤモヤする……
Mac用パッケージ管理ツールのHomebrew経由でGitを2.21.0(2月24日リリース)にアップデート。 GitHubからソースを落としてくるべく、git cloneを実行したら次のエラーが発生。
git clone
fatal: multiple updates for ref 'refs/remotes/origin/master' not allowed
Gitのglobal設定が保持されている~/.gitconfigから[remote "origin"]に関する記述を削除したら解消。
~/.gitconfig
[remote "origin"]
##### 変更前 ###### [user] email = ***** name = ***** [http] postBuffer = 2M [core] excludesfile = /Users/atsushiosawa/.gitignore_global editor = vim [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/*
##### 変更後 ###### [user] email = ***** name = ***** [http] postBuffer = 2M [core] excludesfile = /Users/atsushiosawa/.gitignore_global editor = vim
[remote "origin"]の設定が2.21.0のバージョンアップの際に追加されたのか、それとも旧来からある設定がこのバージョンアップで悪さをするようになったのかは不明。 とりあえずは問題なく動いているので良かったがモヤモヤする……
./gradlew ktlintFormat の後に git diff --name-only | grep -v 特定ディレクトリまでのパス | xargs git checkout
./gradlew ktlintFormat
の後に
git diff --name-only | grep -v 特定ディレクトリまでのパス | xargs git checkout
はじめに コマンドラインからgit flowを使って開発をしたときにコマンドや手順を調べるのが面倒だったのでまとめます。 個人開発なので、複数人での開発とは違う部分もあるかと思います。 間違い等ありましたらご指摘お願いします。 git flow のインストール yum install git-flowでインストールできるというのを見かけたのですが、できないっぽいので他のやり方でインストールします。 $ cd /usr/local/src $ sudo bash $ wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash $ exit git flowの初期化 管理したいリポジトリで下記コマンド実行。 $ git flow init # いろいろでてくるけどとりあえず全部EnterでOK ちなみに-dオプションを付けると自動で初期設定をしてくれます。 リモートリポジトリがあるなら初期化した後git push --allしてもいいかも。 開発手順 featureブランチ developブランチからfeatureブランチを切って機能の追加を行います。 $ git flow feature start hogehoge これでfeature/hogehogeブランチが作成され、チェックアウトされます。 作業が終わったら $ git add . $ git commit -m "hoge" $ git flow feature finish hogehoge でdevelopブランチにマージされてfeature/hogehogeブランチは削除されます。 developブランチにマージされた後、developブランチをpushします。 releaseブランチ リリース作業をする際は、developブランチからreleaseブランチを切ります。 $ git flow release start v1.0 リリース作業が終わったら $ git add . $ git commit -m "hogehoge" $ git flow release finish v1.0 を実行すると、masterブランチとdevelopブランチにマージして、masterブランチにタグをつけてくれます。 タグはreleaseブランチの名前が付くようです。 また、releaseブランチは削除されます。 この作業が終わったらgit push --allですべてリモートリポジトリにあげます。 hotfixブランチ 緊急性の高いバグなどを修正する際に利用します。 master ブランチからhotfixブランチを切ります。 $ git flow hotfix start v1.1 作業が終わったら $ git add . $ git commit -m "hogehoge" $ git flow hotfix finish v1.1 でmasterとdevelopブランチにマージされて、masterブランチにタグが付きます。 余談 Cmderを利用しているのですがreleaseブランチを終了させて、masterブランチにマージする際のコメント記入を何もしないで:wqとすると画面がバグります。 少し書き換えればバグらずに済むのですが、ちょっとめんどうなのでどうにかして直したいですね… 参考 コマンドラインで Git Flow をインストールして使ってみる git-flow を試す git-flow cheatsheet git-flow コマンド説明和訳 さいごに 個人的に便利なツールだと思います。 この記事には載っていないコマンドもあり、理解するにはまだ勉強が足りないようです。
コマンドラインからgit flowを使って開発をしたときにコマンドや手順を調べるのが面倒だったのでまとめます。 個人開発なので、複数人での開発とは違う部分もあるかと思います。 間違い等ありましたらご指摘お願いします。
yum install git-flowでインストールできるというのを見かけたのですが、できないっぽいので他のやり方でインストールします。
yum install git-flow
$ cd /usr/local/src $ sudo bash $ wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash $ exit
管理したいリポジトリで下記コマンド実行。
$ git flow init # いろいろでてくるけどとりあえず全部EnterでOK
ちなみに-dオプションを付けると自動で初期設定をしてくれます。
-d
リモートリポジトリがあるなら初期化した後git push --allしてもいいかも。
git push --all
developブランチからfeatureブランチを切って機能の追加を行います。
$ git flow feature start hogehoge
これでfeature/hogehogeブランチが作成され、チェックアウトされます。
作業が終わったら
$ git add . $ git commit -m "hoge" $ git flow feature finish hogehoge
でdevelopブランチにマージされてfeature/hogehogeブランチは削除されます。
developブランチにマージされた後、developブランチをpushします。
リリース作業をする際は、developブランチからreleaseブランチを切ります。
$ git flow release start v1.0
リリース作業が終わったら
$ git add . $ git commit -m "hogehoge" $ git flow release finish v1.0
を実行すると、masterブランチとdevelopブランチにマージして、masterブランチにタグをつけてくれます。
タグはreleaseブランチの名前が付くようです。
また、releaseブランチは削除されます。
この作業が終わったらgit push --allですべてリモートリポジトリにあげます。
緊急性の高いバグなどを修正する際に利用します。 master ブランチからhotfixブランチを切ります。
$ git flow hotfix start v1.1
$ git add . $ git commit -m "hogehoge" $ git flow hotfix finish v1.1
でmasterとdevelopブランチにマージされて、masterブランチにタグが付きます。
Cmderを利用しているのですがreleaseブランチを終了させて、masterブランチにマージする際のコメント記入を何もしないで:wqとすると画面がバグります。 少し書き換えればバグらずに済むのですが、ちょっとめんどうなのでどうにかして直したいですね…
コマンドラインで Git Flow をインストールして使ってみる git-flow を試す git-flow cheatsheet git-flow コマンド説明和訳
個人的に便利なツールだと思います。 この記事には載っていないコマンドもあり、理解するにはまだ勉強が足りないようです。
概要 一般的には、ソースコード管理・共同開発ツールとしてGithubは使われますが、 プロジェクト進行・タスク(チケット) 管理ツールとしても、Githubは非常に有効です。 Githubを使うことによって、研究のPDCAサイクルを行うことができます。 この記事では、ソースコードの管理のためではなく、Issueを使いこなすツールとしてGithubを紹介します。昨今の研究スピードでは、タスク管理による取捨選択はMustなはずです。 メリットについて説明したのち、Githubの実際の使い方を示します。 メリット プロジェクトを遂行する仕事をIssueという単位のチケットで管理することによって、 タスクの小分け・具体化がされるので、日々のタスクがわかる。 Project機能によって、タスクの進捗を可視化できるので、個々の作業の進み具合を共有できるので作業が重複しない。 開発のログ・思考プロセスが１つのツールに残せるので、共有、引継ぎ にかかる作業が少ない。 Issueそのものについてはこちらの書籍が非常に参考になります。 使い方 初期設定 まずはリポジトリを作ります。リポジトリの作り方はその辺にドキュメントがあるでしょう。 研究のPDCAサイクル PDCAサイクルの順で説明します。 Plan: 計画 1. Issueをつくる。 何はともあれ Issueを作ります。Issueは直訳すると課題, IssuesはTO-DOリストみたいなものです。 プロジェクトに今ある課題を全部Issueとして作りましょう。 Issues タブからNew Issueを選択 Title にはわかりやすい端的な名前。Descriptionには課題の内容、WhatとWhyを書きます。 他のレポジトリのIssueの書き方を参考にしたらいいと思います。 Issue に強弱をつける。 IssueにLabelsをつけて、研究の必須度、タスクの種類に分けるのもいいですし、 Milestonesをつけて、Issueの期日を設定するのもよいです。 2. プロジェクト機能を活用する Issueを作ったら、次はどのIssueから取り組んでいくかを決めます。 ProjectsタブからCreate new projectを選択。 適当なTitleをつける. テンプレートは個人作業ならAutomated Kanban, 複数人で開発するなら(コードレビューを行ったりする)なら Automated Kanban with reviews を選択すれば丸いです。 最初は何もないので、右のAdd cardsよりIssueをとってきてTo doに追加します。 (自動でカード追加するトリガーというものも設定できるみたいです.) 取り組むIssueが決まったら、そのIssueをIn progressに移動します。 これでPlanは完了しました。 Do: 開発する。 Issueに取り組みます。 Issueがプログロム開発に関係していて, Githubの本来の機能(ソースコード管理)を使う場合の具体的なコマンドは他を参考にしてください。ここでは概略だけ。 IssueのIDを確認する (IssueのIDをユニークに決定されます) 作業ブランチの名前にIssueのIDをつける. ユニークなIDを使って, branchを作ります。 git checkout -b #12_test 開発する。 これでDoは完了します。 Check: 確認・レビューする。 Issueの内容に沿ったことができたか、振り返って確認します。 ここでもプログラムに関わるところは、概略のみ示します。 1. オリジンの作業ブランチにプッシュ git add . git commit -m “add/implementation_hogehoge” git push origin #12_test // githubリモートの#12_test というブランチにpush. オリジンの作業ブランチをMasterブランチにマージ Create pull request pull requestの内容は実験ノートを書くのもいいですし、共同開発できるならちゃんとフォーマットにのって書いたほうがいいですね。何も書かないのもありですかね。 - レビューをお願いする ReviewersにGithubのUserを設定して、レビューしてくれる人を設定します。レビュワーから認可してもらえないと、Merge Pull Requestが送れないはずです。 AssigneesはPull Requestの責任者？担当者ってイメージです。 b. Merge Pull Request レビュワーの認可が終わったり、Masterブランチとのコンフリクトがなければ無事にMerge pull requestができるはずです。 これでCheckは終わりです。 Action: 再計画。 とりあえず ProjectのIssuesを In Progressから、Doneに移動させましょう。 また、Checkの内容を踏まえて、新しいIssueを作ったり、Issueの優先度を見直したりしてください。 追記 Slackを導入している研究室なら、SlackにGithubのアプリを導入することによって通知がSlackにいくようになります。ちょっとした議論等はその辺でやることが多いです。
一般的には、ソースコード管理・共同開発ツールとしてGithubは使われますが、 プロジェクト進行・タスク(チケット) 管理ツールとしても、Githubは非常に有効です。 Githubを使うことによって、研究のPDCAサイクルを行うことができます。
この記事では、ソースコードの管理のためではなく、Issueを使いこなすツールとしてGithubを紹介します。昨今の研究スピードでは、タスク管理による取捨選択はMustなはずです。
メリットについて説明したのち、Githubの実際の使い方を示します。
日々のタスクがわかる
作業が重複しない
共有、引継ぎ
Issueそのものについてはこちらの書籍が非常に参考になります。
まずはリポジトリを作ります。リポジトリの作り方はその辺にドキュメントがあるでしょう。
PDCAサイクルの順で説明します。
何はともあれ Issueを作ります。Issueは直訳すると課題, IssuesはTO-DOリストみたいなものです。 プロジェクトに今ある課題を全部Issueとして作りましょう。
IssueにLabelsをつけて、研究の必須度、タスクの種類に分けるのもいいですし、 Milestonesをつけて、Issueの期日を設定するのもよいです。
Issueを作ったら、次はどのIssueから取り組んでいくかを決めます。
Issueに取り組みます。
Issueがプログロム開発に関係していて, Githubの本来の機能(ソースコード管理)を使う場合の具体的なコマンドは他を参考にしてください。ここでは概略だけ。
IssueのIDを確認する (IssueのIDをユニークに決定されます)
作業ブランチの名前にIssueのIDをつける. ユニークなIDを使って, branchを作ります。
IssueのID
git checkout -b #12_test
開発する。 これでDoは完了します。
Issueの内容に沿ったことができたか、振り返って確認します。
ここでもプログラムに関わるところは、概略のみ示します。 1. オリジンの作業ブランチにプッシュ
git add . git commit -m “add/implementation_hogehoge” git push origin #12_test // githubリモートの#12_test というブランチにpush.
ReviewersにGithubのUserを設定して、レビューしてくれる人を設定します。レビュワーから認可してもらえないと、Merge Pull Requestが送れないはずです。 AssigneesはPull Requestの責任者？担当者ってイメージです。
b. Merge Pull Request レビュワーの認可が終わったり、Masterブランチとのコンフリクトがなければ無事にMerge pull requestができるはずです。
これでCheckは終わりです。
とりあえず ProjectのIssuesを In Progressから、Doneに移動させましょう。 また、Checkの内容を踏まえて、新しいIssueを作ったり、Issueの優先度を見直したりしてください。
追記
Git,GitHubの基礎を備忘録的にまとめてみました。 環境 virtualbox 5.2.26 vagrant 2.1.2 mac 10.14.2 Gitとは バージョン管理システム システム開発での区切りを記録して管理出来るもの。 誰がどのような意図で、どのような変更をしたかなどが明確に分かる。 Gitを導入する事で以下のメリットが生まれる。 ・コードとコメントを分けられて、履歴が分かりやすく管理出来る。 ・任意のバージョンを指定でき、即座にバージョンを切り替えられる。 ・ローカルとリモートで管理する事で複数人での開発に役立つ。 Gitを使った開発Flow ローカルリポジトリ作成 # 任意のディレクトリで git init リモートリポジトリをclone or pull cd [ローカルリポジトリ] git clone [リモートリポジトリのパス] or cd [ローカルリポジトリ] git pull [リモートリポジトリのパス] ローカルに開発用ブランチを追加して、チェックアウト git checkout -b [開発用ブランチ名] 開発してadd〜commit # ファイルをインデックスに追加 git add [file_name or dir_name] # コミット git commit -m "comment" ローカルの開発用リポジトリをリモートの開発用リポジトリにプッシュ # originという名前でリモートリポジトリを追加 git remote add origin [リモートリポジトリの開発用ブランチのパス] # 登録したリモートリポジトリにローカルリポジトリをプッシュ git push origin [開発用ブランチ名] # git push -u origin [開発用ブランチ名] で次からブランチ名省略可 # git remote rm origin で登録されているリモートリポジトリを削除 プルリクエストを送る→マージorボツ githubだとメニューからプルリクエスト選択して、リクエストを送る。 OKならマージし、新バージョン。 リモートをローカルリポジトリのマスターにプル git pull [リモートリポジトリのパス] 基本コマンド 初期設定 ユーザー名、メールアドレス登録 git config --global user.name [ユーザー名] git config --global user.email [メールアドレス] エイリアス登録 コマンドからも出来るが.gitconfigを弄ったほうが楽。 .gitconfig [user] name = [name] email = [email] [alias] co = checkout br = branch st = status cm = commit sh = show cp = cherry-pick ad = add lo = log 履歴関連 変更の履歴を表示 git status [オプション] #オプションにディレクトリ等を指定でそのディレクトリ内の変更表示 コミットの履歴を表示 git log [オプション] # オプション --numstat # ファイル毎の追加削除行数を表示 --since="[日数] days ago" --until="[年/月/日]" # 日付指定 --graph # 見やすく表示 --merges # マージのみ --all # 全ブランチ ブランチ関連 ブランチ表示 git branch ブランチ切り替え git checkout [ブランチ名] ブランチ作成と共にチェックアウト git checkout -b [ブランチ名] ブランチ削除 # HEADにマージしたブランチ削除 git branch --delete [ブランチ名] # マージしたかを問わずに削除 git branch -D [ブランチ名] タグ関連 タグ表示 # タグ一覧表示 git tag # 注釈も表示 git tag -n タグ追加 git tag [タグ名] 注釈付きタグ追加 git tag -a [タグ名] -m "コメント" # 以前のコミットにタグを付ける。 git tag -a [タグ名] -m "コメント" [コミット] タグ削除 git tag -d [タグ名] タグをプッシュ タグはブランチをプッシュした時に反映されないため、別でプッシュする。 tag push origin --tags GitHubとSSH接続 SSH (Secure Shell) プロトコルを利用してターミナルから安全にGitHubに接続する。 SSHは秘密鍵・公開鍵を使用した鍵認証によって、 クライアントとリモートマシンの通信を暗号化し安全にコマンドを実行できる。 まず、簡単なコマンドから2つの鍵を作る。 # sshのディレクトリに移動 cd ~/.ssh # 鍵を作成 ssh-keygen [オプション] ssh-keygen -t rsa -b 4096 -t rsa = 鍵の種類。他より強固。 -b 4096 = 鍵の長さ。rsaは4096bit 鍵名とパスフレーズを入力し、鍵が作成される。 GitHubに公開鍵をアップする https://github.com/settings/keys からGitHub上に、公開鍵をアップする。 configファイルに鍵情報を登録 sshディレクトリ内のコンフィグファイルに鍵情報を記載する。 ※configファイルが無ければ作る。 config Host github github.com HostName github.com User git IdentityFile ~/.ssh/[鍵の名前] これで、下記コマンドでGitHubとの接続を出来る。 ssh -T github パスフレーズを入力し、 Hi [ユーザー名]! You've successfully authenticated, but GitHub does not provide shell access. と表示されればOK! これで、ターミナルからGitHubにSSH接続出来る。
Git,GitHubの基礎を備忘録的にまとめてみました。
virtualbox 5.2.26 vagrant 2.1.2 mac 10.14.2
システム開発での区切りを記録して管理出来るもの。 誰がどのような意図で、どのような変更をしたかなどが明確に分かる。 Gitを導入する事で以下のメリットが生まれる。
・コードとコメントを分けられて、履歴が分かりやすく管理出来る。 ・任意のバージョンを指定でき、即座にバージョンを切り替えられる。 ・ローカルとリモートで管理する事で複数人での開発に役立つ。
# 任意のディレクトリで git init
cd [ローカルリポジトリ] git clone [リモートリポジトリのパス] or cd [ローカルリポジトリ] git pull [リモートリポジトリのパス]
git checkout -b [開発用ブランチ名]
# ファイルをインデックスに追加 git add [file_name or dir_name] # コミット git commit -m "comment"
# originという名前でリモートリポジトリを追加 git remote add origin [リモートリポジトリの開発用ブランチのパス] # 登録したリモートリポジトリにローカルリポジトリをプッシュ git push origin [開発用ブランチ名] # git push -u origin [開発用ブランチ名] で次からブランチ名省略可 # git remote rm origin で登録されているリモートリポジトリを削除
githubだとメニューからプルリクエスト選択して、リクエストを送る。 OKならマージし、新バージョン。
git pull [リモートリポジトリのパス]
git config --global user.name [ユーザー名] git config --global user.email [メールアドレス]
コマンドからも出来るが.gitconfigを弄ったほうが楽。
[user] name = [name] email = [email] [alias] co = checkout br = branch st = status cm = commit sh = show cp = cherry-pick ad = add lo = log
git status [オプション] #オプションにディレクトリ等を指定でそのディレクトリ内の変更表示
git log [オプション]
# オプション --numstat # ファイル毎の追加削除行数を表示 --since="[日数] days ago" --until="[年/月/日]" # 日付指定 --graph # 見やすく表示 --merges # マージのみ --all # 全ブランチ
git branch
git checkout [ブランチ名]
git checkout -b [ブランチ名]
# HEADにマージしたブランチ削除 git branch --delete [ブランチ名] # マージしたかを問わずに削除 git branch -D [ブランチ名]
# タグ一覧表示 git tag # 注釈も表示 git tag -n
git tag [タグ名]
git tag -a [タグ名] -m "コメント" # 以前のコミットにタグを付ける。 git tag -a [タグ名] -m "コメント" [コミット]
git tag -d [タグ名]
タグはブランチをプッシュした時に反映されないため、別でプッシュする。
tag push origin --tags
SSH (Secure Shell) プロトコルを利用してターミナルから安全にGitHubに接続する。 SSHは秘密鍵・公開鍵を使用した鍵認証によって、 クライアントとリモートマシンの通信を暗号化し安全にコマンドを実行できる。
まず、簡単なコマンドから2つの鍵を作る。
# sshのディレクトリに移動 cd ~/.ssh # 鍵を作成 ssh-keygen [オプション] ssh-keygen -t rsa -b 4096 -t rsa = 鍵の種類。他より強固。 -b 4096 = 鍵の長さ。rsaは4096bit
鍵名とパスフレーズを入力し、鍵が作成される。
https://github.com/settings/keys からGitHub上に、公開鍵をアップする。
sshディレクトリ内のコンフィグファイルに鍵情報を記載する。 ※configファイルが無ければ作る。
Host github github.com HostName github.com User git IdentityFile ~/.ssh/[鍵の名前]
これで、下記コマンドでGitHubとの接続を出来る。
ssh -T github
パスフレーズを入力し、
Hi [ユーザー名]! You've successfully authenticated, but GitHub does not provide shell access.
と表示されればOK!
これで、ターミナルからGitHubにSSH接続出来る。
何これ？ gitでリモートに作ったブランチ(dev-branch)をローカルに持ってきて開発したい そのコマンドを毎回忘れる 個人メモですが需要あればどうぞ コマンド git fetch git checkout -b dev-branch origin/dev-branch あ、これだけか。こんだけでした。 なぜ毎回忘れるのか 「なんか色々しないといけなかったような気がした」。 そんなことなかったですね。
あ、これだけか。こんだけでした。
「なんか色々しないといけなかったような気がした」。 そんなことなかったですね。
Gitにpushしたリポジトリを他の人へ共有したい時｡ リポジトリのURLを送って！と言われますね(^^) リポジトリのURLはどこで分かるのだろう？？とGitをポチポチしていて 分かったのでメモです｡ まずは Gitの自分のリポジトリ(your repositories)画面に移動します｡ URLを知りたいリポジトリを選んでください｡リポジトリをクリックすると､ ｢Clone or download｣という緑のボタンが画面右の方に有るので そのボタンをクリックしてください｡ クリックするとなにかアドレスが出てきますが､今回はHTTPSの方のURLが欲しいので Use HTTPSをクリックすると､ いつものhttpsから始まる見慣れたURLが出てきます(^o^)ホッ URL右横のコピーボタンを押せばコピーできます｡ その後､困ったことがありました汗 今回の操作により､gitにpushする時の使用が変わってしまっていたようで､push時にパスワード聞かれるようになってしまいました｡ HTTPSに変更した方は､SSHに戻しましょう｡ (参考https://qiita.com/rorensu2236/items/df7d4c2cf621eeddd468)
Gitにpushしたリポジトリを他の人へ共有したい時｡ リポジトリのURLを送って！と言われますね(^^)
リポジトリのURLはどこで分かるのだろう？？とGitをポチポチしていて 分かったのでメモです｡
まずは Gitの自分のリポジトリ(your repositories)画面に移動します｡ URLを知りたいリポジトリを選んでください｡リポジトリをクリックすると､
｢Clone or download｣という緑のボタンが画面右の方に有るので そのボタンをクリックしてください｡
クリックするとなにかアドレスが出てきますが､今回はHTTPSの方のURLが欲しいので Use HTTPSをクリックすると､ いつものhttpsから始まる見慣れたURLが出てきます(^o^)ホッ URL右横のコピーボタンを押せばコピーできます｡
その後､困ったことがありました汗 今回の操作により､gitにpushする時の使用が変わってしまっていたようで､push時にパスワード聞かれるようになってしまいました｡ HTTPSに変更した方は､SSHに戻しましょう｡
(参考https://qiita.com/rorensu2236/items/df7d4c2cf621eeddd468)
はじめに 職場で使用していたPCが重くなってきて、新しいPCに買い替えました。 無事に移行は完了しましたが、Sourcetreeでプッシュやプルしている時に毎回パスワードを聞かれるようになっていました。 前提 SourcetreeでGitHubのログインはSSHで済んでいる。 SSHでSourceTreeにクローン済み git@github.com:eyemovic/hoge.git githubのsshのkey設定などは済んでいる ~/.ssh配下のpermissionなども正しい 問題 プッシュしようとすると、 gouda:hoge-branch gouda$ git push origin hoge-branch 公開鍵のパスワードを聞かれる(毎回) Enter passphrase for key '/Users/gouda/.ssh/id_rsa 解決方法 SSHキーを追加してあげる gouda:hoge-branch gouda$ ssh-add ~/.ssh/id_rsa SSHキーのパスワードを聞かれるので入力してあげる Enter passphrase for key '/Users/gouda/.ssh/id_rsa プッシュしてみる gouda:hoge-branch gouda$ git push origin hoge-branch パスワードを聞かれずに、プッシュできました！ Everything up-to-date おわりに 設定する時間がなく、とりあえず毎回パスワードを入力していたので、ようやく改善されてよかったです。 間違えているところなどあればコメントをお願いいたします。
職場で使用していたPCが重くなってきて、新しいPCに買い替えました。 無事に移行は完了しましたが、Sourcetreeでプッシュやプルしている時に毎回パスワードを聞かれるようになっていました。
SSHでSourceTreeにクローン済み git@github.com:eyemovic/hoge.git
git@github.com:eyemovic/hoge.git
githubのsshのkey設定などは済んでいる
~/.ssh配下のpermissionなども正しい
プッシュしようとすると、 gouda:hoge-branch gouda$ git push origin hoge-branch
gouda:hoge-branch gouda$ git push origin hoge-branch
公開鍵のパスワードを聞かれる(毎回) Enter passphrase for key '/Users/gouda/.ssh/id_rsa
Enter passphrase for key '/Users/gouda/.ssh/id_rsa
SSHキーを追加してあげる gouda:hoge-branch gouda$ ssh-add ~/.ssh/id_rsa SSHキーのパスワードを聞かれるので入力してあげる Enter passphrase for key '/Users/gouda/.ssh/id_rsa
gouda:hoge-branch gouda$ ssh-add ~/.ssh/id_rsa
パスワードを聞かれずに、プッシュできました！ Everything up-to-date
Everything up-to-date
設定する時間がなく、とりあえず毎回パスワードを入力していたので、ようやく改善されてよかったです。
間違えているところなどあればコメントをお願いいたします。
login $ heroku login herokuの接続先URLを 確認 $ git remote -v 登録 $ git remote add heroku https://git.heroku.com/*******.git 変更 $ git remote heroku set-url https://git.heroku.com/*******.git （***はrepository名） heroku URLの確認 https://dashboard.heroku.com/apps -> Personal/各repository/Settings/Info : Heroku Git URL push $ git push heroku master migration $ heroku run rails db:migrate アプリ起動 $ heroku open
$ heroku login
$ git remote -v
$ git remote add heroku https://git.heroku.com/*******.git
$ git remote heroku set-url https://git.heroku.com/*******.git （***はrepository名）
https://dashboard.heroku.com/apps -> Personal/各repository/Settings/Info : Heroku Git URL
Heroku Git URL
$ git push heroku master
$ heroku run rails db:migrate
$ heroku open
TL;DR git rmだと過去の履歴は消えません。git filter-branchを使いましょう。 https://qiita.com/go_astrayer/items/6e39d3ab16ae8094496c はじめに 例えばパスワードファイルなんかを間違ってcommit & pushしたときに、リポジトリから完全に消したいといった事があるかと思います。その時に「git ファイル 消す 方法」などでググると先頭の方に git rm --cache とか解説している記事が見つかります。しかし、コレだとダメです。 どうダメなのか gitの用語に詳しくないので解説が曖昧になります。 git rmだと、"ファイルを消した"という記録を追記します。なので最新のcommitからは見えなくなります。一方で過去の履歴には相変わらず残っています。githubならcommitというとこを見ていけば直ぐに見つかります。 その為、上のURLにある通りの形で実行して行く必要があります。 間違ってコミットしないようにするには .gitignoreというファイルに、ファイル名を書き込むことで回避できます。詳しくはgitignoreで検索してみてください。 余談 本件、"git ファイル 完全に消す 方法"とかで検索すれば先頭に上の記事が出てくるのですが、git rmを勧めるTechAc◯ademyとかいうとこの記事も出てくるんですよね。それに初心者だと検索方法もわからないでしょうし、"git ファイル 消す 方法"とかで検索して安易にgit rmだけ実行して後で大惨事になりそうです。 とりあえず"git rm"と書いてあるメディアは信用しないほうが良いと思います。
git rmだと過去の履歴は消えません。git filter-branchを使いましょう。 https://qiita.com/go_astrayer/items/6e39d3ab16ae8094496c
例えばパスワードファイルなんかを間違ってcommit & pushしたときに、リポジトリから完全に消したいといった事があるかと思います。その時に「git ファイル 消す 方法」などでググると先頭の方に git rm --cache とか解説している記事が見つかります。しかし、コレだとダメです。
git rm --cache
gitの用語に詳しくないので解説が曖昧になります。 git rmだと、"ファイルを消した"という記録を追記します。なので最新のcommitからは見えなくなります。一方で過去の履歴には相変わらず残っています。githubならcommitというとこを見ていけば直ぐに見つかります。
その為、上のURLにある通りの形で実行して行く必要があります。
.gitignoreというファイルに、ファイル名を書き込むことで回避できます。詳しくはgitignoreで検索してみてください。
本件、"git ファイル 完全に消す 方法"とかで検索すれば先頭に上の記事が出てくるのですが、git rmを勧めるTechAc◯ademyとかいうとこの記事も出てくるんですよね。それに初心者だと検索方法もわからないでしょうし、"git ファイル 消す 方法"とかで検索して安易にgit rmだけ実行して後で大惨事になりそうです。
とりあえず"git rm"と書いてあるメディアは信用しないほうが良いと思います。
Git運用でGit Flowを採用することにしたので SourcetreeのGit Flowをつかった開発フローを整理しました。 実現したいこと Gitに慣れていないメンバーでも無理なく運用可能なこと Git, Git Flowの操作はSourcetreeですべて実行 ただし、GitおよびGit Flowの概念は理解していることが前提 Github上でコードレビューを実施 featureからdevelopへのPull Requestをレビュー コードはレビューワーがマージ SourcetreeにGit Flowが表示されていない場合 ツールバー上で右クリックし、ツールバーのカスタマイズを選択 Git Flowをドラッグ＆ドロップしツールバーに追加 開発フロー リポジトリの初期化 はじめてGit Flowボタンを押すとリポジトリの初期化画面が表示されます。 運用ルールに合わせてカスタマイズすることができます。 基本的にデフォルト設定のままで問題ありません。 機能開発開始 Git Flowボタンを押すと推奨するアクションが表示されます。 開発着手時は「新規フィーチャーを開始」をクリックします。 フィーチャー名を入力してOKを押すとdevelopからfeatureが作成されます。 この場合はfeature/sampleが作成されます。 レビュー 実装が完了したらfeatureをプッシュして、Github上でプルリクエストを作成します。 レビューが完了したらGithub上でマージします。 次のステップで自動的にブランチが削除されるので、ここではブランチを削除する必要はありません。 機能開発終了 Git Flowボタンを押し、現在のブランチを終了ボタンをクリックします。 ブランチを削除を選択した状態でOKをクリックするとローカルとリモートのブランチが自動的に削除されます。 最後にdevelopでソースコードをpullします。 このときに「マージではなくリベースする」にチェックを入れます。 featureの変更内容はすべてdevelopに取り込まれているので、履歴はこのようになります。 リリース Git Flowボタン押し、新規リリース開始をクリックします。 リリースバージョンを入力し、OKを押すとdevelopからreleaseが作成されます。 リリース作業が完了したらGit Flowボタンを押し、現在のブランチを終了をクリックします。 タグのメッセージを入力とブランチのプレビューの確認します。 問題ないことを確認してOKを押すとrelease は master, develop の両方にマージされます。 featureのときと同様にGithub上でマージとすることも可能です。 まとめ Sourcetreeを使用することで、git, git-flowのコマンドを知らなくてもGit Flowで開発をおこなうことができます。 Github上でのコードレビューも問題なくおこなうことができます。 ローカル/リモートのブランチの削除、タグの追加がgit-flowでされるので、オペレーションミスが少なくなります。 参考記事 A successful Git branching model
Git運用でGit Flowを採用することにしたので SourcetreeのGit Flowをつかった開発フローを整理しました。
ツールバー上で右クリックし、ツールバーのカスタマイズを選択
Git Flowをドラッグ＆ドロップしツールバーに追加
はじめてGit Flowボタンを押すとリポジトリの初期化画面が表示されます。 運用ルールに合わせてカスタマイズすることができます。 基本的にデフォルト設定のままで問題ありません。
Git Flowボタンを押すと推奨するアクションが表示されます。 開発着手時は「新規フィーチャーを開始」をクリックします。
フィーチャー名を入力してOKを押すとdevelopからfeatureが作成されます。 この場合はfeature/sampleが作成されます。
実装が完了したらfeatureをプッシュして、Github上でプルリクエストを作成します。
レビューが完了したらGithub上でマージします。 次のステップで自動的にブランチが削除されるので、ここではブランチを削除する必要はありません。
Git Flowボタンを押し、現在のブランチを終了ボタンをクリックします。
ブランチを削除を選択した状態でOKをクリックするとローカルとリモートのブランチが自動的に削除されます。
最後にdevelopでソースコードをpullします。 このときに「マージではなくリベースする」にチェックを入れます。
featureの変更内容はすべてdevelopに取り込まれているので、履歴はこのようになります。
Git Flowボタン押し、新規リリース開始をクリックします。 リリースバージョンを入力し、OKを押すとdevelopからreleaseが作成されます。
リリース作業が完了したらGit Flowボタンを押し、現在のブランチを終了をクリックします。 タグのメッセージを入力とブランチのプレビューの確認します。 問題ないことを確認してOKを押すとrelease は master, develop の両方にマージされます。 featureのときと同様にGithub上でマージとすることも可能です。
A successful Git branching model
git コマンドのインストール wget https://github.com/git/git/archive/v2.21.0.zip yum install gcc openssl-devel curl-devel expat-devel make make install
git コマンドのインストール
wget https://github.com/git/git/archive/v2.21.0.zip yum install gcc openssl-devel curl-devel expat-devel make make install
