とりあえずGitLab-CIを使ってみたくて、簡単なジョブを実行させてみたお話。 GitLab-CIを始める前の設定はこちらの記事を参照してください。 ビルドジョブの概要 以前よりドキュメントをmarkdownで記述し、S3の静的ウェブサイトホスティング機能を使ってドキュメントを公開していました。 ドキュメントはgitでバージョン管理して、MkDocsを使ってhtml化し、S3にアップロードしています。 今回は、この作業をGitLab-CIを使って行います。 実行環境 GitLab 8.7.5 GitLab-CI Multi Runner 1.4.1 GitLab-CIの設定ファイル.gitlab-ci.yml作成 GitLab-CIによるビルドを行うときは、gitリポジトリのルートに.gitlab-ci.ymlを置いてビルド手順を記述します。 .gitlab-ci.ymlの書き方について
概要 日本製 OSS のテキストエディタである サクラエディタ はずいぶんと前から SourceForge.net 上で Subversion 管理されている。 ずいぶんと長い間サービスを継続していただいている SourceForge に感謝の念は尽きない。が、今の時流としては SourceForge による Subversion 管理を続けるよりも、機会があれば GitHub 側に移行したほうが機能追加や修正等のプルリクエストを受け付けやすくなり、品質の向上に繋がるのでは、というのが自分の所感。 今回はコミュニティに対しては事後承認的な形で、サクラエディタ V2(UNICODE版) 部分のリポジトリを GitHub に移行してみる。 コミュニティの承認が得られれば今回の GitHub 移行を正式なものとみなし、更なる整備を進めたい。 移行結果（コミュニティの承認待ち） 移行元: http
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた
コミットログには"Why"を書け？ よくコミットログには「何をしたか」ではなく「なぜその変更をするのか理由を書け」と言われます。 これは確かに一理あります。 例えば、コミットログに などと書かれていたとすると、「いやいや、そんなのはgit log -pすればわかるでしょ。何で変更するのかその理由を書いてよ」と言いたくなります。 そこでチームの規約で「コミットログには理由を書くこと」と定めたとします。 まあよくある話ですね。 そうすると、コミットログはこうなるでしょう。 さあこれでよいでしょうか？ 「理由」を突き詰めると「生きる理由とは？」になってしまう これは確かに立派な理由かもしれませんが、「ではそれは何のために？」と理由をさらに深堀りする人がいるかもしれません。 「なぜその変更がSEO的に有効なのか？」 「そもそもなぜSEO対策が必要なのか？」 これらの疑問はもっともです。 コミットロ
元々 Git というバージョン管理システムは、その性質として大きなファイルやバイナリファイルを扱うのが苦手だった。 そんな欠点を補うために GitHub が開発したのが今回扱う Git LFS (Large File Storage) という拡張機能 (仕様) になる。 git-lfs.github.com これは、大きなファイルやバイナリファイルの実体を Git リポジトリではなく HTTPS サーバで保持することで実現している。 Git リポジトリでは、ファイルを本体の代わりにメタ情報を含むテキストファイルの形で管理することになる。 これらの仕様 (プロトコル) は公開されているため GitHub 以外の Git ホスティング事業者でも Git LFS を実装できる。 github.com 例えば現在では Bitbucket Cloud でも次のように Git LFS に対応している。
Git LFS （Git Large File Storage） とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。 Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。 本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、一方でどういった問題が解決されないかまでを、まとめて紹介します。 Git のラージファイル管理における問題点 まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。 バイナリファイルの管理に不向き Git は、ソースコード（テキストファイル）のバージョン管理に特化したツールです。
ふたつとも、Gitにおけるリポジトリのモデルのこと。 こんなふうにブランチを切って運用していくと便利だよというワークフローのこと。 github flowはgit flowを簡略化したもの。 git flowとは？ http://nvie.com/posts/a-successful-git-branching-model/ より masterブランチ、developブランチがメイン featureブランチ、releaseブランチ、hotfixブランチが補助 masterブランチは常にリリースできる状態 developブランチから、featureブランチ/releaseブランチ/hotfixブランチを切って開発を進める featureブランチは機能追加用(通常の開発用) releaseブランチはリリース直前用 hotfixブランチはリリース後の緊急対応用 git flowでの開発の流れ ①
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 bra
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識：Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）（1/2 ページ） 数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、ブランチ管理の課題と効率的にバージョン管理できる5つのブランチモデルと、ブランチの管理を簡単に行えるツール「git-flow」について。 Gitなどの次世代のバージョン管理ツールの特徴として、ブランチの機能を高度に活用できるという利点があります。Gitのブランチを生かしたツール・フローとして「git-flow」「GitHub Flow」が注目を浴びていますが、本連載では数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、git-flowの概要を紹介します。 効率的にバージョ
はじめに Gitのブランチを活用できていますか？ Gitが人気を博している理由のひとつには、手軽に使えるブランチの存在があります。ブランチを効果的に使えなければ、Gitの真価を発揮することはできません。しかし複数人での開発で、特になんの決まりもなくブランチを使っていると、無秩序にブランチの作成やマージが行われ、リポジトリが混沌としてきます。 こうした問題を解決するために、「ブランチモデル」というブランチ管理方法が考案されました。 今回紹介するのは、Gitのブランチモデルのひとつである「git-flow」です。 ブランチモデルの中では比較的歴史が長く、git-flowをサポートしているツールも数多くあります。やや複雑なモデルではありますが、ツールを使うことでブランチの操作をある程度自動的に行うことが可能です。コマンドを覚えて流れをつかんでしまえば、それほど難しいことではありません。実際にやっ
日本人唯一のGitLab Core Teamの @tnir です。GitLab.JP/GitLab Tokyoオーガナイザとして日本語圏でのマーケティングも注力しています。 統合開発ツールチェイン環境GitLab CE 10.7が2018年4月22日にリリースされました ↑背景画像は東京のサクラの写真でした。東京のGitLabユーザにとっては少しシーズン外れだったかもしれません GitLabには、大きく分けてCommunity Edition (CE) とEnterprise Edition (EE) とありますが、本記事はCEで使えるCore機能のみにフォーカスしています。 2018年3・4月のGitLabトピック(一部) その1. 4/10にGitLab Meetup Tokyo #7: 新年度応援＆GitLab 11.0が東京・サイボウズオフィスにて開催されました。私も参加しましたが
An open source Git extension for versioning large files Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise. Getting Started Download and install the Git command line extension. Once downloaded and installed, set up Git LFS for y
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
最近気になってたchore(package): bump versionなGoogleフォーマットとBump versionなベーシックフォーマットのまとめ。 Googleフォーマット chore(package): bump version Angular.jsなど主にJavaScriptのメジャーリポジトリで人気のフォーマット。 github.com azuが概要をまとめているのでこれを引用する。 feat(ngInclude): add template url parameter to events The `src` (i.e. the url of the template to load) is now provided to the `$includeContentRequested`, `$includeContentLoaded` and `$includeConten
最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまったことが一部界隈で話題になっていました。この件にはマージを行った人に悪意はなかったようなのですが、gitの理解不足により生じてしまった案件だとすると悲しい話なので一応メモ 何が起きたか コミッターが複数の内容が含まれたPRを送った 管理者はその中の一部の内容だけをマージするために、管理者はgit merge --squashを実施し、コミットを改変した上でmergeを実施した ←これが問題 コードの内容はコミッターのものなのに、Authorだけ管理者にすげ変わってしまいコミッターのモチベを損ねた そもそもsquashするとどうなるの ここに分かりやすくまとまっています。 アジャイルSEを目指すブログ 図で分かるgit-mergeの--f
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く