【第0回】電流が見える電子回路シミュレータとは?

次回の記事

準備中です……

前回の記事

terapotan.hatenablog.jp

連載記事一覧

  terapotan.hatenablog.jp

電子回路シミュレータって何だ?

あなたは、電子回路シミュレータというものを知っているでしょうか。
普通電子回路を作ったときの動きは、実際に部品を買ってきて、回路を作らないと分かりません。

しかし、部品を買うのにもお金がかかりますし、回路を作るのにも時間がかかります。しかも、回路の組み方次第では部品を壊してしまうかもしれません。

……面倒くさいですよね。正直。「何とか部品を買わずに電子回路の動きを見る方法はないか」と思うと思います。

そんな時に使うのが「電子回路シミュレーター」です。その名の通り、自分で作った電子回路をパソコン上でシミュレーションすることができます。パソコン上でシミュレーションしているだけですから、部品を買う必要もありません。部品を壊してしまう恐れもありません。

LTspice

有名な電子回路シミュレーターとしてよく挙げられるのが、「LTspice」という電子回路シミュレータです。

このシミュレータ―は無料で、しかも機能の制限なく使用することが出来ます。

電子回路の解析に関する機能が豊富で、電流・電圧の測定はもちろん、周波数特性を求めたり、部品のパラメータを変えながら測定を行ったり、といった様々な解析を行うことが出来ます。

ですが、本格的な解析が行える反面、初心者にとってはとっつきにくいものになってしまっているのが現状です。

LTspiceでシミュレーションを行うには、次の手順を踏む必要があります。

  1. 回路図を作成する
  2. コマンドを入力する
  3. シミュレーションを行う
  4. 電流・電圧を測定したいところをクリックする

実際にシミュレーションを行った結果

「回路図作って、実行ボタンを押すだけでシミュレーション実行されないの?」と思われるかもしれませんが、そうではありません。
LTspiceでシミュレーションを実行するには、回路を作成してから「どのような条件でシミュレーションするのか」を指定してあげる必要があります。

また、回路中の電流や電圧等を測るには、測定したいポイントをクリックする必要があります。

CircuitSimulatorApplet

ここで登場するのが、今回の連載で解説する「CircuitSimulatorApplet」という回路シミュレーターです。

CircuitSimulatorAppletの外観

Web上で実行することが出来ます。下のリンクから、「CircuitSimulatorApplet」が実行できるページへ移動することができます。

http://www.falstad.com/circuit/circuitjs.htmlwww.falstad.com

オフラインで実行できるCircuitSimulatorAppletもあります。

www.falstad.com

上のリンク画像

上の画像の赤枠で囲っているリンクをクリックすると、ソフトウェアがダウンロードされます。(Macをお使いの方は、緑色の枠で囲っている所をクリックしてください。)

電流と電圧が一目で分かる

CircuitSimulatorApplet上でシミュレーションを行うには、次の手順を踏む必要があります。

  1. 回路を作成する
  2. 右上の「RUN」ボタンを押す

右上のRUNボタン

LTspiceで必要だった「コマンドを入力する」という操作は必要ありません。回路を作って、RUNというボタンを押すだけでいいのです。

さらに、LTspiceではクリックしないと見ることが出来なかった電流や電圧も一目で見ることができます。

実行時のアニメーション

電流の流れが、黄色い四角で表現されています。

スイッチや部品の値を直感的に変えられる

電子回路では「電圧の値を上げたらどうなるのだろう?」「抵抗の値を変えたらどうなるのだろう?」という疑問が浮かぶ場面がよくあります。

CircuitSimulatorAppletでは、下のアニメーションのようにクリック一つで、回路が動いている最中にスイッチを切ったり、電圧の値を変えたりすることができます。

直感的に変えられる部品の値

回路の動作が一目で分かる

CircuitSimulatorAppletは、上二つのような特徴を持っているため、電子回路の動作を理解する手助けをしてくれます。

例えば、下の図のような電子回路を考えてみましょう。

回路図

抵抗値の異なる抵抗が、二つ並列接続されています。

オームの法則より、抵抗の値が小さいければ小さいほど、抵抗に流れる電流は大きくなるはずです。

この回路をCircuitSimulatorApplet上でシミュレートしてみると、下のような結果になります。

シミュレート結果

抵抗値の小さい抵抗のほうが、黄色い四角の移動が速いのが分かると思います。

回路図を作って「RUN」ボタンを押すだけで、特に何もしなくてもオームの法則を一目で確認することが出来るのです。

最後に

今回は、CircuitSimulatorAppletとはどんなものなのか、について解説しました。
本文中では、CircuitSimulatorAppletの魅力を多く解説していますが、決してLTspiceがダメなソフトだというわけではありません。

むしろ、直感的に操作できるCircuitSimulatorAppletと、本格的な解析が出来るLTspiceを組み合わせて使えばより便利な回路シミュレーションを行えると思います。

次回予告

次回は、CircuitSimulatorAppletの基本的な使い方について解説します。

う-ん、よく分からん!

この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。

参考文献

LTspice関連

LTspiceの使い方について書かれている本です。これを読めば、とりあえずLTspiceは使えるようになります。

次回の記事

準備中です……

前回の記事

terapotan.hatenablog.jp

連載記事一覧

  terapotan.hatenablog.jp

【第0回】この連載を読む前に

大まかな内容

この連載(回路シミュレータCircuitSimulatorAppletを使ってみよう!)では、「Circuit Simulator Applet」という電子回路シミュレータの使い方について解説していく予定です。

この連載の読み方

コラム

記事を読んでいくと、下のようなコラムが出てくることがあります。

Column:コラム

これは、文字通りコラムです。
コラムですから、必ずしも読んで理解する必要はありません。
「あーわからん」と思うのであれば、どんどん読み飛ばしてください。

番外編

番外編も同じく「読むのが面倒くさい」「早く次に進みたい」と思うのであれば、読み飛ばしても構いません。

コラム・番外編ともに本文よりも難しい内容が入っている場合が多いです。

検索する、他の書籍・サイトをあたる

「この連載だけで勉強しなければならない」という決まりはありません。
いまいちピンとこない部分があれば、他の資料を使って勉強しても良いのです。

質問する

記事を読んでいくと、「どうしてこうなるんだ?」と言った疑問が出てくると思います。
そういう時は、ぜひ私に質問してください。
下のコメント欄からでも構いませんし、Twitterでも構いません。
質問内容を公開したくないのであれば、メールで送るという手もあります。

メールアドレスは、ページ右上に記載しています。

その他

連載は、全15回の予定となっています。 第1回の記事、連載記事一覧は下のリンクからご覧ください。

次回の記事

準備中です……

連載記事一覧

準備中です……

ソフト作り=プログラミングではない!

連載記事一覧

  terapotan.hatenablog.jp

あなたは、ソフト作りに必要な要素は何だと思いますか?
「プログラミング」――と答えるでしょうか。
もしそうなら「プログラミング」をどんどん勉強して極めれば、多くの人に使われるすごいソフトが作れそうな気がします。

……が、現実はそうではありません。それ以外にもたくさんの要素があるのです。
はぁ!?プログラミング出来れば、すごいソフト作れるんじゃないの?!――と思った方こそ、この記事をご覧ください。

プログラミングってそもそも何だ?

話を進める前に一つ解決しておかなくてはいけない疑問があります。

「プログラミングが出来る」というのは、いったいどういう状態を指すのでしょう?

人によって意見が分かれるところだとは思いますが、ここでは次のように定義します。

具体的にコンピュータにやらせたいこと(仕様)が決まっていて、それをプログラミング言語にして、実際にコンピュータ上で動くプログラムを作れる状態。

例えば、次のような仕様があったとします。

  • 「二つ数字を入力して、二つの数字を足した数字を表示しなさい」

上の定義で言う「プログラミングが出来る」というのは、上の仕様から

#include<iostream>

int main(void){
    int a,b;
    std::cin >> a >> b;
    std::cout << a + b;
    return 0;
}

上のようなプログラムを作れる状態を指しています。

プログラミングで出来ること

先ほど挙げた例を見れば分かる通り、「プログラミングが出来る」状態で何かしらのプログラムを作るためには、具体的な指示が必要になります。

ソフトというのは、上で見た小さなプログラムが集まって作られます。

ですから、この状態でソフトを作るには、ソフトに関するありとあらゆることについて具体的な指示が必要になります。

ですが、普通「どんなソフトを作りたい?」と聞かれて思い浮かぶのは、

  1. この作業を自動化してくるソフトを作りたい
  2. 爽快感のあるゲームを作りたい
  3. 面白いゲームを作りたい

という曖昧な指示でしょう。
ソフトを作るためには、曖昧な指示を具体的な指示に変換しなくてはなりません。

箇条書きの1であれば、自動化したい具体的な作業が分かれば何とかなるかもしれません。
しかし、2や3はどうでしょうか。爽快感・面白いというのは人によって違います。

これを具体的な指示に変換するのは、非常に難しいことです。

ソフトはプログラムだけで作れるのか?

素材の問題

曖昧な指示を具体的な指示に変換できたとしても、さらなる問題が立ちはだかります。

それはイラストや音楽などの素材が必要だ、ということです。
ツール系であれば、そこまで必要にはならないかもしれませんが、ゲームであれば数多く能素材が必要になります。

自分で作るのであれば、イラストや音楽を作れるような勉強をしなくてはいけませんし、そうでなければ、人に頼むかどこかの無料素材集から持ってこなくてはなりません。

プロジェクトを管理する

趣味で作っているソフトであれば、いつソフトが完成しようと構わないかもしれませんが、人に頼まれて作っているソフトであれば、期限内に完成させなければなりません。

どのようにソフトを期限内に完成させなければいけないか、というのも考えなくてはいけません。

宣伝

自分だけが使うソフトであれば、宣伝なんてしなくてもいいでしょうが、多くの人に使ってもらいたいなら、宣伝の方法を考える必要があります。

結局……

これ以外にも、ソフト作りに必要な要素はたくさんあります。

……もうお分かりでしょうか。
プログラミングはソフト作りの一部分でしかないということです。

書籍にあるようなプログラミングの問題を解いていけば、確かにプログラミングの能力を高めるのには役立つでしょう。ですが、プログラミングの能力が高まったからといって、ソフト作りの能力が高まるわけではないのです。悲しいことに。

ではどうすればいい?

プログラミングを勉強してもだめなのなら、いったいどうすればいいのでしょう?

ソフトを作ればいいのです。

作りたいと思うソフトを作ればいいのです。

ソフト作りの能力を高めたいのなら、ソフトを作ればいいのです。
とは言っても最初は、作るのに何か月もかかるソフトではなく、数日や1~2週間くらいで作り終わるソフトから作っていくのがいいでしょう。

いや、でも……

ソフト作りにはたくさんの要素が必要なんでしょう?じゃあ、プログラミング以外に必要な要素教えて!全部勉強するから!――説明を聞いて、こう思う人もいるかもしれません。

気持ちは分かります。中途半端に勉強してソフトを作るより、全部きっちり勉強してからソフトを作った方が、良いものが出来上がる気がします。

ですが、そもそもソフト作りに必要な要素を全て挙げることは不可能ですし、仮に出来たとしても全てを極めることなど不可能です。一生かかっても終わりません。

全てをきっちり勉強してからやるより、最低限ソフトを作るのに必要なことだけ勉強してからソフトを作る方が、勉強したこともよく身につきます。

さらに、ソフトを作る前は「これだけ勉強したんだから大丈夫!」と思っていても、ソフトを作っていくと「あ、これ勉強しなきゃだめだな」とか「ここ、あんまり理解出来ていなかった。もう少し詳しく勉強しよう」と勉強したいところが沢山出てくるものです。

もし、勉強したいところが後から出てきても何の問題もありません。勉強したいところを勉強すればいいだけです。

最後に

ソフトを作る、Webサービスを作ると聞くと、どうしても「プログラミングが出来なきゃ作れない」と思いがちです。確かにソフトを作るのに、プログラミングは必要ですが、プログラミングはあくまでソフト・サービスを作るための一つの手段にすぎません。

それを、忘れないようにしておきましょう。

注意!!

この記事は「ソフト作りには、プログラミングは全く必要ない」と言っているわけではありません。タイトルにもある通り「プログラミングがソフト作りの全てではない」と言っているだけです。
決して「プログラミングを勉強しなくていい」ということではありません。

う-ん、よく分からん!

この記事を読んで、疑問や意見があったときは、気軽にコメント欄や私のTwitterから質問してください。

連載記事一覧

terapotan.hatenablog.jp

【gitをソフト開発で使いこなそう!:最終回】よくある.gitignore,README,LICENSEって何だろう?

前回の記事

terapotan.hatenablog.jp

連載記事一覧

  terapotan.hatenablog.jp

今回は、「LICENSE」「README.md」「.gitignore」と言った特別な役割を持つファイルについて解説していきます。

特別な役割を持つファイル

gitやGitHubでは、特別なファイル名を付けたファイルをリポジトリに置いておくと、特別な役割を果たすものがあります。
その代表例が、

  • README.md
  • LICENSE
  • .gitignore

です。もちろんこれ以外にも特別なファイルは存在します。 以下に、いくつか挙げますので興味のある方は調べてみてください。

[GitHubにおける特別なファイル]

  • PULL_REQUEST_TEMPLATE.md
  • CONTRIBUTING.md

[gitにおける特別なファイル]

  • .gitattributes
  • .gitmodules

README.md

この名前を付けたファイルをリポジトリに置いておくと、下の画像のようにREADME.mdの内容が表示されます。

READMEが表示されている画像

この機能を使うことで、初めてリポジトリを見に来た人に「このリポジトリってどんなリポジトリなんだろう?」ということを伝えることが出来ます。

上の画像は、私が前回紹介したプルリクエスト練習用のリポジトリです。

「このリポジトリはどんなリポジトリなのか」ということを解説しているのが分かるでしょうか。

Column:Markdownファイルの拡張子

.mdという見慣れない拡張子があります。これは、Markdownファイルの拡張子を表します。
「README」という名前さえついていれば、上の画像のようにファイルの内容が表示されますが、Markdownファイルとしては認識されません。

LICENSE

GitHub上で公開されているソースコード(ソフト)は、確かに無料で利用することが出来ますが、どんな利用をしてもいいというわけではありません。
ソフトの制作者が「こういう使い方だったらいいよ」と言わない限り利用することは出来ません。

LICENSEという名前のファイルに先ほど言ったこと、いわゆる「リポジトリ利用規約」を書いておくと、下の画像のようにGitHubによってライセンスの種類が表示されます。

ライセンス

ライセンス

自分で一からライセンスを書いても、もちろん構いませんが、既に作成され公開されているライセンスを適用するのが普通です。

例えば次のようなライセンスがあります。

  • MIT License
  • Apache License 2.0
  • GNU General Public License v3.0

ライセンス関連の話は、本題から大きくそれるため詳しくは述べませんが、興味のある方は参考文献をご覧ください。

.gitignoreとは?

.gitignoreを使う場面

gitでファイルを管理していると「このファイルはgitで管理したくないな」と思う場面があります。

例えば、次のようなファイルです。

  • ソースコードをビルド(コンパイル)して出来た実行可能ファイル(~.exeなど)
    • ソースコードをビルドすれば、生成できるためわざわざgitで管理する必要がない
  • ビルドする時に一時的に作成されるファイル
    • これもビルドすれば生成される上に、わざわざ管理する必要がない
  • 個人的なメモ書き
    • 本当にただのメモ書きであれば、管理する必要もない

このような時.gitignoreという名前のファイルを置くと、ある特定のファイルを無視することが出来ます。

Column:Windowsで.gitignoreという名前のファイルは作れない!?

Windows 10 Version 1903(2019年5月21日公開)より前のWindows10では、エクスプローラー上で.gitignoreのような、ドットから始まるファイルを作成することが出来ませんでした。
.gitignoreと検索すると、「.gitignoreという名前のファイルが作れない!」といった名前の記事が出てくるのはそのためです。
Windows 10 Version 1903によって、ドットから始まるファイルをエクスプローラー上で作れるようになり、変な裏技を使う必要はなくなりました。

.gitignoreの優先順位

.gitignoreは、一つのリポジトリに複数置くことが出来ます。

ある一方の.gitignoreには「ファイルAを無視しろ!」と書かれているのに、もう一方の.gitignoreには「ファイルAは無視しない」と書かれていたらどうなるのでしょうか。

その場合、より深い階層に置かれている.gitignoreが優先されることになっています。
上の例であれば、「ファイルAは無視しない」という指定が優先されます。

要するに

.gitignoreの書き方

.gitignoreの実体は、単なるテキストファイルです。次のように書かれます。

# Exclude text files
*.txt
*.md

# Exclude specific directories
/[Mm]emo/
/[Mm]anualtest/test/

tada/

/tmp/*
!/tmp/test.txt

以下具体的な書き方について、見ていきます。

基本的には、除外したいファイルやフォルダを書いていくだけです。
除外したいファイルやフォルダが、下のフォルダにあったら、.gitignoreを基準にして、相対パスで指定します。

相対パスって何だ?と思われた方は、下の記事をご覧ください。

https://wa3.i-3-i.info/word1167.htmlwa3.i-3-i.info

(ただし.gitignoreでは、./フォルダ1/フォルダ2のような相対パスの一番先頭にある.は必要ありません。)

# .gitignoreと同じフォルダに入っているファイルを無視する
/test.txt
/test.md

# subフォルダを除外
/sub/

空白行とコメント

.gitignoreにおいて、空白行は何の働きもしません。無視されます。
そのため上の例のように、見やすくするために、空白行を挿入しても構いません。

また、#を行の先頭につけると、コメントを付けることが出来ます。
#を付けた行は、何の働きもしなくなります。(一般的なプログラミング言語で言う「コメント」と同じ役割です。)

ファイル名やフォルダ名だけを書く

test.txtbuildフォルダといった、ファイル名やフォルダ名のみを一つの行に書くと、その.gitignoreサブフォルダ以下にある全ての指定されたファイルやフォルダを無視します。(サブフォルダ以下です。.gitignoreが置かれている上のフォルダには、その.gitignoreの影響は及びません。)

……少しわかりにくいでしょうか?

一つ例を挙げましょう。
リポジトリの構成が下の図のようになっているとします。

例として挙げたリポジトリの構成

ここで、.gitignore

test

と書かれていたとします。すると、上の図のABが除外されることになります。
(フォルダが除外された場合、フォルダの中身のファイルも除外されます。)

名前の最後にスラッシュ(/)をつける

名前の最後にスラッシュをつけると、設定が書かれた.gitignoreサブフォルダ以下にある全ての指定されたフォルダのみを無視します。

例として挙げたリポジトリの構成

.gitignoreに、

test

と書いたときは、ABが無視されましたが

test/

と書いたときには、ファイルであるBは無視されず、フォルダであるAのみが無視されます。

名前の最後以外にスラッシュが入っている

.gitignoreを基準にして、相対パスで指定される、ファイルやフォルダを無視します。

と言ってもいまいちピンと来ないため、下のような例で考えてみます。

例として挙げたリポジトリの構成

ここで.gitignoreに、

main/sub/test

と書くと、.gitignoreが置かれているフォルダを基準にした相対パスとして認識されます。
この例だと、mainフォルダにあるsubフォルダのtestファイルとtestフォルダを無視する、という設定になっています。

また、ここで

main/sub/test/

のように、名前の最後に/をつけると、mainフォルダにあるsubフォルダのtestフォルダのみを無視するようになります。

!

行の先頭に!をつけると、以降のファイル名やフォルダ名を無視しないという意味になります。

この設定で、前の設定を上書きすることが出来ます。

次のような.gitignoreを考えます。

/test/*
!/test/reigai.txt

一行目で、testフォルダにある全てのファイルやディレクトリを無視していますが、二行目でtestフォルダにある、reigai.txtを無視する設定から除外しています。

一見矛盾する設定のようですが、!による指定は、前の設定を上書きするため「testフォルダにあるreigai.txt以外のファイルやフォルダは、無視する」という意味になります。

もしかすると、「こうでもいけるんじゃない?」と思った方がいらっしゃるかもしれません。

/test/
!/test/reigai.txt

しかし、これは思うように動きません。なぜなら、gitの仕様上フォルダそのものを無視した場合、後から一部のフォルダやファイルだけを無視しないようには出来ないからです。

最初に挙げた例が動作するのは、フォルダそのものではなくフォルダの中にあるファイルとディレクトを無視するように設定しているからです。

……何だか、面倒くさい仕様ですが、そのような仕様になっている以上仕方ないのです。

ワイルドカード

*(アスタリスク)

「ある特定のファイルやフォルダ」ではなく、「~.txt~.exeと言った特定の拡張子のファイルを全て除外したい」と言った場面があるかもしれません。

そのような場合、.gitignoreに次のように書きます。

*.txt
*.exe

*(アスタリスク)は、/(スラッシュ)以外の0文字以上を表します。
ですから、次のようなファイル名が指定されたのと同じ意味を持ちます。(下はあくまで例です。上の文を満たすファイルはいくらでもあります。)

  • test.txt
  • ttt.exe
  • setup.exe
  • .txt (ドットの前に一文字も無くても良い。なぜなら0文字以上だから。)
  • /test/sub/file.txt (フォルダが指定されていても、構わない。)

?

/(スラッシュ)以外の任意の1文字を指します。

[~]

[]の中に入っている、/(スラッシュ)以外の一文字が指定されます。

例えば、manual.txtとManual.txtを除外したいとき、

manual.txt
Manual.txt

と書いてもいいですが、

[Mm]anual.txt

と書くことも出来ます。[Mm]はMかmどちらかの文字が指定されたとき、という意味だからです。

既にコミットしたファイルを無視したい

既にコミットしてしまったファイルを、後から.gitignoreで無視するよう設定しても無視されません

既にコミットしてしまったファイルを無視させるには、下のコマンドを入力する必要があります。

無視したいものが、ファイルだった場合。

git rm  --cached <ファイル名(例:test.txt)>

無視したいものが、フォルダだった場合。

git rm  -r --cached <フォルダ名(例:folder)>

delete……と画面上に表示されますが、ファイル自体が消えたわけではないため、安心してください。

-rオプションは、「<フォルダ名>のサブディレクトリ以下に入っているファイルも全て」という意味になります。

次コミットするときに反映されます。

ちなみに、--cachedオプションを忘れると一見ファイルが本当に削除されたように表示されますが、すぐに復旧できます。

下のコマンドを順に入力してください。

git reset HEAD
git checkout HEAD <ファイル名orフォルダ名>

最後に

これで「gitをソフト開発で使いこなそう!」は、終了となります。
「gitをソフト開発で使いこなそう!」をお読みいただきありがとうございました。

より深く学びたい人のために

こっそり始めるGit/GitHub超入門

www.atmarkit.co.jp

この連載では、gitをソフト開発で使いこなそうで扱えなかったGitHubの機能がいくつか解説されています。

う-ん、よく分からん!

この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。

参考文献

Pro Git

git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com

今日から始めるOSSライセンス講座

OSSライセンス、オープンソースソフトウェアライセンスについての概要が書かれている連載です。

thinkit.co.jp

文化庁著作権テキスト

https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/pdf/r1392388_01.pdfwww.bunka.go.jp

www.bunka.go.jp

OSSライセンスとは直接関係はありませんが、OSSライセンスの土台となっている「著作権」について詳しく学ぶことが出来ます。
文化庁が公式で出しているものです。

前回の記事

terapotan.hatenablog.jp

連載記事一覧

terapotan.hatenablog.jp

【gitをソフト開発で使いこなそう!:第13回】プルリクエストを送ってみよう!

次回の記事

terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

  terapotan.hatenablog.jp

今回は、GitHubの大きな特色である「プルリクエスト」という機能について解説します。
これが出来るようになると、他の人がGitHub上で公開しているソースコードを編集することが出来るようになります。

プルリクエストとは?

プルリクエス(プルリク・PRとも略される。)とは、GitHubに備わっているリポジトリの内容の変更をリクエスト出来る機能のことです。

プルリクエストの機能は、GitHubが独自に備えている機能です。gitに備わっている機能ではありません。

一つ例を挙げてみましょう。

誰かが、GitHub上にとあるソフトのソースコードを公開しているとします。

あなたが、このソフトのバグ(不具合)を見つけたため、公開されているソフトのソースコードを修正したいとします。

しかし、第10回で説明している理由で、プッシュ出来る人を普通、制限しているため、あなたが直接ソースコードを修正することは出来ません。

そこで直接ソースコードを修正出来る人に「こういう変更をしてくれ!」というリクエストを送ります。これが、プルリクエスです。

プルリクエストの送り方

フォークとクローン

今回は、下のリポジトリを例にしてプルリクエストを送ってみます。

github.com

Column:上のリポジトリについて

上のリポジトリは書籍「わかばちゃんと学ぶGit使い方入門」のプルリクエスト練習用リポジトリとして公開されているものです。
ですが2020年4月現在、数百件以上のプルリクエストがマージされないまま、放置されている状況です。恐らくプルリクエストが受け入れられることは……ないでしょう。

そこで、プルリクエスト練習用のリポジトリを作成しました。下のリンクから移動することが出来ます。
気軽にプルリクエストの練習に使ってください。

github.com

プルリクエストを送りたいリポジトリに移動したら、画面右上の「Fork」というボタンを押してください。

Forkボタンの場所

このボタンを押すと、今表示しているリポジトリが自分のアカウントにコピーされます。(これをボタンの名前の通り、フォークと言います。)

フォークの概念図

フォークしたリポジトリの名前を見ると、elmas3/pull-request-practiceからterapotan/pull-request-practiceに変わっているのが分かります。(terapotanは私のアカウント名です。)

フォーク成功

さらにフォークしたリポジトリに変更を加えるために、リポジトリをローカル(自分のPCとか)にコピーします。
これをクローンと言います。

フォークしたリポジトリClone or downloadをクリックして、git@から始まるアドレスをクリップボードにコピーしてください。

アドレスを見る

中身が空のフォルダを作成し、そこでGitBashを立ち上げて、次のコマンドを入力してください。

git clone <コピーしてきたgit@から始まるアドレス>
Column:コピーと貼り付けのショートカットキー

普通Windows上では、コピーと貼り付けのショートカットキーは「Ctrl+C」と「Ctrl+V」です。
ですが、GitBashでは「Ctrl+Ins(インサートキー)」と「Shift+Ins」がコピーと貼り付けのショートカットキーとなっています。

クローンが終わったら、下のコマンドを入力して作成されたフォルダに移動してください。(カレントディレクトリを新たに作成されたフォルダにする。)

cd ./<新たに作成されたフォルダの名前>

変更を加える

新たに作成したフォルダに移動したら、新しいブランチを作成します。
ブランチ名は何でもいいですが、今回はpullreqdevとしました。

git branch pullreqdev
git checkout pullreqdev
Column:git checkout -b

「git checkout -b」と入力することで、ブランチの作成と作成したブランチへの、チェックアウトを同時に行うことが出来ます。
上の例であれば、「git checkout -b pullreqdev」と入力します。

新しく変更を加えます。これも、何でもよいのですが、今回は新しく下の内容のファイルを追加しました。

プルリク.txt

PullRequestTest

次のコマンドを実行してコミットします。

git add --all
git commit -m "プルリクコミット"

git pushコマンドを実行して、変更をフォークしたリポジトリに反映します。

git push origin pullreqdev
Column:あれ?git remoteコマンド打ってないよ?

第10回では、リモートリポジトリにプッシュする前に「git remote add~」を使って「origin」を追加していましたが、今回はしていません。
……ですが、上の「git push」コマンドは正常に実行されます。なぜ上手くいくのでしょうか。
それは、「git clone」コマンドを使ってローカルリポジトリを作成した場合、自動的にクローン先のリモートリポジトリ(今回の場合、フォークしたリポジトリ)のアドレスをoriginとして登録するようになっているからです。

プルリクエストを送る

新たにブランチを作成したら、プルリクエストを送りたいリポジトリのページを開いてください。

下の画像のような、メッセージが画面の上の方に表示されているはずです。

プルリクボタン

画像右端にある、Compare & pull requestをクリックしてください。

下のような画面が表示されます。

プルリクを出す。

画像上の方にある、base repositoryhead repository……というのは、「head repositoryからbase repositoryへ、内容変更のリクエストを出す」という意味になります。

画像のような表示だと「terapotan/pull-request-practiceリポジトリpullreqdevブランチから、elmas3/pull-request-practiceリポジトリmasterブランチへ、内容変更のリクエストを出す」という意味になります。

何となく気づいた方もいらっしゃるかもしれませんが、プルリクエスというのは、「俺の作ったブランチをお前のリポジトリのブランチに、マージさせてくれ!」というリクエストです。

ですから、どこのブランチをどこのブランチへマージさせるのか、予め指定しておく必要があります。

画像中央に「プルリクエストのテストです。」と書かれている部分があります。
ここに、プルリクエストと一緒に送るメッセージを書き込みます。

Column:Markdown

プルリクエストと一緒に送るメッセージは、Markdownという書式で書くことが出来ます。
Markdownと呼ばれる書式で書くと、見出しや太字・箇条書きと言ったものを簡単に書くことが出来ます。この記事も、Markdownで書いています。
Markdownには、HTMLのように決まった規格があるわけではないため、エディタによって書く方法に若干の差があります。
ここではMarkdownについて詳しく解説しません。詳しいことが知りたい方は、参考文献をご覧下さい。

メッセージが書けたら、画像下にあるCreate Pull requestを押してください。

プルリクエストが作成されます。

プルリクエスト作成完了

後は、マージされるのを待つだけです。

マージされると、画像左上にあるOpenという文字がMergedに変わります。

マージが通った

(上の画像は、別のリポジトリでマージされた時のものです。)

次回予告

次回は、よくGitHubリポジトリに登場するREADME.mdLICENSE.gitignoreの3つのファイルについて解説していきます。

う-ん、よく分からん!

この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。

参考文献

Pro Git

git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com

GitHub公式マニュアル

GitHub公式の、プルリクエストについて解説した文章です。

help.github.com

Markdown関連

Markdownそのものについて詳しく知りたい方はこちら。

www.markdown.jp

Markdownの書き方について知りたい方はこちら。

help.github.com

次回の記事

[terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

terapotan.hatenablog.jp

【gitをソフト開発で使いこなそう!:第12回】git fetchで引数を省略すると何が起こる?

次回の記事

terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

  terapotan.hatenablog.jp

今回は、リモートリポジトリから変更を取り込むコマンドである「git fetch」の使い方を解説していきます。
前回と同じく、リポジトリ名やブランチ名を全て省略したときの動作も扱います。

前提知識

今回の記事の説明をしっかりと理解するには、上流ブランチリモート追跡ブランチという用語について理解している必要があります。

下の記事では、用語の解説を行っています。
用語の意味が分からない方は、ご覧になることをお勧めします。

terapotan.hatenablog.jp

git fetch

どんなコマンド?

リモートリポジトリから、変更を取り込むコマンドです。
下のような例を考えてみましょう。

fetch解説例

リモートブランチmasterには、ローカルブランチmasterにはまだないコミットが追加されています。
上の図で言うとコミットB,Cの部分です。

この時git fetchコマンドを使うと、コミットB,Cの部分をダウンロードすることが出来ます。

ダウンロード

ここで注意しなければならないのは、git fetchコマンドは、本当にただダウンロードするだけという点です。
上の図を見ると分かる通り、リモート追跡ブランチであるorigin/masterはコミットCへ動いていますが、ローカルブランチであるmasterは動いていません。

前回のコラムで解説した通り、リモート追跡ブランチにチェックアウト(HEADを移動させる)ことは出来ませんから、このままではダウンロードしてきた分を編集することは出来ません。

編集出来るようにするには、git mergeコマンドを使って、origin/mastermasterをマージする必要があります。

コマンドの使い方

先ほど挙げた例で、git fetchコマンドをどのように使うか見ていきましょう。

さっきの例

今、リモートリポジトリoriginのリモートブランチmasterをローカルリポジトリに取り込みたい(ダウンロードしたい)とします。

次のようにコマンドを入力すると、変更を取り込むことが出来ます。

git fetch origin master

値の意味は次の通りです。

git fetch <取り込みたいリモートリポジトリ名> <取り込みたいリモートブランチ名>

リモートリポジトリtestのリモートブランチdevelopのみを、ローカルリポジトリに取り込みたいときは、

git fetch test develop

というコマンドを実行します。

全て省略すると?

例として挙げる例

上の図のような状況(カレントブランチはmaster。masterブランチの上流ブランチは、myrepo/master。)で、

git fetch

のようにリモートリポジトリ名とリモートブランチ名を省略してコマンドを実行したとき、何が起こるのでしょうか。

前回と同じように、上の例を使って、リモートリポジトリ名とリモートブランチ名がどのように指定されるのか見ていくことにします。

リモートリポジトリ名

今回の例では、masterブランチがカレントブランチになっています。
また、masterブランチの上流ブランチは、リモート追跡ブランチmyrepo/masterに設定されています。

このように、上流ブランチが設定されている場合は、リモート追跡ブランチが追跡しているリモートリポジトリ名が、指定されます。

今回の例では、myrepoがリモートリポジトリ名として指定されることになります。

上流ブランチが設定されていない場合は、originが指定されます。
(originが存在しない場合は、何も起こりません。)

リモートブランチ名

リモートブランチ名を省略した場合、リモートリポジトリ名のリモートリポジトリにある全てのリモートブランチの変更が取り込まれます。

今回、リモートリポジトリ名はmyrepoが指定されています。ですから、リモートリポジトリmyrepoにある、リモートブランチであるmasterdevelopが取り込まれることになります。

最終結果

リモートブランチ名だけ省略すると?

リモートブランチ名だけ省略した場合というのは、

git fetch myrepo

などのようにコマンドを入力することです。
この場合、リモートリポジトリmyrepoにあるリモートブランチ全てが、取り込まれます。

マージしないと編集することは出来ない

本記事の最初でも解説した通り、git fetchコマンドは本当にただダウンロードするだけです。
リモートリポジトリからダウンロードしてきた内容を基に編集するには、ローカルブランチとマージする必要があります。

実際にどうやるのか

下の図のように、既にリモートリポジトリmasterの内容をダウンロードしてきた場合を考えます。

ダウンロード

ダウンロードしてきた内容を指しているのは、リモート追跡ブランチorigin/masterです。
(リモート追跡ブランチは、git fetchコマンドを実行したと同時に移動します。)

ですから、origin/masterとローカルブランチmasterをマージすればいいことになります。
そうすれば、ローカルブランチmaster上で取り込んできた変更を元に編集することが出来ます。

ローカルブランチmasterにチェックアウト(git checkout master)して、下のコマンドを実行します。

git merge origin/master

origin/masterの履歴が、ローカルブランチmasterにまとめられました。

merge実行後

次回予告

git,GitHubでは、ある特別な名前をファイルにつけると特別な働きをするものがあります。
次回は、そんなファイルをいくつか紹介します。

う-ん、よく分からん!

この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。

参考文献

Pro Git

git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com

git用語解説マニュアル

git公式の用語解説マニュアルです。
上流ブランチ(upstream branch)や、コミット(commit)等の用語の意味について英語で書かれています。
git-scm.com

git fetch

git fetchコマンドに関するgit公式マニュアルです。

git-scm.com

次回の記事

terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

terapotan.hatenablog.jp

【gitをソフト開発で使いこなそう!:第11回】git pushで引数を省略すると何が起こる?

次回の記事

terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

  terapotan.hatenablog.jp

今回は、「git push」コマンドについて解説していきます。このコマンドの動作自体はシンプルなのですが、ブランチ名などを省略したときの動作が複雑です。
その動作を詳しく解説していきます。

変更履歴

2020年4月18日 コラム:push.defaultを追加。
参考文献に、git-configのマニュアルを追加。
注意!:git push -fの使用は慎重に、慎重にを追加。

2020年4月22日 git push --deleteの動作説明を「リモートリポジトリを削除する」から「リモートブランチを削除する」に修正。

リモートリポジトリとローカルリポジトリ

リモートリポジトリというと、ローカルリポジトリとは何か別の構造をしたもののように感じます。
ですが、実際にはリモートリポジトリの構造もローカルリポジトリと同じです。

同じ構造だよ

上の四角がリモートリポジトリを表し、下の四角がローカルリポジトリを表しています。

ローカル/リモートブランチ・上流ブランチ・リモート追跡ブランチ

リモート追跡ブランチ

先ほどの図には、いくつかブランチがあります。
これらのブランチには、種類ごとに名前が付いています。

まずローカルリポジトリにあるブランチはローカルブランチ、リモートリポジトリにあるブランチはリモートブランチと呼ばれます。
ローカルリポジトリには、origin/masterという名前のブランチがあります。
このブランチは、リモートリポジトリoriginのリモートブランチmasterを追跡しています。

(originというのは、リモートリポジトリに付けられた名前です。単なる名前であるため、別にtestでもmyrepoでも構いません。今回の例では、originと名付けています。)

このようなブランチをリモート追跡ブランチと言います。

「追跡している」とは、どういうことでしょうか。

例えば下のような場面を考えてみましょう。リモートリポジトリが1つ、ローカルリポジトリが2つあるような場面です。

想定している場面

ここで、ローカルリポジトリBに変更を加えます。(コミットを行う。)

変更を加える

続いて、ローカルリポジトリBからリモートリポジトリoriginに変更を反映(プッシュ)します。

すると、リモートリポジトリにあるmasterブランチが移動します。
ローカルリポジトリBにあるorigin/masterは、リモートリポジトリにあるmasterブランチを追跡しているため、masterブランチの動きを追いかけるように、origin/masterも動きます。

動く

またローカルリポジトリAも、「リモートリポジトリで起こった変更を取り込むコマンド」(次回解説します。)を使うと、ローカルリポジトリAにあるorigin/masterが、リモートリポジトリにあるmasterの位置まで動きます。

ローカルリポジトリAの動作

今回の記事では、あまりリモート追跡ブランチを使っている意味がよくわからないかもしれません。
ですが、次回やる「リモートリポジトリの変更を、ローカルリポジトリに取り込む」ときに重要な役割を果たします。

Column:リモート追跡ブランチにチェックアウトすることは出来ない!

git checkout origin/masterのようにして、リモート追跡ブランチに移動することは出来ません。
そのため、リモート追跡ブランチを普通のブランチのように使うことは出来ません。
ここからも、リモート追跡ブランチは特殊なブランチであることがわかります。

上流ブランチ

……また謎な用語が出てきました。

一番最初に挙げた例を使いましょう。

一番最初に挙げた例

gitでは、あるリモート追跡ブランチをあるローカルブランチの上流ブランチと呼ばれるものに設定することが出来ます。

わかった。で、上流ブランチって何?――と思われるかもしれませんが、あまり上流ブランチの意味は考えず「gitには、上流ブランチというよくわからんものをローカルブランチに設定出来る機能がある」と割り切った方がいいです。

一応、参考文献に載せてあるgitのマニュアルには、上流ブランチについて解説されていますが、あまりピンと来ないと思います。

何でこんなの解説するの?

リモート追跡ブランチ、上流ブランチといういまいちピンとこない単語が二つも出てきました。
よくわからないものは、出来るだけ避けて通りたいものですが、この二つは次の解説するgit pushコマンドや次回出てくるコマンドの動作を説明する時に出てくるのです。

これを理解しておかないと、何を言っているのかさっぱり分からなくなってしまいます。

git push

ローカルブランチのmasterの変更を、リモートブランチoriginmasterに反映する時、gitでは次のコマンドを入力することで、変更を反映出来ます。(リモート追跡ブランチの図で出てきた【1:Push】の操作にあたる。)

git push origin master:master

上のコマンドの意味は、下の通りです。

git push <リモートブランチにつけた別名> <ローカルブランチの名前>:<リモートブランチの名前>

ですから、もしリモートリポジトリendにあるリモートブランチdevelopに、ローカルブランチmouseの変更を反映させたいとすると、

git push end mouse:develop

と入力すればいいことになります。

リモート追跡ブランチの移動

git pushコマンドを実行すると、リモートブランチが移動することになります。
リモート追跡ブランチは、リモートブランチと同期しているため、リモート追跡ブランチも移動することになります。

ブランチ名を省略する

最初に取り挙げた例では、次のようなコマンドを入力しました。

git push origin master:master

ローカルブランチの名前とリモートブランチの名前が同じです。
このような時、gitではmaster:mastermasterに省略することが出来ます。

git push origin master

複数のブランチを同時にプッシュする

先ほどの例では、masterブランチ一つだけをプッシュしましたが、下のように空白区切りでブランチ名を書くことで、複数のブランチを一気にプッシュすることが出来ます。

git push origin master develop sample

リモートブランチを削除する

--deleteオプションを付けることで、リモートブランチを削除することが出来ます。

git push --delete origin master
注意!:git push -fの使用は慎重に、慎重に

プッシュしようとしている内容によっては、リモートリポジトリの履歴と競合(コンフリクト)してしまい、プッシュが上手くいかないことがあります。
このような時「-f」というオプション(git push -fのように入力する。)を付けるとプッシュすることが出来ます……が、絶対にやってはいけません。

競合した状態で、強制的にプッシュしてしまうとリモートリポジトリの履歴が上書きされてしまいます。
強制的にプッシュした本人は、何の問題もなく使えるのですが、このリモートリポジトリを使っている別の人が困ってしまいます。
リモートリポジトリの履歴が上書きされてしまうと、今度はその履歴と別の人のローカルリポジトリの履歴が競合(コンフリクト)してしまうからです。
変更を取り込もうにも、プッシュしようにもエラーが多発して、使用不能になってしまいます。

インターネット上で、いくつか「-fを使ってエラーを解決出来る」としている記事がありますが、それは上で言ったことを全て分かった上で、問題が起こらないと確信しているから解決できるとしているのです。

ここまでの説明を聞いて「なんかよくわからんなぁ」と思っている人は特に使うべきではありません。

ソフトが出す警告には、意味があります。無視しないようにしましょう。
でないと……とんでもないことが起こるかもしれません。

これで終わり?

git push自体の動作の説明はこれで終わりです。

ですが、プッシュという操作はよく行われます。そのたびに長いコマンドを打つのは面倒です。

そこで、git pushコマンドには「リモートリポジトリの別名」や「ブランチ名」を省略出来る機能が付いています。

下のようにコマンドを入力しても、プッシュが行われるということです。

git push

……確かに便利なのですが、名前が全て省略された時の動作はかなり複雑です。
使い方によっては、プッシュしてほしくないブランチにプッシュしてしまうかもしれません。

以下で省略された時の動作を解説しますが、「読むのが面倒くさい!」と思うのであれば、とりあえず飛ばしておくのもいいでしょう。

「git push」と入力したときの動作

git push

と入力された時、省略されているのは

  1. リモートリポジトリ名
  2. ブランチの名前

の二つです。
この二つの値が、省略された場合どのように値が決まるのか見ていくことにしましょう。

リモートリポジトリ名――上流ブランチが設定されている場合

下の図のような例で、git pushを実行すると、どのような動きをするのか見ていきましょう。

例1

myrepo/masterは、リモートブランチmasterを追跡している、いわゆるリモート追跡ブランチです。
また、myrepo/masterはローカルブランチmasterの上流ブランチ(と呼ばれるもの)に設定しておいてあります。

カレントブランチ(HEADが指し示しているブランチ)はmasterにしておきます。

この状況で、

git push

と入力すると、まず初めにgitは、カレントブランチの上流ブランチを見に行きます。
今回カレントブランチの上流ブランチはmyrepo/masterに設定されています。

次に、その上流ブランチがどのリポジトリにあるリモートブランチを追跡しているのか見ます。このリポジトリ名が、リモートリポジトリ名を省略したときにセットされる名前です。

今回、上流ブランチはリモートリポジトリmyrepoにあるブランチを追跡しています。
ですから、今回の例で指定される名前はmyrepoということになります。

上流ブランチが指定されていなかった場合は?

先ほどの例は、上流ブランチが設定されていた場合でした。
では、上流ブランチが設定されていなかった場合はどうなるのでしょう?

その場合、originという名前が指定されることになっています。

Column:repoオプション

上流ブランチが設定されていなかった場合に指定される名前は、repoオプションを使って変更することが出来ます。
例えば、指定される名前をteraに変更したい場合次のようにします。

git push --repo=tera

リモートリポジトリ名――まとめ

リモートリポジトリ名が省略された場合、指定される名前は次のように決まります。

  1. カレントブランチに上流ブランチが設定されているか?
    1. (Yesの時):リモート追跡ブランチが、追跡しているリモートリポジトリ名が指定される
    2. (Noの時):repoオプションが指定されているか?
      1. (Yesの時):指定された名前が、設定される
      2. (Noの時):originが指定される

ブランチ名

続いてブランチ名ですが、プッシュするブランチを決める方法はいくつかあり、ユーザーが選ぶことが出来ます。
今回解説するのは、ユーザーが何も設定していない場合、デフォルトで設定される動作です。

Column:push.default

gitでは、ユーザ名やメールアドレスなどの値やコマンドの挙動について設定出来る機能があります。
例えば、ユーザ名の場合user.nameという設定項目がありこれに対して、user.name=myusernameという値をセットすることで、ユーザ名がmyusernameに設定されます。
同じように、ブランチ名を省略した場合の挙動を決めるpush.defaultという名前の設定項目が存在します。
push.defaultには、simple・matching・nothing・current・upstreamという5つの値(文字列)を設定することが出来ます。(それぞれの設定値の挙動については、参考文献にあるpush.defaultをご覧ください。)
本文にあった「ユーザーが何も設定していない場合」というのは、push.defaultに何の値も設定していない場合、という意味になります。

push.defaultに値が設定されているか見るには、「git config -l」というコマンドを入力します。
もし設定されていれば、「push.default=simple」のように表示されるはずです。設定されていなければ、「push.default」という設定項目自体が表示されません。

Column:引数無しのpushは危険?

「git push 省略」と検索してみると「git push」と打ってプッシュするのは危険だ!という記述がたまに見られます。
これは、Git2.0(2.0はバージョンを示します。)以前のGitでは、プッシュするブランチを決める方法をユーザーが決めていない場合、リモートブランチと同じ名前のローカルブランチをプッシュするという設定になっていたからです。

この設定だと、masterブランチだけプッシュしたくて「git push」と入力したのに、それ以外のブランチも、リモートリポジトリに同じ名前のブランチがあれば、プッシュされてしまう可能性があります。
Git2.0以降のGitでは、下で説明するような動作に変更されました。

今使っているGitが、Git2.0以降か確認したい場合は「git --version」とGitBashに入力してください。
「git version 2.xx.x.windows.x」のように表示されたら、Git2.0以降のGitです。

先ほどと同じ例を使って、ローカルブランチmasterをカレントブランチにしているとき、git pushと入力すると何が起こるのか見ていきましょう。

先ほどと同じ図

まず、gitはカレントブランチ(今回の場合だとmaster)の上流ブランチを見に行きます。

上流ブランチが設定されていない場合、プッシュは行われません。

加えて、この上流ブランチと同期しているリモートブランチの名前とカレントブランチの名前を比較します。

名前の比較

もし同じであれば、カレントブランチの内容を比較したリモートブランチにプッシュします。
異なる場合は、プッシュは行われません。

ローカルブランチmasterをカレントブランチにしているとき、git pushと入力すると、下のコマンドが入力されるのと同じ動作を行います。

git push myrepo master

ブランチ名――まとめ

ブランチ名が省略された場合、プッシュの動作は次のように決まります。
なお、プッシュするリモートリポジトリ名は「リモートリポジトリ名――まとめ」で、取り挙げた手順で決定されます。

  1. カレントブランチに上流ブランチが設定されているか?
    1. (Noの時):プッシュは行われない。(エラーが出る。)
    2. (Yesの時):上流ブランチが追跡しているリモートブランチの名前と、カレントブランチの名前は同じか?
      1. (Yesの時):カレントブランチから、先ほど名前を比較したリモートブランチへプッシュする
      2. (Noの時):プッシュは行われない。(エラーが出る。)

上流ブランチを設定する

上で見たように、git pushと入力するだけで、プッシュが行われるようにするには、リモート追跡ブランチをあるローカルブランチの上流ブランチに設定しなければなりません。

origin/masterというリモート追跡ブランチを、masterというローカルブランチの上流ブランチに設定するには、次のコマンドを入力します。

git branch --set-upstream-to=origin/master

エラーが出る?

git pushとコマンドを入力したとき、次のようなエラーが出ることがあります。

fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin master

ローカルブランチに上流ブランチが設定されていないことが原因です。

git push -uって何だ?

前回の最後で、下のようなコマンドを入力しました。

git push -u origin master

-uというオプションがついています。
これは、「下のコマンド2つを同時に実行せよ」というオプションになります。

  1. git push origin master
  2. git branch --set-upstream-to=origin/master

masterブランチをリモートリポジトリoriginにプッシュして、origin/mastermasterの上流ブランチにしなさいという意味になります。

初めてローカルブランチをプッシュするとき、-uオプションを付けておけば、いちいち上流ブランチを設定するコマンドを入力する必要がなくなります。

次回予告

次回は、リモートリポジトリから変更を取り込むコマンドであるgit fetchgit pullについて解説します。

う-ん、よく分からん!

この記事を読んで、疑問に思うことがあったときは、気軽にコメント欄や私のTwitterから質問してください。

参考文献

Pro Git

git,GitHubを使うにあたって必要なコマンドの使い方が詳しく解説されています。この連載を読んで分からないことや詳しく知りたいことがあったときはまずProgitを読んでみるといいでしょう。 git-scm.com

git用語解説マニュアル

git公式の用語解説マニュアルです。
上流ブランチ(upstream branch)や、コミット(commit)等の用語の意味について英語で書かれています。
git-scm.com

push.default

git-configで見ることが出来る設定値の意味について書かれた、git公式のマニュアルです。
ブラウザでCtrl+Fを押して、push.defaultを検索すると、コラムで出てきたpush.defaultの設定値の意味の説明に飛ぶことが出来ます。

git-scm.com

次回の記事

terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

terapotan.hatenablog.jp