You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
あの「GitHub Inc」さんから「Facebook」と共同で開発した「Atom IDE」なるものが発表されました このパッケージを入れることで「Atom」をIDEにすることができます。 現在対応している言語 TypeScript & JavaScript Flow C# Java(Java 8 runtime required) PHP(PHP 7 runtime required) 推奨ではありません。必須です 公式の「Atom IDEブログ」をみてみると We strongly recommended you use Atom Beta 1.21 as it includes the necessary file monitoring and process control to ensure the underlying language servers are running
個人的なメモ取り環境としてWikiが欲しいな、と思ったので建てました。 以下macOSで作業していますが、LinuxやWindows環境でも大きく変えるところなく使えると思います。 Wikiエンジンにはgollumを使う gollumはバックエンドにGitを使っているシンプルなWikiです。 gollum -- A git-based Wiki GFMで記述するようにもできますし、レポジトリに直接コミットしてもちゃんと拾ってくれるので、取り敢えず適当なテキストエディタで殴り書いたメモを取り込む場合にも手間があまりかかりません。 勿論複数人でバリバリ使うような用途には向いていないかもしれませんが、個人的な用途で使う場合にはその手軽さが助かります。 Dockerで構築 一昔前ならローカルにLAMP環境を構築したり、VirtualBox等で仮想VMのLinuxを起動して〜となるところですが、今の
システム開発の常識を覆す「サーバレスアーキテクチャ」について「AWS Lambda」を使って構築方法を学ぶ本連載「AWS Lambdaで始めるサーバレスアーキテクチャ入門」。前回の「簡単なサーバレスアプリ構築で分かるAWS Lambdaの実装方法の基本」では、サンプルとなるサーバレスアプリケーションの構築を例にAWS Lambdaを使ったアプリケーションの実装方法を紹介しました。 最終回となる今回は、AWSとSlack、GitHubを連携させたサーバレスアーキテクチャの構築方法について解説し、他に3つのサーバレス活用事例を紹介します。 SlackとGitHubの連携 SlackにはもともとGitHubと連携するための仕組みが用意されているため、既に利用されている方が多くいるかと思います。普段利用する分には十分ですが、GitHubとSlackとで異なるユーザー名を登録してしまい、メンションが
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
GitBucketとは GitBucketはたけぞうさんという方が開発されているGitHubのクローンアプリです。 Scalaで書かれており、驚くほど簡単に導入することができるのが特徴です。 OSSのGitHubクローンといえばGitLabがメジャーですが構築の手順が複雑かつ面倒なため、 使い始める前に構築段階で挫折した経験のある人も多いのではないでしょうか。 対するGitBucketはwarファイルを実行するだけという手軽さです、素敵!! より詳しいレビューはこのあたりを参照してください。 背景 とあるクラウド環境にGitBucketを導入する機会があり、 せっかくなので vagrant + ansible で導入を自動化するplaybookを書いてみました。 以下のクラウドプラットフォームで導入検証をしました。 AWS DigitalOcean したごしらえ Case: AWS vag
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
January 22, 2014 github git github-flow 図解 チーム 「github チーム 使い方」とかでggってみたら、git-flowとGithub-flowがごっちゃになっててわかりづらい。他の人に説明する時にも使いそうなので、個人的にまとめてみた。 Contents Github flowって何よ? 概要教えて 特徴は? 欠点は? 流れを図で説明して 実際にどうやんの? リポジトリを準備する 各ユーザーをCollaboratorに登録する git clone masterからgit branch コーディング git push pull request masterブランチへmarge 直ちにdeploy ブランチを削除 git pull 参照 Github flowって何よ? 複数人で開発するときに、github上のリポジトリをどう運用するかをまとめたも
結論から言うと featureブランチを開発マスタ用ブランチにマージするなど、あるブランチをあるブランチにマージする依頼を出す点は同じ。 GitHub と GitLab では使い方の違い上、使われる言葉が違う。 ※ GitHub では、開発する際にリポジトリをForkしてローカルブランチを作成することが想定されている。 Gitlab では、開発する際に同一リポジトリ内で開発ブランチを作成することが想定されている。 Merge RequestまたはPull RequestはGitマネジメントアプリケーションで作成され、指定した担当者に2つのブランチをマージするよう依頼します。GitHubやBitbucketでは最初のアクションとしてfeatureブランチをプルするため、Pull Requestという名前を使用します。要求され、最終的に行うアクションという意味でGitLabやGitorious
git-flowとは、プラグイン(ツール)のことです。。 Vincent Driessen氏がブログに書いた"A successful Git branching model" というブランチモデルの導入を簡単にする git プラグインである。 参考資料: ・ http://hm-solution.jp/lifehack/post2475.html ・ http://d.hatena.ne.jp/Yamashiro0217/20120903/1346640190 Git-flowイメージと各ブランチの役割 master: プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。 develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。 feature branches: 機能の追加。
Git, GitHub, GitLabそれぞれの特徴 *注意事項:当初は、GitHub Flowを入れる想定で調べていましたので少しGitHub Flowとの比較の観点が強いです Git Flow 使用するブランチ master マイルストーン用のブランチ develop 開発用のブランチ feature 機能追加用 (hot)fix 不具合修正用 release リリース準備用 Git Flowの良さ fix(不具合)の数が一目瞭然 masterを見ればマイルストーンの遷移が一目瞭然 参考:git-flowとプロジェクトの運営 Git Flowのまずさ ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない hotfixブランチをdevelop, master共に反映しなければならない点が面倒 参考:【翻訳】GitLab f
先日GitHub Universeをダラダラと聞いてたら、Git LFSの1.0がリリースされてGitHub上で使えるようになったらしいので試してみました。 追記 2016/8/20: まだベータでしたがBitbucketでも使えるようになってました。試したら詳しく追記します。 2017/5/20: git lfs initがgit lfs installにrenameされていたのでその旨追記しました。 概要 Git LFSはGitHubが中心となって開発しているラージファイル(画像・音声・映像等)を扱うための拡張機能です。gitレポジトリにはテキストファイルのポインタを保存しておいて別の場所にラージファイルの実態を保存しておくことができます。これによって不要なファイルのpullやfetchをすることなくgitレポジトリの最新化ができるようになったりします。 先日のGitHub Unive
どうも、まさとらん(@0310lan)です! 今回は、ブラウザ上のGitHubでMarkdown(マークダウン)ファイルを作成し、そのまま超高機能なスライド資料に変換してくれるサービスのご紹介です! もちろん、自分でMarkdownファイルを用意してpushするだけでもOKなのですが、今回はコンソール画面などは使わずにすべてブラウザだけで完結できる方法をご紹介致します。 【 GitPitch 】 ■「GitPitch」の基本的な使い方! それでは、実際に簡単なスライド資料を作ってみましょう! まず最初に、自分のGitHubアカウントでログインし、新規のリポジトリを作成しましょう! 「① リポジトリ名」は好きな名前を付けてください。 画面下にある「② チェックボックス」をONにしてから「③ Create repository」ボタンをクリックしましょう。 すると、自動的に「README.md
問題 プルリクエストのレビュー、動作確認をするためにローカルでcheckoutしたいが、ブランチ名を調べて入力するのが面倒くさい。別名をつけてcheckoutできるようにする方法があるが、プルリクエストの番号を調べる必要があってそれも面倒。 もっと簡単にcheckoutしたい!!! 解決策 プルリクエストの一覧からブランチを選択してcheckoutできるようにしました。 1. プルリクエスト一覧を取得する まずプルリクエスト一覧を取得します。そのためにprfetchというスクリプトを書きました。 手っ取り早く下記でインストールできます。 wget https://raw.githubusercontent.com/yuku-t/dotfiles/master/bin/prfetch chmod +x prfetch mv prfetch ~/bin # ~/bin はPATHに入っていると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く