Gitでやらかした時に使える19個の奥義 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
git,GitLabを1年半使った現状 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、河野です。 一昨年にgitについての社内勉強会を行い、その内容を gitの勉強会「はじめようgit」を行いました にてまとめました。それから1年半ほど経ったので現状をまとめようと思います。 ワークフロー git flow、GitHubフローを参考に始めましたが、現在は develop,master,各feature以外に、stagingブランチを設けるようにしています。 自分がいるチームは、SIのプロジェクトが中心なので頻繁にリリースすることはありません。ですので、 各featureブランチで機能を開発→developへマージ 社内のテストはdevelopを中心に行う→テストが一巡したらstagingへマージ お客様確認用のステージング環境へはstagingブランチを使用 ステージング環境でのテストも終わったらmasterへマージ 最新のmasterをリリースし、タグを打つ と
面倒くさいsvnリポジトリをgit-svnで扱う時に役立ちそうなオプション一覧 - アジャイルSEの憂鬱
最近は分散バージョン管理が主流になり、gitやhgを使う事が増えてきたと思う。 ただ、政治的な事情でsvnを使わなければならない事もあります。 そんな時に役立ちそうなgit-svnのオプションを備忘録として一覧にしておきます。 標準ディレクトリ構成のリポジトリ svnの標準的なディレクトリ構成の場合は一番楽。 例 ./trunk/src ./branches/v1.x/src ./tags/v1.0.0/src 使うコマンド この場合、オプションに -s（もしくは--stdlayout）を使用する。 $ git svn clone -s <svnのURL> 非標準ディレクトリ構成のリポジトリ 色々な事情により、標準的なディレクトリ名を使っていない場合。（複数プロジェクトは後述） 例 ./dev/src ./support/v1.x/src ./release/v1.0.0/src 使うコマ
git push での容量制限エラー - あじーん-0.0.2-SNAPSHOT
発端 とある大きな内容を git push しようとすると 見慣れないエラーで失敗しました。 error: RPC failed; result=22, HTTP code = 411 fatal: The remote end hung up unexpectedly fatal: recursion detected in die handler 解決策1 411 なので送信量の指定がきちんとされていない？と思いつつ、 調べてみると gitlab のフロントにいる nginx が受けつけられる サイズの最大量を超えてしまっていたよう。 これを解決するために nginx の gitlab 用設定に client_max_body_size 100M; を一時的に追加しました。 解決策2 しかしそれでも同じエラーが発生していたのでさらに調べたところ、 git が送信するファイル量が多すぎる
GitLabとRedmineを連携してみるの巻 - アルパカDiary Pro
はてなブログさんの開発フローのお話 少し前の話になるんですが、GitHubKaigiで はてなブログさんの開発フローについて発表がありました。 その中で 当初はGitHubとRedmineを併用していたが、 両ツールの連携がイマイチだったので Redmineを止めてホワイトボードでタスク管理するようにしたという内容がありました。 https://speakerdeck.com/shibayu36/hatenaburogutimufalsekai-fa-hurotogithub 「ふむふむ、なるほどなぁ」という感じで非常に勉強になったのですが、 もしかしたら 「"GitLab＋Redmine" ならツール自体が連携機能を持っている」 のでもう少しマシになるのかも？とも思いました。 そこで、GitLabとRedmineを使うと 一体どういうことが出来る様になるのか？といったところを紹介してみま
RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題 - プログラマの思索
RedmineとGitを巡る疑問点をメモ。 詳細は後で書き足す。 【参考】 チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索 分散バージョン管理ツールにおけるブランチ戦略: プログラマの思索 Gitによるチケット駆動開発の事例: プログラマの思索 A successful git branching model とgithub flowの比較: プログラマの思索 第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索 GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索 【1】Redmineは日本のSIでかなり普及しているらしい。 その状況と並行して、オープンソース界隈では、GitHubでチケット管理する運用も多い。 すると、最近の状況としては、RedmineとG
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
SVNを捨ててGitを使うべき5つの理由 - Qiita
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです（たぶん）。 それが今で
もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
VSS ユーザーがゆるやかに Git に移行するためのゆるいガイド
VSS = Visual SourceSafeまだまだ、たくさんの現場では、VSS (Visual SourceSafe) が使われ続けています。それをどうこう言うつもりはまったくありません。現場で一番良いと思うものを使うは決してイケないことではないからです。 ただ、以下の事実は知っておかなければいけません。 VSS について知っておいてほしいことVSS は単体での販売をすでに終えています。要するに新規ユーザー分のライセンスを購入することはできません。また、メインストリームサポートもすでに終えています。 以下は、Visual SourceSafe 2005 で記載していますが、VSS 6.0 などはすでに延長サポートも含めて終了しています。 単体販売の終了日: 2011年12月末メインストリーム サポート終了日: 2012年7月10日延長サポートの終了日: 2017/7/11MSDN サブ
インフラ構築手順書 RedmineとGitのLDAP(ActiveDirectory)認証設定
※CPANは、管理が面倒なため、[Auth::Simple]はEPEL testing リポジトリからインストールする。 ■依存するモジュール [Auth::Simple],[Auth::Simple::LDAP]をインストールする前に、依存関係があるモジュールを事前にインストールする。 # yum install perl-LDAP perl-Params-Validate perl-Module-Runtime \ perl-Module-Implementation perl-Class-Accessor perl-Class-Data-Inheritable \ perl-Crypt-PasswordMD5 perl-Test-Simple ■[Auth::Simple]のインストール EPEL testingリポジトリから[Auth::Simple]のインストールする。 # yu
git2.1をCentOS6にtgzからインストールする - まーぽんって誰がつけたの？
CentOS6で、yumで入るgitのバージョンが1.7で、1.7だとgit mvを経由しないでmvした場合に、git addしただけだとrenameを検知してくれなかった。ローカルPCのMacのgit(2.0)だとできたからgitも進化してるんだなーと思った。 まぁそんな前置きはおいといて、CentOSに新しいgitをインストールする。 yumでできたらいいんだけど、公式見てもググっても出てこなくて、基本ソースからコンパイルするしかなさそうだった。 How to install the latest GIT version on CentOS | HowtoForge - Linux Howtos and Tutorialsを参考にする。 # 1. まず最初のyumで入れちゃってたやつを削除 yum remove git # 2. 参考URLのやつとプラスperl-ExtUtils-Ma
git-svnを利用した運用を考える - Qiita
最近、諸事情あってsubversionからgitへプロジェクトの半ばでバージョン管理を変更しました。その際にちょっと変わった形でgit-svnの運用を行う事になったのでやりかたに関して簡単にログを残しておきます。 プロジェクトを取り巻く事情 今まではSubversion(仮にメインとします)を用いた運用を行っていたのですが、気軽にtrunkに対してコミットする事が出来ない事情がありました。では、メインSubversion上にbranchをたてればいいじゃんという話になるのですが、ブランチすら気軽に切る事が出来ない状態でした。その上、メインのSubversionにコミットすることが可能なのはコミッターだけとなっておりコミッターの負担が増えつつありました。 今までの運用 今まではメインSubversionとは別に 同期しないSubversion(仮にローカルとします)を別途立てて、なんと手動で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Redmine+SVN/Gitの環境構築 (3)』