TortoiseSVNのtrunkとブランチをマージする - Qiita
TortoiseSVNでtrunkとbranchをmergeします。 環境 trunk → 公開する環境 branch → 開発のみ環境 branchを切る 右クリックから「TortoiseSVN > Branch/tag...」 To path: branches/[directory] Create copy in the repository from: HEAD revision in the repository にチェックで良いと思います。 これでbranch切れました。 merge branch→trunkにmergeしたいと思います。 （途中のURL変更変えれば、trunk→branchもやり方は同じ） 「TortoiseSVN > Switch...」でtrunkに切り替えておきます。 ※すでに切り替えてあるのであればやらなくてOKです。 右クリックから「Tortoise
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
コンフリクトの解決を記録して再適用する git rerere - Qiita
はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所
第1回 シンプル・軽量な構成管理ツールItamae | gihyo.jp
はじめに はじめまして。クックパッド株式会社の荒井（@ryot_a_rai）と申します。 今回から全5回、構成管理ツールであるItamaeの入門から実際の活用例までを解説していきます。今まで構成管理ツールを使ったことがなかった方から、Itamaeをすでに使っている方まで、ぜひご覧ください。 Itamaeとは Itamaeは筆者が中心となって開発を進めているオープンソースの構成管理ツールです。同様のツールとしてはPuppet、Chef、Ansibleなどが有名ですが、ItamaeはChefに影響を受けています。Chefの記述性・柔軟性を持ちながら、シンプルで導入しやすい構成管理ツールを目指して開発が進んでいます。 構成管理ツールの必要性 Itamaeの解説を始める前に、構成管理ツールを使う理由について軽く考えてみたいと思います。 サーバ構築の自動化 手動構築の手間と時間を減らす 手動構築によ
知って「おっ！」てなったGitHubの知識7選 - Qiita
GitHubダイスキー！ ということで、知った時に「おっ！」と感じたGitHubに関する事項を選出してみました。 あなたに「おっ！」と思ってもらえたら幸せです。 １．入れておくと、意味を持つファイル名がある。 README.md README.mdは有名ですよね。リポジトリのトップにREADME.mdという名称でマークダウンを入れておくと、GitHubで解釈されて表示されます。 それ以外にも、あるのです。意味のあるファイル。 ISSUE_TEMPLATE.md トップか、.github/というフォルダにISSUE_TEMPLATE.mdという名のファイルを入れると、GitHubでIssueを作った時にこのファイルの内容が入ります。書くべき項目を羅列しておくとルール化できていいですよね。 それ以外にも PULL_REQUEST_TEMPLATE.md を入れておくと、Pull request
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
現場がSubversionでつらい貴方へ…自分だけこっそりGitで開発する方法 - interprism's blog
この投稿は インタープリズム的「俺達私達の進捗を上げる25個前後のTips」 Advent Calendar 2015 - Qiitaの1日目 の記事です。 こんにちは、Imamotoです。 仕事に役立つTipsの紹介ということで、今日は最近自分の開発を快適にしてくれた豆知識として、現場はSubversionだけど自分だけこっそりGitで開発しちゃう方法を紹介します。 Subversionでのバージョン管理、捗ってますか？ 唐突ですが皆さん、現場でバージョン管理は捗っていますか？ バージョン管理システムはGitですか？それともSubversion(svn)でしょうか。 もしSubversionであり、尚且つSubversionであることに多少なりとも不満を感じているのであれば、 この記事はお役に立てるかもしれませんので気が向いたらご覧になってください。 Subversionのつらみ… 私は
git-svn の使い方メモ
git-svn.markdown git-svn の使い方メモ git-svn の使い方をメモする。他によいプラクティスがあれば指摘していただけるとありがたい。 用語 SVN のブランチと git のブランチが混在しているため、ここではブランチという語を以下のように区別する。 ブランチ、 SVN ブランチ：$SVN_REPO/branches 以下にあるディレクトリ ローカルブランチ：git のローカルブランチ リモートブランチ：git のリモートブランチ 例題の SVN リポジトリの構成 このメモでは SVN リポジトリが以下のような構造になっているとする。 $SVN_REPO/ foo/ bar/ branches/ foo-x/ foo-y/ bar-new-feature/ このリポジトリは標準レイアウトではない（trunk/ や tags/ がない）。トップレベルのディレクトリが
10分ではじめるGitBucket - Qiita
GitBucketとは GitBucketはたけぞうさんという方が開発されているGitHubのクローンアプリです。 Scalaで書かれており、驚くほど簡単に導入することができるのが特徴です。 OSSのGitHubクローンといえばGitLabがメジャーですが構築の手順が複雑かつ面倒なため、 使い始める前に構築段階で挫折した経験のある人も多いのではないでしょうか。 対するGitBucketはwarファイルを実行するだけという手軽さです、素敵!! より詳しいレビューはこのあたりを参照してください。 背景 とあるクラウド環境にGitBucketを導入する機会があり、 せっかくなので vagrant + ansible で導入を自動化するplaybookを書いてみました。 以下のクラウドプラットフォームで導入検証をしました。 AWS DigitalOcean したごしらえ Case: AWS vag
t32k、怒られる！セマンティック バージョニングしてますか？
どうも、バンクーバーでぶらぶらしている@t32kです。最近は暇なのでもっぱらOSS活動に勤しんでおります。そんなわけで日々のアプリケーション開発において重要になってくるのがバージョニングです。 今日はセマンティック バージョニングについて解説します。自身が公開しているライブラリやパッケージのコードを何かしら修正したら、それに伴いバージョンを上げるのが一般的だと思うのですが、実はどのようにバージョンを上げるのが適切なのか、昔の私は理解していませんでした。 『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』などと、なんとなくにバージョニングをしていました。 If the plugin’s API changes dramatically (for example, when sortOrder option is renamed
SourceTreeでいろいろ取り消してみる - yk5656 diary (旧)
SourceTreeでいろいろ取り消してみる 修正を破棄する（git checkout） 何かファイルを修正して、作業ツリーに修正ファイルが表示された状態。 この修正を破棄する場合は、破棄したいファイルで 右クリック（または[操作]メニュー）から[リセット...]を選ぶ。 [OK]ボタンを押すと修正が破棄される。 [リポジトリ]メニューの[リセット...]からも破棄することが可能。 ステージしたファイルの取り消し（git reset） Indexにファイルをステージした状態。 チェックボックスを外せば、ステージを取り消せる。 前回のコミットの修正（git commit --amend） コミットメッセージの修正 ファイルを修正してコミットした状態。 プッシュはしていない。 コミットメッセージを修正する場合は、 [コミット]をクリックして、下記の画面を表示する。 [オプションのコミット]で[
git でコミットした内容をなかったことにしたい（打ち消したい）時
コミットを打ち消したい時に使う reset と revert について。あとオマケでコミット前のものを打ち消す Discard についても。それぞれ SourceTree でどうやるのかも含めてメモ。 コミット済みだけれど push はしてない場合 コミット済み push 前なら「git reset」。 例）誤ってコミットしてしまったとか、いくつか試しにコミットしたけどこのコミット要らないなーとなった場合。 例）マージしないでいいブランチを誤ってマージしてしまった場合。 上記それぞれ細かくコマンドなど見たい場合、git reset についてもまとめてみる – murankの日記 が詳しかったです。 SourceTree で git reset 戻りたいコミットを選択して右クリックから「現在のブランチをこのコミットまでリセット」。push してない範囲だけが取り消せるという認識で戻りたいコミ
Jenkins Git publisherでデイリーリリースをタグ付けする - Qiita
どの変更分までをリリースしたりテストしたりしたかを確認する必要がでてきたため、 デイリーのリリース結果としてリリース用ブランチのタグ打ちを自動化した履歴 用意されてるものだけだと普通に出来るが、 ちょっと名前など工夫入れようとしたらハマったためメモ 前提 内部で利用しているGitLabからソースを取得している 通信の制約上Webhookでいい感じに使えない Pollingで頑張るしかない... Plugin Git plugin リポジトリでGitを使っているため利用 タグ打ちする時にも使ってる Environment Injector Plugin Git Publisherに渡すタグ名の環境変数を入れるために利用 やったこと 上記Pluginを入れておく Gitリポジトリから取得できるよういい感じになにがしかする RepositoryとCredentialsは通常通り設定 Advanc
すぐ忘れる！SourceTreeを使ったリベースとスカッシュの手順 - Qiita
Git操作をGUIで行えるSourceTreeは、私にとって今では無くてはならない存在です。 コレのお陰で、ターミナル恐怖症のデザイナーさんにもGitでファイルの変更を管理してもらえるようになって、デザイナーさんとの連携がとても楽になりました。 もう、これなしでは開発したくないと思えるほど便利です。 でもSourceTreeのいくつかの機能はお世辞にも直感的とは言えず、間違った操作を誘発する危険性をはらんでいます。私もハマって結構大変な目に会いました。 私が、そして私のような方が同じ過ちをおかさないように、ここにハマりそうなSourceTree操作を記録しておきます。 リベース手順 例えば、developブランチから分岐したfeature/hogeブランチで作業している途中で、他の開発者のコミットがdevelopブランチにマージされた場合、後々大きなコンフリクトが発生するのが怖いので、早め
Gitのブランチ戦略まとめ - _log
今更話題として盛り上がることは少ない気がするが、自分の中で曖昧になっているので有名そうなものをまとめてみた。 数年前のエントリになるけど、雛形として有名なものだとこの辺りだと思われる 1. A successful Git branching model (git-flow) A successful Git branching model を翻訳しました リリースを中心に考えられており、以下の5つのブランチを使用する メインブランチ master : 常にリリース可能な状態。 develop : 次のリリースのための最新の開発作業の変更を常に反映する。 サポートブランチ Feature branches : 新機能開発用。developから分岐して、developにマージ。(–no-ff フラグ付けて、Fast-forwardしないようにする) Release branches : リリ
Microsoft、業務PC自動セットアップツール「Windows AutoPilot」を提供
Microsoftは2017年6月29日（米国時間）、Windows 10の次期大型アップデート「Windows 10 Fall Creators Update」に向け、自社環境に適したPCのセットアップを自動化する「Windows AutoPilot」などの業務クライアント管理者向け新機能を提供すると告知した。 Windows AutoPilotは複数の管理機能を含めたスイートツールとして展開されるが、中でも目玉は「Windows AutoPilot Deployment」だという。Windows AutoPilot Deploymentは、IT部門が自社環境や組織の業務内容に応じてカスタマイズしたクライアント初期設定を読み出し、ユーザーがセルフビルドできるようにするクラウド型サービス。IT部門は、新たに導入するクライアントの配布準備業務を簡略化できる。 Windows AutoPilo
PowerShell Desired State Configuration（DSC）とは（前編）
PowerShell Desired State Configuration（DSC）とは（前編）：PowerShell DSCで始めるWindowsインフラストラクチャ自動化の基本（1/2 ページ） Windows OSの設定や構成を変更する場合、GUIの管理ツールを使うのが一般的である。だが台数が多かったり、構成変更や以前の構成への復旧などが頻繁だったりするとGUIでは非常に面倒だし、間違いもしやすくなる。こんな場合はPowerShell DSCを使ってインフラ構築作業を自動化するとよい。 連載目次 標準でGUI管理ツールを備えているWindows Serverでは、さまざまな設定・構築作業をGUIを通して手軽に実行できる。その半面、手動作業が必要なため、設定・構築に時間がかかったり設定を元に戻すのに手間が掛かったり、さらには複数のサーバーを同一の構成にそろえるのに苦労したりしがちだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitのブランチ戦略
Google、「Cloud Source Repositories」正式公開。Gitベースのソースコード管理ツール、5ユーザー、50GBまで無料
今からでもtig入門 - Qiita
