You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
分散 SCM とはいえ、バックアップはあるとうれしいものです。git のリモートリポジトリが破損した場合などに復元元を探すために、誰が持っているのが最新のリビジョンで、、というような作業が発生することは避けたいからです。 git のリモートリポジトリから別のサーバにバックアップを作成するのは、hooks を利用することで簡単に設定できます。例えば、対象となるリポジトリの post-receive で下記のようなコマンドを設定しておくとできます。 バックアップ先のサーバ:ディレクトリは targethost.example.jp:/var/lib/git バックアップのための SSH 接続で利用するユーザは syncuser gitosis ユーザは syncuser 権限で git コマンドが利用出来るように visudo を設定 #!/bin/sh ##### # hooks/post-
仕事でもgitを使い初めることになったけど、自分も含めてadd忘れ、commit忘れ、merge忘れ、push忘れが発生するだろうなと思っていた。 これらを無くすことは、結構難しい問題ではあるんだけど、自分のローカルのリポジトリの状態を一発で確認できるだけでも、対策になると考えた。 check git status https://github.com/smeghead/check-git-status (最新版はgithubにあります) 今回は、Ubuntu限定でシステムトレイのアイコンをクリックしたら、自分のローカルのgitリポジトリ一覧を表示して、tooltipでgit statusの結果が見れるという簡単なものを、とりあえず目指したので、gtk周りが簡単らしいという噂の、pygtkを使ってみた。 check-git-status.py #!/usr/bin/python impor
どうもこんにちは。フックしてますか。ジャブからローにつなげてますか。 そんなこんなで最近は僕もそこそこ git に慣れてきて助けてもらわなくても良くなって来ました。 しかし人間の欲望はとどまるところをしらず、「なんか定形作業めんどくせーなだるいしなんかうまいことどうにかなれよ面倒くせぇ」とか考え始めるものです。たとえば「テスト通ってないコードコミットするなってリーダーがいうけどいちいち手でテスト走らせて確認すんのだるいからなんかうまいこと自動で動かんかな」とか。 git は大変よくできたツールですので、そういうのもちゃんと用意されています。hooks といって、コミットのタイミングなどで特定のシェルスクリプトなりなんなりを動かすことが出来るよう配慮されているのです。すげーな git 。 しかしこいつがマジめんどくさい。自分でシェルスクリプト書くとか絶対嫌だし、すでにそのへんに転がってるのを
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
■ [git] どの段階で混入したのか全く分からないバグが発生したので、git bisectを使ってみた 気づいたら、BiwaSchemeのmakeが通らない状態になっていた。 java -jar bin/yuicompressor-2.4.2.jar lib/biwascheme.js -o lib/biwascheme-min.js [ERROR] 16082:51:invalid property id [ERROR] 1:0:Compilation produced 1 syntax errors. 数日前までは通っていたんだけど、それから結構な回数コミットを行ったので、どれが原因なのか分からない。 でも大丈夫、こんな時こそ(存在は知っていたけど使う機会のなかった)git bisectを使うチャンスだ。 git bisectは、「OKなコミット」と「NGなコミット」の2点の間を二分
この記事は Git Advent Calendar / Jun. 25日目の記事です! 24日目はrosylillyさんの「複数人での Git 開発に便利な 3 つのコマンド」でした。 gitslaveとは gitslaveはこちらで公開されているツールで、あるgitリポジトリの中にサブディレクトリとして別のgitリポジトリを置いて管理するためのツールです。 似たようなツールとしてgit submodule(sotarokさんの「Git submodule の基礎」がとてもわかりやすい!)があります。 しかし、submoduleで管理しているリポジトリ内も頻繁に更新するような使い方だと、以下のような操作が結構煩雑です。 親リポジトリとsubmoduleで管理している子リポジトリに一緒に変更を加えてcommitやpushをしたい。 親リポジトリと子リポジトリで同じ名前で一緒にブランチを切りた
There comes a time in any coder or non-coder's life when keeping track of file changes in your own head just gets out of hand. When that happens the logical next step is to move your files, whether it be code, configuration files, text files or other; to a version control system. Git is a popular version (or revision) control system which is in wide use today and is built for speed and reliability
前々回のGit解説の続き。 Gitでは色んな作業の仕方があります。 デザイナーとエンジニアの間でよくある作業の流れをイメージ描きつつ説明してみようかと。 今回は「エンジニアとデザイナーが同じブランチで作業する」です。 まず朝出社! 今日は検索ページを作るお仕事をすることになりました。 このイメージにそって説明してみます。 [イメージ内:P-1] エンジニアがみんなの場所(remoteとか呼ばれてるところ)から最新の「master」ブランチを持ってきて… そこから「search」というブランチを作りました。 [イメージ内:P-2] エンジニアは「search」というブランチで、検索フォームのあるページを作成しました。 デザインはまだ入ってません。 [イメージ内:P-3] エンジニアは「git push」というコマンドで みんなの場所remoteに「search」ブランチを置
こんにちは、 rosylilly です。すっかり Advent Calendar のことを忘れていて、大急ぎで記事を書いています。ちゃんと予定は管理しておかないといけませんね…… ということでいつも使っているコマンドの中で 3 つほど紹介されていなかったものがあったので紹介しようと思います。 git grep コマンド 特定の語句が含まれているファイルを検索し、そのファイルでその語句が含まれている行数などを調べるコマンドです。 通常の grep コマンドなどを利用してもいいのですが、コマンドがわかりにくいのと、対象として指定するファイルを指定するのが面倒です。 その点 git grep だと、 git が管理しているファイルだけが検索対象になるので、手軽にリポジトリから検索することが出来ます。 また、オプションを使うことでより柔軟な検索も実現出来ます。一部を紹介しておきますので、man g
Lars Vogel (c) 2009 - 2024 vogella GmbH version 4.4, 20.07.2021
私のまわりには「バージョン管理が未体験」なデザイナーさん多いです。 デザイナーでも、プログラマーと一緒に仕事すると、Gitやsvnを使うことになると思うんですが、Gitとかsvnはまず「その仕組みとかカタチとか」が、デザイナーにとっては分かりにくいと思います。 そんなわけで(元)デザイナーの私が、理解してる範囲のことを分かりやすい言葉で解説してみます。 例の図を描いてみました。 だいたいこんな感じなのですが。。。 解説すると みんなの場所 プログラマーの人がremote(りもーと)とかorigin(おりじん)とか言ってる場所です みんなのファイル共有置き場です branch(ぶらんち)というものがあります。branchはプロジェクトやリリース毎や機能ごとに作られます。 図では「デイリーランキング機能追加用のdaily-rankingというbranch」「検索ページリニューアル用のse
社内のあちこちで git-flow を使っているのを見聞きして、じゃあ僕も、と試そうとしてみたのですが、ググって出てきた情報は、新規にリポジトリをつくるやり方ばかりで、 (新規のリポジトリではなくて)既存のリポジトリにも git-flow って導入できるの? << と疑問に思ってやってみたところ、思いのほか、あっさりとできてしまったのでメモしておきます。 **既存のリポジトリに git-flow を導入してみた そもそも git-flow ってナニ? A successful Git branching model の開発モデル git-flow のインストール 事前に develop ブランチを作成 既存のリポジトリに git-flow を導入 -おまけ - 事前に develop ブランチを作成していなかった場合 << *1. そもそも git-flow ってナニ? git-flow
rebase を使うと、本番用の設定と開発用の設定を簡単に切り替えることができます。 rebase の基本は rebase について - ぐるぐる〜 で説明しているので、ここまでは分かっている前提です。 例えば、ASP.NET で本番用と開発用の web.config が違うとします。 共用のリポジトリには開発用の web.config をコミットしてはいけません。 これをすべて手作業で行おうとすると、ついつい間違って開発用の web.config をコミットしてしまったり、ついつい間違えて開発用の web.config の内容がどこかにいっちゃったりすることがあります。 こういった事故を少なくするために、rebase を使います。 rebase --onto onto オプションを使用することで、ある地点 (ブランチ a とします) から分岐したブランチ (b とします) の分岐点から先
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く