hitoyam.comhitoyam.com 2023 著作権. 不許複製 プライバシーポリシー
Git SubmoduleのトラブルをGit Subtreeで解決できると知っていますか？
ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われているgit submoduleを使わないほうが良いという論争が起こっています。それを受けてgit subtreeを使うべきであるというエントリがAtlassianのNicola Paolucci氏がブログに投稿しています。彼はまずgit submoduleを使うべきではないという話題が盛り上がっているという事で3つの記事を参照したあとに、git subtreeを使うべき理由と使用例を挙げています。それによるとgit subtreeを使うべき理由は以下のとおり。 ワークフローがシンプルなので管理が簡単。 古いバージョンのgitもサポートしている。(v1.5.2ですら。) サブプロジェクトのコードがcloneした直後に利用できる。 subtreeはユーザに新しい学習を要求しない。
愛知県の社会福祉法人 清凉会は、老人ホーム・デイサービス・特別養護老人ホーム・保育園などを運営しております。
ABOUT SEIRYOU GROUP 清凉グループについて 清凉グループでは、「あふれる笑顔～慈悲の心で～」を経営理念として掲げ、 地域における介護・保育ニーズにお応えすべく、複数の施設を運営しております。 今後も地域の皆様の生活に寄り添う場所として、個々の施設と連携し、よりよいサービスを追求していく所存です。 清凉グループからのお知らせinformation
git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
gitでサブモジュールを削除する | Webシステム開発／教育ソリューションのタイムインターメディア
問題 git submodule で他のリポジトリ(以下「サブモジュール」)の内容を埋め込むことが簡単にできるのですが、 ごく稀に追加したサブモジュールを削除したくなる場合があります。 サブモジュールの追加や更新は git submodule add や git submodule update で簡単にできるものの、 何故か git submodule rm サブコマンドはありません。 どうすれば削除できるのでしょうか。 解決方法 submodule_name='The name of a submodule you want to remove.' submodule_path="$(git config --file .gitmodules --get "submodule.$submodule_name.path")" git rm --cached "$submodule_pat
小規模チームでのGithub利用開発 - Mandy Code
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
共同創業者に聞いた、GitHubは何が違ったのか？
プロジェクトホスティングサービスで高い成長率で注目を集める「GitHub」（ギットハブ）。2008年4月の一般公開から5年足らずで利用者数が300万人を突破（2013年1月中旬）した。これはソフトウェア開発者向けサービスというニッチ市場では破竹の勢いといっていい。2012年7月には有力ベンチャーキャピタリスト、アンドリーセン・ホロウィッツを中心に1億ドル（約91億円）という大きな投資を受けて注目を集めた。 GitHubがローンチした時点で、すでに同類のサービスは多くあったが、過去5年を見れば、一人勝ちといっていい勢いだ。この強さの秘密は何なのか？ 来日中のGitHub共同創業者らに話を聞いた。 Googleトレンドを使って、「github」「gitorious」「bitbucket」「sourceforge」「codeplex」を検索ボリュームの推移を比較した。青線のGitHubが類似サー
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
gitのpost-updateフックでブランチ名を取得する
gitでフックする時のお話。 gitの運用で、こんな感じでやる場合があります。 自分の作業用ブランチで開発作業 開発が終わったらリモート(中央リポジトリ)にプッシュ プッシュされたプログラムをデプロイ 2と3の間を自動化するために、post-updateフックなんかを使ったりするのですが、このシェルスクリプトの中でプッシュされたブランチ名を判断して処理したいことがありました。 たとえば、リリース用ブランチ、ステージング用ブランチ、開発用ブランチの3種類のブランチがリモートにあるとして、リリース用とステージング用は、確認してから手動デプロイしたいけど、開発用ブランチだけはプッシュされた後にすぐにプログラムをデプロイしたい、という場合なんか。 で、本題ですが、post-updateフックのシェルスクリプトには、第一引数に完全なブランチ名が渡ってくるようです。 たとえば git push ori
フック（hook）を使ってコミットしたら自動的にデプロイするようにする - ちなみに
Gitさんはいくつかのタイミングで好きな処理をフックできる賢い子です。 $GIT_DIR/hooks配下にタイミングごとのスクリプトが用意されていて、それを書き換えることで任意の処理を行わせることが出来ます. タイミングなどの詳しい説明はman githooksに書かれています。（最初にこれを見ていれば僕の数時間は失われなかったのに） 今回やりたかったのは、ローカルでWebサイトをこねくりまわして、気に入ったらコミットしてリモートにpush、そうすると自動的に公開用のディレクトリでpullするというものです。 やったことは、リモート側で $ cat path/to/repos/hooks/post-receive #!/bin/sh (cd /path/to/site/directory; git --git-dir=.git pull) $ chmod +x path/to/repos/
GitとSubversionを共存させる » tune web
git svn cloneして、ファイル編集して、git commitして、git svn dcommitでSubversionサーバに変更を反映させる。Subversionの変更を取ってくるのはgit svn rebaseだ… なんてのがWeb上で探してすぐ見つかる情報ですが、これでは複数人でgitを使う場合の運用ですぐに行き詰まってしまいます。 実用Gitの16章に定石が載っていると聞き、さっそく買って読んでみました。他の章を飛ばして16章だけ読んだせいもあるのか自分の中ではまだうまく消化出来ていません。とりあえず手順だけ書いておきます。 ◯前提条件 git svnを行う窓口は1箇所にする。git svnのオプションを変えたり、とってくるリビジョンを変えただけでもコミットオブジェクトは変わってしまう。 ◯前準備 git svnを使ってSubversionリポジトリのcloneを作る
Git Cheat Sheets JP
設定 基本 ブランチ リモート・リポジトリ git-stash git-svn 参考 修正履歴 設定 Git には様々なオプション設定がある。中には挙動を大きく変えるものもあるので注意が必要である。 設定をすべて表示する $ git config --list システム (/etc/gitconfig) の設定 $ git config --system --list や、ユーザーごと (~/.gitconfig) の設定 $ git config --global --list など表示する対象を絞ることもできる。 ユーザ名とメール・アドレスを設定する $ git config --global user.name "John Doe" $ git config --global user.email "john.doe@example.com" コミットする時に記録されるユーザー名とメ
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
Git hooks まとめ - Qiita
他のバージョン管理システムと同様 git にも hook が色々存在しますが、役割を適用順に一覧にしたサイトが見当たらなかったので自分用にここに書いておこうと思います。 細かいことはは公式ドキュメントを見てください。 また各々の hook script の書き方自体は、手元の環境の .git/hooks/*.sample を参考にしてください。 commit関係 見ての通り、コマンドを実行してからの流れ順に書きます。 git commit pre-commit commit前に起動しコードをチェックするなどで使う。 0以外を返すとcommit中止。--no-verifyで無視。 prepare-commit-msg commit時のデフォルトメッセージ編集用。 エディタが起動し commit msg の入力 commit-msg commit msg が既定のフォーマットに沿っているかなど
git-svn を使って、Subversion のリポジトリと連携 - yun_kichiの日記
ちょっと前に エレコマ という EC サイト構築パッケージを利用して、ショッピングサイトを作ることになったのですが、エレコマのリポジトリが Subversion でした。 私のいるプロジェクトで使おうと決めたバージョン管理システムは Git だったので、Subversion リポジトリと連携できる git-svn というコマンドを使ってソースを取得することにしました。 下記の環境で行います。 共有リポジトリ（bare なリポジトリ）と、最新ソース取得用リポジトリ hoge というサーバを使用 OS は CentOS 5.4 git のバージョンは1.6.5.7 ローカルリポジトリ OS は WindowsXP（クライアントPC） git は msysGit で、バージョンは 1.6.5.1.1367.gcd48 共有リポジトリの作成と、sourceforge から エレコマのソースを取得
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git add -A is not adding all modified files in directories
layer8.sh
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
layer8.sh