English Português (Brasil) 简体中文
よく使う Git コマンド自分用メモです。 これらのコマンドの組み合わせでなんとか開発はできています。新しいコマンドを覚えたら随時追記。 目次 基本操作 ブランチ操作 tag 操作 stash 操作 変更をやり直す rebase -i diff log リモートブランチを全削除するワンライナー リモートブランチを全部チェックアウトするワンライナー 基本操作 git init Git 管理を開始する。カレントディレクトリに .git が作成される。 git add hoge.txt 対象をステージングエリアに追加。 git status ワークツリーとステージングエリアの状況を表示 git commit -m 'commit message' ステージングエリアの情報をリポジトリに反映。 git rm hoge.txt 対象をワークツリーとステージングエリアから削除。 git mv hoge
Joelさんがsubversionを使うのはやめろ!と書いているのを見て、マジかよ!と思ったわけですが、gitの本を2冊買いながら全く手を出していなかった自分にはよい刺激になったんで、会社の開発サーバ(CentOS 5.4)にgitを入れてみた。joelさんはMercurial使ってるみたいだけどね…。 クライアントは、Mac miniです。 サーバの方は、例によってyumで。 yum -y install git git用の適当なディレクトリを作り、公開リポジトリを作成する。 mkdir -p /var/git/hoge.git cd /var/git/hoge.git git init --bare WebDavで公開するということなので、subversion用のconfをコピーして修正してみる。 cd /etc/httpd/conf.d cp subversion.conf git.
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
しばらくQiitaの方で技術メモを登録していくようにしてみます action script action script3でhello world action script3でクロスドメインの画像読み込みを試してみる apache Apacheでand条件でアクセス制限を試してみた Apacheで他のサイトを自分のサイトのように表示してみる Apacheでクライアント認証してみる Apacheのクライアント認証をIPアドレスによっては不要にしてみる git-flow git flowをgitプロトコルが許可されていないproxy越しにhomebrewで導入する jenkins jenkinsプラグイン Jenkins Tips opencv opencvとc++で画素ごとのアクセスをやってみる squid Amazon Linuxのsquidで帯域制御したフォワードプロキシをたててみる s
Gitを使い始めて1年以上たちます。最近、Gitを使ったプロジェクト運用方法が自分なりに固まってきたので公開します。かなりシンプルなので、ある程度Gitに慣れていれば十分に運用可能だと思います。 僕たちが理想とするヒストリーGitを使った開発の成果物、それは開発のヒストリー(履歴)そのものです。このヒストリーが論理的に正しく、かつ、簡潔で理解しやすいものを目指すというのが大方針となります。その方針のなか、現時点で僕たちが理想だと考えているのが、以下の図のような履歴がリモートブランチに残ることです。このヒストリーには2タイプのブランチが存在します。 リリースブランチ … 次期リリースバージョンに向けて進んで行くブランチ。チケット1枚について1つのコミットが良い。 フィーチャーブランチ … チケット1枚について1つ切られるブランチ。機能を実装する際に小刻みにコミットしたログが残っているため、後
最近の更新 (Recent Changes)2016-04-25FrontPage 2014-04-08機能一覧 今後対応を予定している機能 2013-02-16新規メンバーのミッション 2012-12-22リリース手順 2012-11-25議事録一覧 最新リリース情報setucocms (1.6.1)2013-03-24 21:20 Wikiガイド(Guide)Wikiの文法 リンクの種類と文法 ブロックプロセッサ 拡張文法 サイドバー プロジェクトWikiでの広告設定 サイドバー (Side Bar)このサイドバーについて このサイドバーの編集 Gitリポジトリ運用ルールOutlineバージョン番号の構成 githubのリモートリポジトリのブランチ 各自のローカルリポジトリのブランチ 開発の流れ シナリオ1 次リリースに向けた変更(過去のリリースへのフィードバックが必要ない場合) シナ
Using Git To use Git on the command line, you will need to download, install, and configure Git on your computer. You can also install GitHub CLI to use GitHub from the command line. For more information, see "About GitHub CLI." If you want to work with Git locally, but do not want to use the command line, you can download and install the GitHub Desktop client. For more information, see "About Git
学校や会社などproxyを通してしかインターネットに接続できない環境で、GitHubにpushする最善の方法を模索して満足できる方法が見つかったのでメモします。Windowsの環境にだけしぼった方法ですがBK山盛りです。 問題・課題 そもそもリモートのgit操作ができるかどうか http経由だと認証関係で色々と面倒くさかったり・生認証データの問題がある gitはhttpプロトコル経由よりgit(SSH)プロトコルの方が色々と便利(らしい) 普段の操作でプロキシの有無を意識したくない プロキシ環境(http通信限定)でのgit操作 「httpでgitのremoteリポジトリと通信できるか?」は、gitの仕様では可能です。 但しリモートの環境でhttpが使えるようにセットアップしてある必要があります。 githubは使える事が確認済み。 認証方法 http通信だと認証方式がBasic認証になり
■インストール EclipseからGitを使うにはEGitというプラグインを使う。 インストールは公式サイトのここにあるように、Eclipseの通常のプラグインインストールと同じように、Help -> Install New Softwareを選択し、Add Siteで http://download.eclipse.org/egit/updates を追加して・・・って感じ。 使用方法はこれが詳しい(英語)。 ■sshの設定 Pageantが立ち上がってればそっちで認証してくれるようにして欲しかったんだけど、そのやり方がよく分からなかったので、Puttyの鍵(*.ppk)をPuTTYgenに読み込ませた後にOpenSSH形式でエクスポートして、それを使うようにEclipseで指定する。 Window -> Preferencesで設定画面を開き、General -> Network Co
LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 LinuxカーネルやRuby on Rails、Perlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。本記事では、Gitを使いこなすために覚えるべき20個のGit基本コマンドを紹介する。 なお、Gitの基本的な考え方や使い方については分散バージョン管理システムGit入門でも紹介しているので、そちらも参照してほしい。
最近、ソースコードを管理するバージョン管理システムで人気なのがGitだ。サーバ集中型のSubversionやCVSと違い、クライアントサイドでコミットできる分散型と言う形式がうけている。すでにRailsのソースコードもGitに移行している。 トップページ そんなGitをWebサービスとして提供するのがこれまた人気のGithubだ。そしてこれはそのクローンだ。 今回紹介するオープンソース・ソフトウェアはGitorious、Githubクローンだ。 Gitoriousはユーザ登録すれば誰でもGitリポジトリを追加することができる。そしてコミッターの管理、差分のWeb表示、コメント、プロジェクトの進捗をグラフで見られたりと多彩な機能が揃っている。 プロジェクトページ DiffのWeb表示はDiffファイルの表示またはグラフィカルな新旧横に並べた表示が選べるようになっている。さらにソースツリー、マ
これからGitを始める人が読むべき記事のまとめ 2009-05-13 candycane(RedmineをCakePHPでPHPに移植するプロジェクト)の開発でGitの素晴らしさを痛感したので、これはもう全力でGitを広めるべきだと思いました。そこで、これからGitを始める人が読むべき記事をまとめてみたいと思います。 なお、Gitの発音は「ぎっと」です。 目次 Gitの開発者による45ページの特集記事「WEB+DB PRESS vol.50 はじめてのGit」 WEB+DB PRESS Vol.50 このサイトから -人 が購入しました 全体で -人 がクリック posted with amazlet at 09.05.13 WEB+DB PRESS編集部 技術評論社 売り上げランキング: 380 おすすめ度の平均: 森田創特集(?) perl, PHP, SQL Amazon.co.jp
git-svnを使ったときのコミット手順について自分用にまとめた コミットログに必要な情報を書きたい。 gitの使い方は割愛 git-svnの使い方は以下のまとめを読んだ git-svnの使い方を覚えた – idesaku blog git svnとgitを併用する方法のメモ – Hello, world! – s21g $ git commit -v 修正完了 自分のいるブランチを確認 $ git branch master * test_commit $ git checkout master masterにいることを確認 $ git branch * master test_commit $ git svn rebase (svn update相当) $ git merge –no-ff –no-commit [ブランチ名] マージはされるが commit が作成されないので $ g
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います: ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
GitX GitX is a git GUI made for Mac OS X. It currently features a history viewer much like gitk and a commit GUI like git gui. But then in silky smooth OS X style! Features Detailed history viewer Nice commit GUI, allowing hunk- and line-wise staging Fast workflow Explore tree of any revision Nice Aqua interface Paste commits to gist.github.com QuickLook integration Requirements GitX runs on Mac O
分散SCMを使いたい!と思う今日この頃。 仕事ではSVN(Subversion)を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある?いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ!」とうそぶいてきているわけだが…ハッタリかましてました!本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く