Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
git checkout -b develop origin/develop
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
この記事はGit Advent Calendar 2014の6日目の記事です! (更新がお昼になってしまいました、ごめんなさい><) みなさん! Gitの-pオプション使ってますか? 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します! 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね! 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
GitHubにpushするとき、Authorのメールアドレスにどのメールドレスを設定しようかと悩んで少し調べたところ、 GitHubのアカウント用のメールアドレスが利用できることを知ったので、その方法をまとめた。 1. GitHubの設定 まずは、GitHubの設定。 1.1. GitHubの設定画面を開く ブラウザでGitHubの設定画面 1.2. Emailの設定を開く 画面左にあるEmailsを開く。 1.3. "Keep my email address private"にチェックをつけ、の説明文にあるメールアドレスを控える。 メールアドレスは<username>@users.noreply.github.comになる。<username>はアカウント名。 2. gitリポジトリの設定 次に、対象のgitリポジトリでの設定。 こちらはgit configコマンドを使って、user.
昨日、弊社の社内勉強会にGitHub実践入門の著者である @HIROCASTER さんにお越しいただき、GitHub活用術の話をしていただきました。 さらにひょんな流れから、なんと「GitHub実践入門」の本まで頂いてしまった! ありがとうございます!!ありがとうございます!! まだ流し読みしかできていないのですが、スピード感想をここに。 心に残ったフレーズ Pull Requestを育てる GitHub単体だと、現在利用しているプロジェクト管理ツールよりも機能的に足りない点もあるかと思います。ですが、その足りない機能を一度捨ててみることも検討してください。GitHubのような非常にシンプルな機能だけで、ソフトウェア開発は十分にできるはずです(Issueとかの話) 常にデプロイ。リリースという概念はない(GitHub Flowの話) すべての変更をステージング環境で確認してからデプロイする
何度目か忘れた 何度も失敗しているのでうまくいく方法からチャレンジ 準備 テスト用の環境を構築 git clone https://github.com/mshige1979/vagrant-centos-dev-001.git test02 cd test02 vagrant up saharaプラグインで前の環境へ戻しやすい用 vagrant sandbox on 今回はhttps://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.mdの通りに ダウンロード(https://about.gitlab.com/downloads/archives/) openssh-server sudo yum install -y openssh-server※インストール済み postfix sudo yum install -y
git rebase -i HEAD^^ Vimが起動するので、以下の様に修正 今回はひとつ前のコミットを最新のコミットとあわせる。 pick yyyyyyy コミットログ2 pick xxxxxxx コミットログ1 # Rebase yyyyyyy..xxxxxxx onto yyyyyyy # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log m
gitサーバーをCentOS上に構築 - 鶏頭のプログラムで書きましたように gitのサーバーを構築しました。 さらに今回は sphinx でドキュメント管理をして それを即時反映Webで公開可能な状態にするということに取り組みます。 というわけで今回はWebサーバーとしては RubyのSinatraを使用 httpのサービスはapache を使用して環境構築を行います。 まずはSinatraの準備から(今回はとても簡単に)。 ディレクトリ構成は下記のようになります。 ├── Gemfile ├── compile.rb ├── config.ru ├── route.rb ├── log │ ├── access.log │ └── error.log ├── public │ └── sphinxでmakeしたhtmlファイルを配置 └── sphinx └── documents ├
2014-03-30 Githubで初めてのPull Requestした Github はじめに こんにちは、先日大学を卒業しました(それについては別に書こうかな?) 今回は昨日僕が初めてPull Requestしたので、それにについて書こうと思います。 Pull Requestって何? Githubには数多くのリポジトリがあると思いますが、その分数多くのプログラムにバグであったり、不十分な所があったりするわけです。 そこで、気づいた人が「ここはこうしたらどうだろう?」と自分で書き換えたプログラムを元の作者に提案します。 これがPull Requestデス(多分)さらに、それが作者に認められ、取り込まれることを「マージされる」と言います。 他人のプログラムに手を出すなんて恐れ多い・・・ 安心してください、1行消すだけのPull Requestでも全然大丈夫です。 今回僕がreq
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 (これ以降の記事中のリモートは全てoriginとします。) このコロンは何?? リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか? 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
分散型バージョン管理システム「Git」の開発チームは2月14日、最新版となる「Git 1.9.0」を公開した。多くのサブコマンドが追加されるなど、多数の機能強化が行われている。 Git 1.9.0は2012年10月に公開されたバージョン1.8系に続くアップデートとなる。本バージョンでは多くの機能が追加されており、一部後方互換性のない機能変更も行われている。 大きな変更点としては、HTTP経由でのトランスポートでGSS-Negotiate認証利用時に「100 Continue」メッセージを利用するように変更された点がある。これにより大規模なペイロードの再送を避けられるとしている。サブシステムではremote-bzr、remote-hgのバグを修正し、git q4、git svn、gitkも更新した。 ワークフローやUI関連では、従来は行えなかったshallowクローンで作成されたレポジトリか
BitbucketやGitHubのGitリポジトリにアクセスではSSH認証キーを使うことができます。このSSH認証キーを使ったアクセスのメリットは次のとおりです。 * Pushするときにいちいちパスワードを打つ必要がなくなる * セキュリティが向上する 今回はMacでSSH認証のための公開鍵と秘密鍵を生成して、GitHubやBitbucketに公開鍵を登録して、SSHでアクセスできるようにするまでの設定手順をできるだけわかりやすく書いていきます。もし、詰まった点とかあればコメントお願いします! (04/11 22:30) 前回の修正でミスってた部分を修正 🐯 流れSSH認証キーの設定の流れは次のとおりです。 (1) SSH認証の公開鍵と秘密鍵を作成 (2) Mac側(クライアント側)へのSSHキーの設定 (3) Bitbucketへの公開鍵の登録 (4) GitHubへの公開鍵の登録
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く