この記事は富士通クラウドテクノロジーズ Advent Calendar 2020 の6日目の記事です。 5日目は @tmtms さんの「RubyNet::SMTP 」という記事でした。 2021年に向けて、普段何気なく使っているSMTPをプロトコルから改めて振り返る機会になりましたね。 はじめに仕事では、ITインフラストラクチャサービスの企画・設計・開発・運用を担当している @ysaotome です。 この記事では、会社でGItLab Enterprise Edition (EE) の Premium を導入した話を書きたいと思います。 ※社内のLT大会でプレゼンした内容を改編した内容になります。 祝!GitLab Enterprise Edition導入! 会社でGitLab Community Edition (CE) を導入したのは遡ること 6 年前の 2014 年頃にな

gitはどうしても独自プロトコル+sshを使って欲しいのだろうか。HTTP認証がいい加減すぎる。libcurlでデフォルトでできることしかできない。 認証方式の指定ができない まず、認証方式を指定することが一切できない。BASIC認証なら一応使えるが、それもlibcurlが無指定でやってくれてる分だけ。 ユーザ名、パスワードがconfigに保存できない ユーザ名やパスワードはconfigファイルに保存できて然るべき情報。これができないのでは対応する気がないと言わざるを得ない。 一応指定する方法はあるが、スマートではない。netrcファイルを使う $HOME/.netrcに以下のように書いておく。machine www.example.comlogin username password password もちろんこれだとBASIC認証しか対応できないし、1つのホストに対して1つのユー
これでリポジトリの移行も完了! 2019/10/03追記 hiroponzさんコメントより、GitHubからの移行なら、以下で丸っとインポートできます。GitHubを使用している場合は、「New Project」→「Import Project」→「GitHub」で、リポジトリ以外にも「Issue」と「Pull Request」と「Wiki」も一緒にインポートできて便利です。 コマンドベースの操作だと、自前のローカルリポジトリを移植する際に使えるのが良いです。また、本記事の記載方法だとmasterブランチのみなので、全ブランチ、タグを取り込む方法もまとめました。GitLabを少し触ってみた感想 とりあえずGitHubで普段使う機能は大抵あるGitHubで便利だなと思った機能は大体あります。 ただUIが大分小洒落た感じでいいですが、操作感はあっちこっちにタブが飛ぶのがちょっと苦手。好み

はじめに 読んだ。GitLab実践ガイド (impresstop gear) 作者: 北山晋吾出版社/メーカー: インプレス発売日: 2018/02/01メディア: 単行本(ソフトカバー)この商品を含むブログ (1件) を見る Git大好きエンジニアで、もちろんGitLabも仕事で愛用してますし、もう社内のGitLabなしでは僕は仕事できません(笑)仕事のすべてをGitLabにおいてるので。。。まぁlocalでは作業できるけど。。。 そんなGitLab大好きマン、この書籍出るっていうのでまぁまず買うよね。 軽く内容をさらいつつ、気になる点はgitlab.comで試してみる。 第1章GitLabが目指す開発スタイル まずはプロダクトの思想から。大事ですよね。 DevOpsの考えを前提とした上で、ConvDev(Conversational Development)というスタイルを推奨

オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。

はじめに Gitのコマンドについて、ネットで検索すれば簡単に見つけることができます。 ただ、Gitの仕組みを理解せずに、おまじないのようにコマンドを実行している方を多く見かけます。というか、少し前まで自分もそうでした(笑) そこでGitの仕組みについて、備忘録的ですが、情報をまとめてみました。 実際、仕組みを理解することで、コマンドを覚えやすかったので、皆さんにも参考にしていただければと思います。 ※もし誤りや不足等がありましたら、コメントいただけると大変助かります。随時修正していきたいと思います。本記事の対象者 gitを初めて使う方 gitのコマンドをおまじないのように実行している方 gitの仕組みについて学びたい方 難易度:★☆☆ そもそもGitとは Gitとは、分散型バージョン管理システムです。 すごくざっくり言うと、サーバーにデータベースが一つだけある状態でなく、開発者の各PCに

TL;DR 突然ですがクイズです。「追跡ブランチ (tracking branch)」という言葉の使い方で正しいのはどれだと思いますか? origin/master はリモートリポジトリの master を追跡する追跡ブランチである origin/master はローカルの master に追跡される追跡ブランチである ローカルの master は origin/master を追跡する追跡ブランチである 現在の正解は多分3番です。過去には1番でした。 分からなかった方、分かったけど他人に「追跡ブランチ」と言って伝わるか不安な方。大丈夫です。正確な用語1で言い換えることにしましょう。 origin/master はリモートリポジトリの master を追跡する**リモート追跡ブランチ (remote-tracking branch)**である origin/master はローカルの ma

この投稿は インタープリズム的「俺達私達の進捗を上げる25個前後のTips」 Advent Calendar 2015 - Qiitaの1日目 の記事です。 こんにちは、Imamotoです。仕事に役立つTipsの紹介ということで、今日は最近自分の開発を快適にしてくれた豆知識として、現場はSubversionだけど自分だけこっそりGitで開発しちゃう方法を紹介します。 Subversionでのバージョン管理、捗ってますか? 唐突ですが皆さん、現場でバージョン管理は捗っていますか? バージョン管理システムはGitですか?それともSubversion(svn)でしょうか。 もしSubversionであり、尚且つSubversionであることに多少なりとも不満を感じているのであれば、 この記事はお役に立てるかもしれませんので気が向いたらご覧になってください。 Subversionのつらみ… 私は

今日からはじめるGitHub ~ 初心者がGitをインストールして、プルリクできるようになるまでを解説エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ソースコードの管理はできていますか? ファイルを修正するときに、修正前のソースコードをhoge.php.bakのようなバックアップファイルとして残し、開発環境をゴミだらけにしていませんか?エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ここではGitの詳細な仕組みには触れません。GitやGitHubを利用したことのない人が、Gitを

業務で Git を使っているが、全く利点が無いので、Git 否定的立場で書いてみた。 あくまでも 業務環境での Git についてです。 八つ当たり被害者は、Qiita で一番最初に挙がった下記ページ様です。 qiita.com まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している(Git Lover)と言ってもいいくらいです。 私は Git が好きでも嫌いでもない人間です。 ただ、特に製品開発をしている現場(特に大手メーカ)では、単に「新しい」「世間で流行っている」というだけで新しいソフトを導入しているような気がしています。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 新しい VCS の利点のみしか見えなくなり、理想形ばかりを夢見ていないでしょ

Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。)本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう

TL;DR 気軽に $ git config --global http.sslVerify false するな💢 今回のおはなしは要するにこれ→ https://github.com/Microsoft/Git-Credential-Manager-for-Windows/issues/646 KasperskyのWeb保護をオンにしているのであれば今すぐオフにしましょうというお話でした。 やったこと: gitを最新版にアップグレードする opensslを使って $ openssl s_client -connect www.github.com:443 して問題の証明書を見る(今回の場合) 以降、どうやってこれにたどり着いたかの備忘録です。 Step 1. gitから事情聴取 gitが叫んでいる通り、、エラーとしてはSSLcertificate problem: self sign

SVNからGitへの移行を考えたんだけど… 10年ほど前にバージョン管理ソフトウェアとしてSVN(TortoiseSVN)を使い始めました。現在はドキュメントもソースコードもバージョン管理なしの世界には戻れないなと感じています。世の中的にGitが流行っているのは知ってたんだけど、職場でもGitに移行するって話は具体化しなかったし、いろいろ不便はあったけどSVNに慣れちゃってたんで、Gitの導入はしてませんでした。久しぶりに技術ブログを書くにあたって、サンプルコードを共有するならGitHubがいいかなーと思い、ようやく使い始めたところです。 なるほど、GitはオリジナルのリポジトリをローカルPCにコピー(クローン)して、ローカルで一旦コミットしてから、オリジナルにプッシュするという二段構えの構成になっている。個人の作業は成果物が完成するまでローカルで進めるので、マージの衝突頻度が緩和されるん
本記事は当初SVNとGitの比較として「ブランチを用いた開発フロー」のメリット・デメリットについて記載していましたが、 「SVNでもブランチを利用できること」「分散型という言葉に対する記載の誤り」についてご指摘をいただきました。 そのため、ブランチを利用した開発フローに対して感じたことを焦点に記事を修正しております。誤った情報を記載していたこと、SVNに対して誤ったイメージをもつ可能性のある記載をしていたことに対し、深くお詫び申し上げます。 Gitをまともに使い始めて約二ヶ月がたちました。 特に、「ブランチをきる」「修正する」「レビューする」「マージする」という、おそらくGitで想定されている開発フローに沿っての開発はクラスメソッドに入社してからが初めてです。 6月に入社する以前は、開発用のソースコード管理には主にSVNを利用し、1つのバージョンの流れに全ての修正をコミットしていくフローで

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く