プログラムの実行時間を99％短縮した「たった1行のコード」とは？
プログラムの実行速度やウェブサイトの表示速度は、たった数秒の改善でも多くのエンジニアたちの苦心を必要としますが、時として拍子抜けするほどにあっけなく、かつ劇的な改善がなされる場合もあります。画像共有サービスのPinterestが自社のブログで「たった1行の変更でコードの実行時間を99％短縮した」事例を紹介しています。 How a one line change decreased our build times by 99% | by Pinterest Engineering | Pinterest Engineering Blog | Oct, 2020 | Medium https://medium.com/pinterest-engineering/how-a-one-line-change-decreased-our-build-times-by-99-b98453265370
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Gitでよく使用するコマンドをGIFアニメで解説
Gitでよく使用するコマンドが何を行っているかをGIFアニメで解説した記事を紹介します。 Gitのマージ、リベース、リセット、チェリーピック、フェッチ、プル、リフログなど、コマンドを実行した時にブランチはどのように相互作用し、履歴にどのような影響を与えるのか視覚的に学べます。 🌳🚀 CS Visualized: Useful Git Commands by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Gitのマージ（fast-forward, no-fast-forward） Gitのリベース（rebase） Gitのリセット（reset, revert） Gitのチェリーピック（cherry-pick） Gitのフェッチ（fetch） Gitのプル（pull） Gitのリフログ（re
GitHubが大変身！Web開発向けの万能ツールに変えてくれるサービスをまとめてみた！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回はGitHubと連携してソースコードをさまざまな用途に活用できる便利なWebサービスを厳選してご紹介しようと思います。 特にWeb開発を便利にしてくれるサービスを中心に、GitHubだけでどこまで作業効率を向上できるのかをぜひ確認してみてください！ なお、paizaラーニングでは「Git入門編」講座を公開しています。そちらも合わせてチェックしてみてください。 ■GitHubをフル装備のクラウドIDEに変えるサービス！ 【 Gitpod 】 GitHubに置いているリポジトリのソースコードを統合型のクラウドIDEで自由に編集できるサービスが「Gitpod」です。 TheiaをベースにしたVS Codeライクなコードエディタで、豊富な機能と拡張性を備えておりプログラミングに最適なIDEの一つと言えるでしょう。 使い方は簡単で、リポジトリのページ
[社内新人向け]Gitで使ってほしくないコマンド - Qiita
社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。 本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。 (追記：第二弾できました) → [社内新人向け]Gitで絶対にオススメなプラグインや設定3つ 社内環境 Web系開発がほぼ100％ ブランチワークはGitflowをベースにしたプルリク駆動開発 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい（vagrantや開発サーバ上の操作など） GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました CIツールはまだ導入できず。各サーバーへのデプロイ
![[社内新人向け]Gitで使ってほしくないコマンド - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c02b564a55050853439b0f6986d3aa42501396d4/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUE0JUJFJUU1JTg2JTg1JUU2JTk2JUIwJUU0JUJBJUJBJUU1JTkwJTkxJUUzJTgxJTkxJTVER2l0JUUzJTgxJUE3JUU0JUJEJUJGJUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJUJCJUUzJTgxJTk3JUUzJTgxJThGJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgyJUIzJUUzJTgzJTlFJUUzJTgzJUIzJUUzJTgzJTg5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz00YzYzNDI4NzA3YjAxYTI4Y2QzMzAyOTFjYzQzMTkxYQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB6YXJhbW1lJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mZDc5M2U2Y2U4OTg4ZTM4OTI2YmE3NDkyOTc1MDJkZQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dc30c566ec78e040079beb6919643238f)
よりよい機能をより早く届けるためにGit/GitHubを使いこなす10の方法 - Qiita
この記事は freee Engineers Advent Calendarの6日目です。 こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。 僕には「よりよい機能を、より早くユーザーに届けたい」という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ
Gitでよく使うコマンドまとめ - Qiita
Gitリポジトリからソースをクローンする。 $ git clone <リモートのクローン先> [optional ローカルのフォルダ名] リモート操作 リモートブランチも含めたブランチ一覧を表示する。 $ git branch -a 例) $ git branch -a feature2535 feature2558 * master remotes/origin/1.2.1 remotes/origin/HEAD -> origin/master remotes/origin/testbra リモートからブランチを取得する。 $ git fetch origin <ブランチ名> リモートからブランチをチェックアウトする。 $ git checkout -b <作成ブランチ名> <リモートブランチ名> 例) git checkout -b testbra origin/testbra リモ
Git初心者でも分かるGitブランチの作成、確認、切り替え、マージ、削除の手順
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの一つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終えるころには、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 連載第3回目の本稿のテーマは「ブランチの基本」です。 前回の「最低限押さえておきたいGitの超基本的な作業フロー、5つのコマンドまとめ」では「Gitの基本的な作業フロー」を解説しましたが、「ブランチ」についてはほとんど触れませんでした。 今回は実際に作業を進めていきながら「ブランチ」の基本的な要素を解説していきます。 ブランチとは 関連記事 「うわっ…私のバージョン管理、ダメ過ぎ…？」を解決するGitの使い方“超”入門 本連載は、ちょっととぼけた女
Gitのtagとpull requestのマージ履歴からChangelogを自動生成する `ghch` | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghch mackerel-agent のリリースフローでは、前回のリリース以降の、pull requestのマージ履歴を拾って、そこからChangelogを自動生成するということをおこなっている。 これは、1年半前くらいにPerlで書いていたのだが、この度汎用的にしてGoで書きなおした。それが ghch。前回打ったsemverっぽいgit tag以降のマージ履歴を抽出してくれる。例えば、こういう風にmackdownで出力がされる。 % ghch --format=markdown --next-version=v0.30.3 ## [v0.30.3](https://github.com/mackerelio/mackerel-agent/releases/tag/v0.30.3) (2016-04-27) * retry retire
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
僕がよく使うGitコマンド14個 - Mitsuyuki.Shiiba
僕がよく使うGitのコマンドの整理をしておこうと思った。 1. git clone リポジトリから取ってくる まずはcloneするよね。手元にあってちょうど良い感じなのがmakingさんのjsug-shopだったので、これで進めてみる。 $ git clone git@github.com:bufferings/jsug-shop.git Cloning into 'jsug-shop'... remote: Counting objects: 299, done. remote: Total 299 (delta 0), reused 0 (delta 0), pack-reused 299 Receiving objects: 100% (299/299), 427.05 KiB | 193.00 KiB/s, done. Resolving deltas: 100% (96/96),
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
はじめに 英語力をあげるために、コミットメッセージを英語で書こうとしても実践するのはなかなか難しいものです。 GitHubで使われている実用英語コメント集 - Qiita のような記事を読んでもコミットするときには忘れています。 そこで、git commit時に表示されるコメントに、英語でメッセージを書くためのヒントを表示してみました。 完成イメージ やり方 ~/.gitmessage.txt を作成 # fix, add, changeといった事実ではなく、このcommitで実現する要件や仕様を書きましょう。（リファクタなどは除く） # # 例文） # - Fix typo in docs # - Remove unused code # - Remove use of deprecated method # - Update Modernizr to v1.6 # - Make it
気付いたら.gitignoreはgiboで自動生成する時代になっていた - Qiita
$ gibo --version gibo 1.0.4 by Simon Whitaker <sw@netcetera.org> https://github.com/simonwhitaker/gibo $ gibo java ### https://raw.github.com/github/gitignore/8c9b77cb5c85f6464c0bb31abdf4cfcfdf6833bb/java.gitignore *.class # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.ear # virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml hs_err_pid*
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Git 2.x シリーズの 6 つの素晴らしいフィーチャー | Atlassian Japan 公式ブログ | アトラシアン株式会社
私が Git リリース ノートをレビューしてからしばらく経ちましたが 、だからといって私が最新のノートを熱心に読んでおらず、毎日の作業に新たな優れモノを取り入れていなかった訳ではありません。自分の誕生日 (拍手！) と、先日の Bitbucket Server のリリースを祝うため、本日は私が Git 2.x シリーズ (2.6 まで) で気に入っているフィーチャーを全てご紹介します。どれか役に立つようなことがあれば、是非ご一報ください。 リベース前に変更内容をスタッシュ Git 2.6 では、rebase コマンドが皆さんから良い意味での注目を浴びました。以下にご紹介するのは、より興味深い新しいフラグの1つです : git rebase --autostash これからは、rebase 操作の開始時に未コミットの変更内容を一時的にスタッシュするか、操作を失敗させるかを指定できます。この行
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub/基本 - きのさいと
GitHub/コミットをまとめる - きのさいと
git 2.9がリリース，merge/rebase/commitなどに新機能を追加
GitHub - jlord/git-it-electron: :computer: Git-it is a (Mac, Win, Linux) Desktop App for Learning Git and GitHub
