【GitHub x サイバーエージェント共催】GitHub Copilotで変わる開発文化の現実 https://cyberagent.connpass.com/event/292982/
【GitHub x サイバーエージェント共催】GitHub Copilotで変わる開発文化の現実 https://cyberagent.connpass.com/event/292982/
英国グラスゴー大学にて機械工学の博士号を取得。共同設立したスタートアップが2014年に米Microsoft(マイクロソフト)に買収され、同社に参画。2021年にマイクロソフト傘下の米GitHubのCEOに就任。(写真:村田 和聡) Copilotは2つの点で開発者の生産性を高め、ひいては開発者をハッピーにするものです。 1つは、「フロー状態」と呼ばれる超集中状態を維持しやすくなることです。 開発者はプログラミングの途中で、頻繁に何かをリサーチしています。その際、これまで作業していたコードエディターの画面から、Google検索やGitHub、Stack Overflow(プログラミング技術などの知識共有サイト)などの画面への切り替えを余儀なくされます。 さらに、多くの開発者はコードエディターとしてVisual Studio Codeなどをブラウザー上で使っていますが、そのためWebサイトやソ
対象読者 これからGitやGitHubを使い始めようと思っている方 Gitの使い方は知っているが、チーム開発の経験がない方 Gitによるチーム開発のいろは 第1回ではGitの基本的な使い方を解説しました。第2回では、実務・チーム開発の現場でGit、およびGitHubを活用するためのノウハウを紹介します。とはいえあくまで一例なので、自分たちの開発チームに合わせたやり方に適宜カスタマイズしてみてください。 GitHubは、Gitリポジトリのリモートホスティングサービスの1つであり、Gitでチーム開発を行う上で欠かせないものです。GitHubについても後半の節で解説します。 Gitの誕生秘話 まず余談ですが、Gitの誕生秘話について少し触れておきます。そもそもGitはLinuxを開発するために生まれました。つまり、Linuxほど大規模なプロジェクトを、大人数で進められることが要件としてありました
私が普段心がけている PR の書き方やコードレビューの方法をご紹介しようと思います。 そもそもコードレビューってどうやるの、どういった観点でコードレビューをするのか、みたいなところは、わかりやすい記事がたくさんあるので、そちらを参照していだくと良いと思います。 この記事では、 PR の書き方やレビュアーにアサインされた際のコメントの仕方などをご紹介できればと思います。 1. PR を作成する Github に限定した PR の出し方を順を追って説明します。 下記の画像は PR を作成する際の例です。 ご参考までに。 (1) ブランチの設定をする 派生元のブランチと変更ブランチを正しく設定します。 (2) 説明を記入する フォーマットが決まっていればそれに従うようにします。 特に決まっていなければ、 Why , What を書くと良いと思います。 Why なぜこの PR が必要なのかを記載し
GitHub で参考になった英語表現をまとめました。文脈がわかるように原文の URL も記載しています。 🙅 方針に異議を唱える it's hard to ~~~ Select onInput doesn't function in Microsoft Edge · Issue #2331 · preactjs/preact 🤦 誤解を解く We never said that ~~~ Select onInput doesn't function in Microsoft Edge · Issue #2331 · preactjs/preact 🙊 誤解していたことを伝える now I see you suggested this in your original feature request. Type EffectCallback - allow async function
米マイクロソフトは4日、ソフトウエア開発者向けサイトを運営する米ギットハブを75億ドル(約8200億円)で買収すると発表した。マイクロソフトにとって過去3番目に大きいM&A(合併・買収)となるが、サティア・ナデラ最高経営責任者(CEO)による改革を象徴する意味では過去の案件をしのぐインパクトを社内外に与えている。バルマー氏が敵視していたものギットハブは2008年の設立で、同社が運営するサイト
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、
前に書いた記事ですが かなり前に書いた記事でレイアウト崩れてたので書き直した git pullするときに $git pull origin masterって感じでリモートとブランチを書きますよね? 書かなければこんな感じでエラーが出ます $git pull There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=or
いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.
「間違ったコミットをリモートにpushしちゃった!取り消したい!」ってときの操作。上イメージのようにgithubに誤ったpushをした場合を想定して解説してみます。 下記コマンド打つ。 HEAD~2は「直前の2つのコミットを修正対象とする」という意味になります。3つ前のコミットを取り消したい場合はHEAD~3としてください。するとこんな画面が出てくる。 取り消したいコミットを削除して保存します。この場合、2行目のコミットが誤りなので2行目を削除して保存します。うまくいくとこんなメッセージ。
Github、joinしたのは2013年で作ったものは軒並みちゃんと突っ込んではいるんだけど、単に一区切りついたらadd => commit => pushしているだけでちゃんと使っていなかったので、個人開発ではあるがGithub Flowを取り入れてみた。 What is Github flow ? Githubを用いた開発作業を進めるにあたっての指針みたいなものです。基本的にはmasterブランチ上では作業せず、作業工程ごとにブランチ作って、終わったらプルリクしてmasterにマージしてもらうことでデプロイとしましょうね、というものだと理解している。至ってシンプルではあるけど、これを取り入れるだけで従来やっちゃってた「masterで作業してるのでデプロイしても動かないレポジトリがGithub上にある」みたいな状態が防げて良さそうだと思った。 ちなみにGit-flowというのもあるようだ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視1年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 1年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると
なんと毎月 $7 の費用で無制限のプライベートリポジトリを持てるようになりました。 従来のプランでも最低額ですので、既存の有料会員は自動的に新しい無制限プランに移行になっています。 私の場合、従来の Small プランを契約していたのですが、毎月の請求額が安くなり個数制限も撤廃されたことになります。 個人の小さなプロジェクトでもGitHubで管理しようと思えばそれでも足りず、本当に悩みの種でした。結構この制限って厳しいし、高かったんですよね・・・。 法人アカウントは? Organization に適用される旧の料金プランは、最小で $25/月 で10個のプライベートリポジトリを持てるBronzeプランから、一番大きなものは $2,050/月 で1,500個まで持てるAluminiumプランまで、13段階でプランがありました。 法人プランに追加された無制限プランは、ユーザ数で課金されます。具
Private repository とは GitHub 上で作成した Repository は、一般的なウェブサイトと同じく誰でも見ることができるので、見られたくないソースコード等は置きづらい。 Private Repository は、自分(とアクセス権を与えたアカウント)のみがアクセスできるプライベートな Repository であり、見られたくないソースコード等も置ける。 しかし GitHub の Private Repository は有料月額制で、しかも Repository の数に比例した金額となっており、気軽に手出しできなかった。そのため Private が欲しいなら Private Repository を無料で無制限個作れる Bitbucket を使うべし、みたいな意見が主流だった。 ところが最近、GitHub が料金プランの変更を行い、月額7ドルで無制限個の Priv
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです. なお前提としてGitHub Enterpriseを利用しています. git-flow 大上段に構えたもののあまり特殊なことはしていなくて,基本的にgit-flowをそのまま踏襲しています. git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが,ざっくり説明すると masterブランチ,developブランチ,releaseブランチ,featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で,ステージング環境等に上がっている releaseブラン
はじめに 現状 仕事ではSubversionを使用。仕事とは関係なく、プライベートでGitHubを使ってみたい。 GitHubに登録してみたはいいものの、1年くらい放置。 今さらですが、勉強のために、GitやGitHubについてまとめてみようと思った。(自分のメモ用でまとめたので、もし間違ってるところとかおかしいところがあったら教えていただけると助かります) Git とは バージョン管理を行うためのツール。 リモートリポジトリ(共有リポジトリ)とローカルリポジトリを使い分けて開発を行う。 2005年に誕生。もともとはLinuxカーネルのソースコード管理のために、リーナス・トーバルズによって開発された。 売り → 高速。作業時にサーバ接続が必要ない。等 GitHub とは Gitを利用した、リモートリポジトリ(共有リポジトリ)を提供しているwebサービス。 ご利用には登録が必要。無料プランの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く