ローカルのブランチ名を変更する方法です。Pull Requestのissue番号を間違っていたときなどに活躍します。
![gitのローカルのブランチ名を変更したい - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e494d6e90dbce48945cc8ac868484d0d66a78b92/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9Z2l0JUUzJTgxJUFFJUUzJTgzJUFEJUUzJTgzJUJDJUUzJTgyJUFCJUUzJTgzJUFCJUUzJTgxJUFFJUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUIzJUUzJTgzJTgxJUU1JTkwJThEJUUzJTgyJTkyJUU1JUE0JTg5JUU2JTlCJUI0JUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTg0JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz05NWIzZmQxOWUxZjAzZTA2MmI5M2ExOTQ2Y2Y2MTg0NQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzdWluJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wMmNiMDRkYmM5YTE5NjlkMWUyMzlhNTg4NGFiYzQ4ZA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gQ3JhZnRzbWFuIFNvZnR3YXJl%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D96b85604b2625fc00ead0050079511f7)
ローカルのブランチ名を変更する方法です。Pull Requestのissue番号を間違っていたときなどに活躍します。
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね!また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
新しめの言語では例外を投げることを推奨しない言語が出てきているように思えるが、そうした言語が例外をどう考え、例外の代わりにどのようなアプローチを奨励しているかを調べてみた。 本稿での「例外」とは、Javaのthrow構文のようにスコープを脱出してcatchされるまでエスカレートされる「投げる例外」のことを指し、エラーを表現したオブジェクト(エラーオブジェクト)については「例外オブジェクト」と呼び区別するものとする。(この2つを同一に扱うと、例外を使わないということは、エラーオブジェクトは使わないの?という話になるため) Go言語 - 例外はコードを複雑にする Go言語では、通常、エラーは戻り値として扱われる。(本当の本当に例外的なエラーのためにpanic, recoverがあるが、ほとんど使われることがないように見受けられる。) 例外がないGoでは、どう呼び出し元にエラーを伝えているかとい
PhpStormはクラス名などを途中まで入力すると補完の候補を出してくれる。補完の対象となるクラスは、PHPのコアのものやユーザ定義クラスだけでなく、PHP拡張のクラスまでと包括的で親切設計なのだ。 しかし、逆に補完が包括的すぎて普段使わない拡張のものまで候補にあがってきて選択ミスをしやすかったり、特によく使うコアのクラスよりも、めったに使わない拡張のクラスが上位に出てくると、うっとうしいことこの上ない。 本稿では、使わないPHP拡張のクラスが補完の候補に上がらないようにする方法を紹介する。 特定のPHP拡張の補完を無効化する方法 「Navigate」→「Class」(macOSの場合command Oがショートカットキー)で無効化したいクラスのファイルを開く。 開いたら、そのファイルがあるディレクトリを特定し、そこから拡張の名前を特定する: つづいて、「Preference」→「Lang
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く