ルーターのコンフィグを git にぶち込んで世代管理してみたはなし - miyalog
この記事を三行で みんな好き勝手な名前でコンフィグファイルをアップロードしてサーバーがパンク＆どれが最新版かわからない状況に 命名規則を作り、サーバーに置いておくコンフィグを最新世代１つのみとした さらにファイルを社内 GitLab に自動アップロードし履歴確認ができるようにした ※ GitLab を入れ物として使うだけで、git を使ったワークフローを導入したとかのカッコイイ話じゃありません あらまし とある通信会社の委託でIPネットワークの監視作業員をやっています（非エンジニア）。うちの会社ではルーター・スイッチ類のコンフィグをTFTPサーバーへアップロードしてバックアップとしていますが、先日そのサーバーで反応が5分くらい返ってこなかったり、ファイルのアップロードに失敗したりと動作が不安定に･･･。HDDでも壊れたかな？と思いながら調べてみると... $ df -h Filesyste
CentOS7にgitをソースからインストール
yumでインストールしたgit CentOS7にyumでgitをインストールしたのですが、バージョンが1.8.3.1と最新ではないので、ソースから最新版をインストールすることにしました。 yumでインストールしたgitのバージョン 「git --version」コマンドでインストールされているgitのバージョンが確認できます。 # git --version git version 1.8.3.1 ソースからのgitインストール インストール手順は公式サイトの手順を参考にしています。 事前準備 gitインストールに必要なパッケージ gitをインストールするために必要なパッケージをインストールします。 curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker <--github
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
git logにブランチ名を表示する git log --oneline --graph --decorate=fullのススメ - Qiita
* commit 1235f58b72bd3323375debbc783a508d8328277cce5 | Author: Masaru Furuya | Date: Fri May 16 00:54:09 2014 +0900 | | git test * commit 2rr29dd167c5d38fec823f2c90fb4896536a6214 | Author: Masaru Furuya | Date: Thu May 15 19:22:14 2014 +0900 | | | * commit 9003273439ba845614650688d7bb752614ec6231 |\ Merge: 90b2dd4 4034903 | | Author: Masaru Furuya | | Date: Thu May 15 18:32:17 2014 +0900 | | | | M
gitのorphanブランチを理解する - ::Eldesh a b = LEFT a | RIGHT b
Github Pagesに使えそうなのでmanの該当箇所を訳してみました*1。=>原文 orphanブランチというのは、元のブランチからの歴史を受け継がず、gitリポジトリ内で新しく0から歴史を持つブランチです。新しくルートになり、親コミットを持ちません。 リポジトリの中から特定のファイルのみを公開したい場合などに使えそうです。 # 日本語として自然になるように努力はしてませんが、間違いは指摘していただければ直します Synopsis git checkout [-q] [-f] [-m] [[-b|-B|--orphan] ] [] Description Create a new orphan branch, named , started from and switch to it. The first commit made on this new branch will have
Duplicating a repository - GitHub Docs
Note: If you have a project hosted on another Git-based hosting service, you can automatically import your project to GitHub using the GitHub Importer tool. For more information, see "About GitHub Importer." Before you can push the original repository to your new copy, or mirror, of the repository, you must create the new repository on GitHub.com. In these examples, exampleuser/new-repository or e
tigでgitをもっと便利に！ addやcommitも - Qiita
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
git revert で複数コミットを打ち消す - miauのブログ
git にはコミットした内容を取り消す方法がいくつかありますが、いったんリリースしたコンテンツの公開期間が終了してその内容を取り下げたいような場合は、git revert でリリース時のコミットを打ち消すコミットを作るのがお作法です。 今回まさにそういう状況になったんですが、リリース時のコミットが複数回にまたがっており、それも 先のエントリ で書いたように他の対応と入り交じってコミットされてしまっています。 こういう場合にどう revert すればいいかという話です。 revert の基本的なところ 例えば 3a0e871f というコミットを打ち消したい場合は、 git revert 3a0e871fを実行すれば、 Revert "xxx 対応" This reverts commit 3a0e871ff60411ca89fa07c7f2b4d426fa04285d.のようなメッセージがみ
Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita
あらまし 大きな作業をする場合、こまめにローカルレポジトリのブランチにコミットして、何かあったときにすぐに戻せるようにしたくなります。 また、パフォーマンス改善など、実験や研究の色合いの強い作業は、試行錯誤しながらブランチに"とりあえず"保存しつつ、「あっちのほうが良かったかな〜」と思ったときに取り出せるようにしておきたくなるものです。 また、ローカルレポジトリだけでなく、リモートレポジトリに置いたほうがチームみんなで共有できたりしていろいろ便利です。 ですが、最終成果物はなるべく少ないコミットにしないと、マージが大変です。 メインブランチにこんなコミットが入るとゲンナリしますよね？ $ git log --oneline bcdef12 Revert foo abcdef0 Add foo cdef123 Refactor bar again def1234 Refactor bar e
チームが Git を使っていなくても Git を使う: git-svn をうまく使うコツ | Atlassian Japan 公式ブログ | アトラシアン株式会社
私はアトラシアンに入社する前、バージョン管理システムとして Subversion (SVN) を使用している多様なプロジェクトに携わってきました。私はすでに Git へ移行して数年経っていたので、可能な限り Git を利用したいと思いました。 そして幸運にも、git-svn を使うことができました。Git-svn は、パワフルな Git ツールセットの快適な使用感を手放すことなく、Subversion リポジトリとやり取りができるすばらしい完全なソリューションです。そして、それには知っておくと便利な点がいくつかあります。この投稿では、すでに git-svn の知識が少しあり、git-svn を使用して SVN とやり取りする方法を知っている人を対象に話を進めていきます。 ここでは、SVN と連動して Git を快適に使用し続けるために、私が自ら調べて学んできたワークフローに統合する必要のあ
First commit が git rebase -i できない問題 → git rebase -i --root でできる - 納豆には卵を入れる派です。
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・？— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
綺麗なpull requestを送るための3つのポイント - Qiita
これはGit Advent Calendar / Jun.20日目の記事です。前回は、fukajunさんの変更を一時的に退避！キメろgit stashでした。 この記事ではgithubでpull requestを送る時に私が気をつけていることを共有したいと思います。 私が気をつけていることは次の3つです。 masterにコミットしない 簡潔なコミットメッセージを書く コミットを1つにまとめる この話の前提 以降では、次の2つのリモートリポジトリが登録されている前提で説明します。 upstream: fork元のリポジトリ origin: upstreamからforkされた自分のリポジトリ masterにコミットしない 修正作業は必ず新しいブランチを作ってから行ない、masterブランチはあくまでupstreamの更新を取り込むためだけに使って下さい。 このルールを守らないでpull req
美しき git log –graph のエイリアス
git log --graph --pretty=oneline でもいいんだけど、情報として物足りない。 エイリアスの設定によりこんな感じに美しくすることが可能です。 .gitconfigのエイリアスは下記のように設定します。 [alias] lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative lga = log --graph --all --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-com
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
続・Gitリポジトリ運用の最適解 - chulip.org
このエントリは過去に書いたエントリの続編として位置づけています。 過去の記事：Gitリポジトリ運用の最適解 - chulip.org この記事を書いた当時、いや少なくとも少し前までは本気でマージコミットがないGit運用が最高だと考えていました。 だからこそ、何故A successful Git branching modelがNon-Fast-Forwordマージを推奨しているか疑問であり、昨今のgit-mergeには--no--ffオプションを設定。むしろgit-configでデフォルトの挙動を--no-ffにできるから設定しとけお前らという話に対してよく理解ができていませんでした。 マージコミットがないGit運用が最高だというのは限られた場合の話ではないか ある特定の場合においてのみこの話は適応されるのではないかということに気づきはじめたような気がします。 これは例えばリリース前の開発
Gitのブランチで効率的に開発・運用・保守・管理する方法 - (DxD)∞
はじめに 最初に、Gitに関するリソースとして、本では「入門Git」と「実用Git」、Web上では「Pro Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。 特に、他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。 しかし、Gitを利用していくにつれて色々と疑問も出てきます。局所的なワークフローについては、様々なリソースによって理解することができます。では、効率的に開発・運用・保守・管理を行うために、大局的・継続的なワークフローをどのように採ればよいのか、特にGitの柔軟性を活かすにはブランチをどのように使えば
Gitクライアントの「SourceTree for Windows」、日本語化された最新版が無償公開、アトラシアン
Gitクライアントの「SourceTree for Windows」、日本語化された最新版が無償公開、アトラシアン アトラシアンが提供している無償のGitクライアント「SourceTree for Windows」がバージョン1.4となり、無償公開されました。そしてこのバージョンからWindows版も日本語化されたことが、同社エバンジェリスト 長沢智治氏のブログ「Re:WorkStyle」にポストされたエントリ「SourceTree for Windows 1.4 日本語版が公開に」で発表されました。 これまでSoruceTreeのMacOS版は日本語化されていましたが、Windows版は英語版のままでした。同社は「SourceTree for Windows 翻訳にご協力ください！」と昨年から協力を呼びかけており、今回のバージョン1.4からその成果が反映された形です。 SourceTre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ギットクエスト
既に git 管理しているファイルをあえて無視したい - Qiita
bitbucketの使い方
