TLDR; the default GitHub labels kinda suck; use a sane labelling scheme instead; and use git-labelmaker to simplify GitHub label editing. If you work for a company that manages any part of their codebase using GitHub, or if you work in some open-source repositories with at least a few contributors, then I’m sure you’re aware of how wonderful labels can be at organizing everyone’s work. Maybe you n
今日からはじめるGitHub ～ 初心者がGitをインストールして、プルリクできるようになるまでを解説 エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ソースコードの管理はできていますか？ ファイルを修正するときに、修正前のソースコードをhoge.php.bakのようなバックアップファイルとして残し、開発環境をゴミだらけにしていませんか？ エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ここではGitの詳細な仕組みには触れません。GitやGitHubを利用したことのない人が、Gitを
こんにちは。Backlog のSite Reliability Engineering (SRE) を担当している吉澤です。 AWS アクセスキーを含むコードを GitHub の公開リポジトリにプッシュしてしまい、そのアクセスキーがビットコインの採掘に使われて AWS から高額請求が来た！という話をたまに目にします。今年の2月に検証された方（GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！)によると、git push から13分で不正利用開始されたらしいです。怖いですね……。 Backlog のソースコードは Backlog の提供する Git リポジトリで管理しています。Backlog の Git にはリポジトリの公開機能はないので、AWS アクセスキーをプッシュしたからといって即座に悪用される可能性は低いです。とはいえ、漏洩時の影響が大きいため、AWS
.gitignoreをプロジェクトの度手書きしていませんか？ 毎度毎度 *.DS_Store や Thumbs.db をignoreファイルに含めていませんか？ 地味に面倒くさいけどプロジェクトの最初だけだからまぁいいかとなりがちなgitignoreファイルをスマートに生成・管理しましょう。 gibo: git ignore boilerplate フレームワーク固有・ディストリビューション固有のgitignoreの内容はほとんどの場合同一です。 GitHubが公開しているgitignoreのテンプレート集（github/gitignore: A collection of useful .gitignore templates）に使っているフレームワークなどがあれば、必要なテンプレートを選んでコピペすればOKです。 しかし、いちいちブラウザでこのページを開いたり、cloneするのも少し面
2016年1月に Git 2.7 がリリースされました。 色々なコマンドが増えたりしていますが、なかでも .gitignore に関する仕様追加が興味深かったのでまとめます。 .gitignore とは Git で管理したくないファイルを設定するためのファイルです。 たとえば .gitignore ファイルにこのように書いて置いておくと、 *.json /sample-folder 拡張子が .json のファイルと、 /sample-folder というフォルダ配下は Git で管理されなくなります(変更などがあっても無視される)。簡単ですね。 .gitignore の設定を、打ち消したい場合 ! 記法で、設定の打ち消しが可能です。 たとえばこう書くと、 *.json !required.json 拡張子が .json のファイルは無視されるのですが、 ! をつけた required.j
Gitで別々に作ってたリポジトリをコミットログを残したまま1つにしてしまいたい時のめも。 例えばkankore_repoとkuchikukan_repoという2つのリポジトリが別々にあったとします。 これらを別々のリポジトリで管理するのが大変になってきたのでkankore_repo内の'destroyer'ディレクトリに kuchikukan_repoで管理していた全てをコミットログを残したまま入れてしまいたい。そんな感じです。 図で書くと /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git /kuchikukan # kuchikukan_repo リポジトリのあるディレクトリ |--- .git これを ↓ のような感じにしたいのです！ /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git |--
お仕事でエンジニアしてないと本当にどんどん忘れて言っててヤバイって感じてる今日このごろな訳です。 マージしたブランチの消し忘れとか不要なブランチが残ってると見通しが悪くなるのでリモートリポジトリのブランチは定期的に整理したい訳です。で、リモートのブランチを削除する方法。gitHubとかBitbucketとか使ってるとサービス上で削除できるのですが、まぁコマンドで削除する方法を。忘れてたので、メモしておきます。 リモートのブランチを削除する手順 $ git branch -a * master release/20160229 remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/release/20160229 こんな感じにブランチがあります。 release/20160229はmasterにマー
Fork is getting better and better day after day and we are happy to share our results with you.
ありがちなgitの失敗とその修正コマンドをまとめました。(´﹃｀) masterブランチで作業を始めてしまった！ Σ(llﾟ艸ﾟll) git stash をすると、stashリストに書きかけのソースが退避して登録される。 なので、git statusとしても"nothing got commit"となり、変更が隠される。 ちなみにstashはこっそりしまう、という意味。 git stash list とすると、退避されているソースのリストが表示される。 コードを持っていきたいブランチに切り替えて、 git stash apply とすると、最後にstashされたものがそのブランチで反映される。 直前のソースではなく、特定のstashしたソースを指定したい場合は、 git stash apply stash@{[git stash listで確認した番号]}とすると、適用できる。 べつにm
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Ultimate Guide to Automated WordPress Deployments - SpinupWP
