日本のDX促進の突破口となれるか？ DevSecOpsを一括でカバーするGitLabの魅力
ソフトウェアの開発プロジェクトにおいて、ライフサイクルのすべての情報やタスクを管理するのに欠かせないリポジトリ管理。バージョン管理システムGitを使ったリポジトリサービスはいろいろ登場しているが、最近、注目を集めているのが「GitLab」である。今年3月に日本法人 GitLab合同会社を設立。なぜこのタイミングで日本に進出したのか。またGitLabとはどのようなソリューションなのか。そのコンセプトや活用するメリット、さらにはGitHubとの違いなどについて、カントリーマネージャー（日本担当）の村上督氏、シニア・ソリューション・アーキテクトの伊藤俊廷氏にお話を伺った。 GitLab 日本担当カントリーマネージャー 村上督（むらかみ ただし）氏 Citrix SystemsやAcronisなどの企業で経営幹部を務めるなど、テクノロジー分野に25年従事。複雑な販売情勢下におけるダイレクト販売や、
自由民主党: 日本国憲法改正草案-2012-04-27 by atsuya · Pull Request #1 · atsuya/constitution-of-japan
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
超一流プログラマーはどういう働き方をしているのか？
By Jefferson Santos 多くの社会人は決められた勤務時間に従って仕事をしているわけですが、フリーランスのプログラマーには「時間にとらわれることなく、フレキシブルに仕事をしているのでは？」という偏見がついてまわり、ましてや超一流プログラマーともなれば「起きている時間は常に働いているのでは？」という想像上の生き物的な扱いをされる場合もあります。そんな中、ブロガーのIvan Bessarabovさんが「超一流プログラマーの勤務時間」を明らかにしています。 At what time of day does famous programmers work? https://ivan.bessarabov.com/blog/famous-programmers-work-time At what time of day does famous programmers work? Par
Write yourself a Git!
This article is an attempt at explaining the Git version control system from the bottom up, that is, starting at the most fundamental level moving up from there. This does not sound too easy, and has been attempted multiple times with questionable success. But there’s an easy way: all it takes to understand Git internals is to reimplement Git from scratch. No, don’t run. It’s not a joke, and it’s
クソ簡単にgitの説明をする
どこもかしこも妙ちくりんな図で混乱させてくるのうざい 自分で書いてみる gitなんてクソ難しいんだから、きちんと概念を理解させようとかすんなよ なぜgitが必要かバージョン管理のために必要、と言うと意味わからんと思う プログラムみたいなのは少しずつ変更していくんだ だから細かに変更の差分を管理したり、変更を戻せたりしなきゃきつい なぜgitか？他のバージョン管理との違いうるせぇgit使え そんなの来年考えろ gitの基本要素、用語branch： いきなり説明が難しいが、branchがわかればどうにかなる。 例えば、今編集しているプログラムに対して、RPGのセーブデータがあると思ってほしい。 それぞれのセーブデータがそれぞれのブランチにあたる。 セーブデータが1枠しか無いと、難しいだろ？何があるかわからない、戻ったり、試したりしたいからな。 セーブデータと少し違うのは、1個のブランチでも過去
Goにおけるバージョン管理の必要性 − vgoについて −
Takuya UedaSouzoh, Inc. (affiliated by Mercari, Inc.) - Go Engineer
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
Emacsで現在見ている行を変更したPRを開けるようにした - $shibayu36->blog;
このコードどうしてこうなってるのかという経緯を知りたい時、git blameなどのコマンドを利用することが多い。しかし、git blameだとその行を変更したcommitが分かるだけであり、経緯が結局分からないということがよくある。 そういう時にその行を変更したPRを開けるようにしたいなーと思って、いろいろやったところ、Emacsで現在見ている行を変更したPRを開けるようになったのでメモ。 特定のコミットが含まれるPull Requestを開くには 前段階として、特定のコミットが含まれるPull Requestを開くということをやってみる。これは既にいろいろやっている人がいて Commit Hash から、該当 Pull Request を見つける方法 - Qiita How to find pull-request by a commit sha - Pitr.ch Gitベースのコード
Git LFSをAmazon S3でいい感じにする話 - YDiary
はじめに 皆さんはソースコードリポジトリの保存先として，GitHubなどのホスティングサービスをお使いでしょうか． また，リソースファイルなどのバイナリファイルを管理するためのリポジトリのサイズが肥大化していたりしないでしょうか． 実は，GitHubなどのホスティングサービスでは推奨されるリポジトリのサイズが決められており，そのサイズを大幅に超過するようなリポジトリは運営による凍結・削除の対象となってしまうことがあるのです． この記事では，そうしたリポジトリの肥大化を，バイナリファイルをソースコードとは別で管理することによって防ぐことが可能なGit LFS (Large File Storage)と，Git LFSのサーバとしてAmazon S3を活用する方法などを紹介します． 推奨されるリポジトリのサイズ 各ホスティングサービスで推奨されるリポジトリのサイズは次の通りです． GitHub
commit をどう分割すべきか 〜コードレビューの観点から〜
普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request（以降 PR）ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか？ コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ：git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
git clone 時の秘密鍵指定と git のバージョンについて
こんにちは、野口です。 git clone 時に、特定の秘密鍵を指定したい場面があり、どのように対応したかを紹介します。 通常の状態で git clone すると、 ~/.ssh/id_rsa の秘密鍵をみてくれます。例えば /tmp/ssh/id_rsa をみてほしい場合、どうすればよいでしょうか。 ~/.ssh/config で秘密鍵を指定する ~/.ssh/config に秘密鍵のパスを指定すれば良いです。 $ cat ~/.ssh/config Host github.com User git IdentityFile /tmp/ssh/id_rsa ただ config ファイルはいじりたくなかったので、他の方法を探してみました。すると、 GIT_SSH_COMMAND で指定する方法が見つかりました。 環境変数 GIT_SSH_COMMAND で秘密鍵を指定する $ GIT_SS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これならしんどくないGit運用の考え方
SUSE OpenStack Cloud 8 New Capabilities Update
Blog | Perforce