Features2-way syncing across your stack EnterpriseBuilt for global brands Request a FeatureHelp influence our roadmap Data SecurityEnterprise-level security What is 2-way sync?Find out more about a simpler approach to integration Other Products
Version 1.0.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
株式会社トランスリミット 社内規程 https://github.com/Translimit/company-regulation 順調に従業員が増えてきて、そろそろ労基署へ就業規則を提出する必要があるということで、改めてちゃんとした就業規則を作りました。そして、その就業規則をGitHubで公開することにしました。 これまでは、ネットに落ちている適当なテンプレートを組み合わせて小1時間程度で作成したもので、お世辞にもちゃんとしたものではありませんでした。従業員が10名未満であれば、就業規則を労基署へ提出する義務が発生しないため、このように就業規則が甘かったり、そもそも就業規則なんてものは存在しないスタートアップもあるのではないでしょうか。 今回、弊社は初めて就業規則を労基署へ提出することになりますが、このような状態で中途半端な就業規則のままだと、従業員はおかしな条件で働かされるリスクを負
Pro Git第2版の驚くべき冒険と最終的なツールチェーン ほぼ6年前、私はApressから執筆が予定より遅れていたPro Gitと呼ばれる本の手伝いの誘いを受けました。結局原著者が書き続けないことを決めて、私が最初から書き直して2009年8月頃に最終的に出版されました。最初の3章あたりは、私はWordで本を書きました。そして編集者に文書を送って、しばらくして最終的な版を手にしました。 この3章のあとで、私たちが執筆と技術的な編集段階のためにMarkdownに切り替えて、同意された編集のためにだけWordへ戻るように提案したとき、私はやめようとしていました。一旦本が完成したら、私はすべての内容をMarkdownへ再び戻したので、それを私が作成したWebサイトにおいてオンラインで発表できました。幸運にも、原著者は著作をクリエイティブ・コモンズ・ライセンスとすることでApressと同意しました
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
はじめに 相変わらずブログ環境に悩んでいます。 前にも書きましたけど、私もブログを新しく作るにあたって流行りに乗ってMiddleman+Github Pagesでやろうかなあと思ったんです。 でも、めんどくさいんですよ。 エディタで書いて、git add、git commit、git push、Travis CIでビルドを自動化、middleman-deployとかもあるけど。。。いや、俺ブログにこんなに手を掛けたくない。。。ていうかブログ書くのに黒い画面使いたくない。 APIドキュメントとか会社サイトなら更新多いしGitで管理するのもいいけど、ブログはね。あんま編集しないし。 そういう人は静的サイトジェネレータ使うなとか言われそうですけど、 コンテンツが完全に自分のものになる（いつでも好きなところに引っ越せる） デザインは黒い画面でできて、どんなCSSもJavaScriptも書ける って
2024 著作権. 不許複製 プライバシーポリシー
Tokyo Otaku Mode（以下TOM）でエンジニアをやっているpchwです。 今回は情報共有ツールのお話をさせていただきます。 TOMの開発チームは、創業当初は数人で構成されていたのですが、最近ではフルタイムでないメンバーも含めてかなり人数が増えました。 少人数であればある程度自然に情報共有できるものの、人数が多くなってくると持っている情報量に差が出てきて、なかなかスムーズに共有を図ることができなくなります。 そこで頼りになるのが、情報共有ツールというわけです。現在、TOMの開発チーム内では情報共有のためにesa.ioというサービスを使っています。 なぜesa.ioを使うようになったのか？ esa.ioとはどういうものなのか？ esa.ioは他の情報共有プラットフォームと比べてなにが違うのか？ これらの点を踏まえつつ、esa.ioを紹介していきます。ぜひ参考になさってください。 な
Blazing Fast Incredible generating speed powered by Node.js. Hundreds of files take only seconds to build. Markdown Support All features of GitHub Flavored Markdown are supported, including most Octopress plugins. One-Command Deployment You only need one command to deploy your site to GitHub Pages, Heroku or other platforms. Plugins Features powerful APIs for limitless extensibility. Various plugi
GitHub Enterpriseがやってきた！～導入編～
どうもはじめまして。 シャノンで社内インフラを担当しているma2iです。 入社してからもうすぐ半年になるのですが、時間って本当に早いですね。 今回初のブログ当番という事で、今年買った輸入盤ベスト５でも紹介しようと 思ったのですが、技術ブログなのでそれはダメだそうです・・。 閑和休題。 何を書こうか迷ったのですが、先日社内に導入した「GitHub Enterprise」（以下GHE）に ついて書いてみたいと思います。GitHubについては様々な情報があるのですが、GHEに 関しては日本語の情報がまだ少ない気がします。今回の作業の経緯をまとめることで、 GHE導入を躊躇している管理者の方々の参考になればよいかと思います。 ■GitHub Enterpriseとは？（一応説明しておきます） GitHubをクローズドな環境で使うために、GitHub社が提供しているソフトウェアです。 機能やインタフ
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
Note If you have a project hosted on another Git-based hosting service, you can automatically import your project to GitHub using the GitHub Importer tool. For more information, see "About GitHub Importer." Before you can push the original repository to your new copy, or mirror, of the repository, you must create the new repository on GitHub.com. In these examples, exampleuser/new-repository or ex
[English version] はじめまして、LINE技術戦略室のhayaishiです。 趣味は自転車と言っていますが最近は全く乗っていません。 この記事では、LINEのiOSアプリ開発に関することをいくつかご紹介させていただこうと思います。 LINEのiOSアプリ開発環境 ソースコード管理 ソースコードはgitで管理しています。gitのリポジトリブラウザとしてGithub Enterpriseを利用しており、Githubでお馴染みのPull Requestなどを活用して開発を進めています。 また、LINEのiOSアプリのタスクについてはGithub Enterpriseとは別のチケット管理システムを利用しておりそちらのステータスと連携して開発者、QA、プランナー間の開発状況の共有を行っています。 Gitでの開発フローについて LINEのiOSアプリはgithub-flowの様に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
