Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに こんにちは、kenです。みなさんコンフリクト解消してますか! チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント(日本語版)には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
gitでコミット(commit)前にterraform fmtやtflintを実行したい時はpre-commit-terraformが便利 「ローカルでもterraform fmtやtflint・tfsecの実行を自動化したい。」 terraformにはコードのフォーマットやテストに便利なcliツールやコマンドが色々あります。 (terraform fmt、terarform validate、tfsec、tflint等) ただ、このコマンドを毎回手動で実行するのは面倒です。 CI/CDツール上で実行するのもいいですが、CIで失敗する前にローカルで気づけたらより良いですよね。 そんな時に便利なpre-commit-terraformを紹介します。 pre-commit-terraformとは pre-commitフレームワークで使用できる Terraform の git hook スクリプ
目的 色々作るにあたって、ソースコードを公開できる場合とできない場合がある。 企業レベルでなら、ちゃんと契約してprivateで作業できるようにしてもいいと思うが、個人レベルでやってる場合には、そうはいかない。 そこで自分でGitサーバを構築することにした。 ここで問題が発生する。それは、そのサーバをどのように調達するかだ。 しかし、今回は作るものがWebサーバということで、元々VPSを借りる予定だったため問題とはならなかった。 その他の対応としては、ローカルLAN内にサーバを立てるなどがあるだろう。 現状予定では使用するのが私一人なので、GUIは作らず、CLIで管理できれば良いとする。 環境 サーバ VPSサーバ CentOS release 6.5 (Final) クライアント Windows 10(Fall Creators Update済み) Subsystem for Linux
この画像は本文とは関係ありません。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 みなさん、git submodule コマンドは好きですか?git submodule は特定の状況下では便利なコマンドです。 社内アンケートでも25%が怖いという結果に しかし、なぜか世間にはgit submodule が怖いという人が相当数いるようです。推測ですが、git submodule は動作モデルや使用手順が誤解されがちなところがあり、それで「怖い」と思われているのないでしょうか。git 本体でも昔そんなことがありましたよね。 この記事では git submodule の誤解を解き、適切な使い方を解説します。また、記事の最後にチートシートをつけます。 git submoduleはトモダチ!怖くないよ! git submodule って何? 誤解1 「プロジェクトが大きくなっ
これによって、次のような問題が発生します。 全員がtrunkに対してコミットするため一人のビルドエラーが全員を巻き込む 1つの機能開発が複数回コミットで完成するため、開発を続ける限り安定版を作ることが難しい 開発中コミットが頻繁に入るため、どこまでレビュー・テストしたか分からなくなる SVNはGitと違ってサーバー上のリポジトリのみなので、コミットによって他のメンバーにも影響が発生します。コミット漏れや、ビルドエラーとなるコミットが行われると、チーム全員がその影響を受けることになります。 コミットミスでエラーとなる図 また、複数機能や障害対応のコミットが入り乱れるため、「いつになれば安定版となるのか」「いったいどこまでレビューしたのか」などの管理が大変です。 実際問題、レビュー依頼されたけど忙しくてレビューできずに、バージョンブランチに移ってしまったみたいな事も発生していました。 ノーレビ
半年ほど前のことでうろ覚えなのですが、pixivで複数のリポジトリを統合したときの方法を紹介します。 AAAAAリポジトリとBBBBBリポジトリを統合し、ZZZZZという大きなリポジトリを作成します。もちろんコミットログを統合前まで遡れるようにするのが絶対条件です。 最終形↓ ZZZZZ .git AAAAA BBBBB filter-branch まず、新しくgit clone AAAAAしてきます。(なぜなら、このディレクトリはこの後使い捨てられるので、pushされてないbranchとがあると困るからです) 次にcd AAAAAして、次のコマンドを実行します。 git filter-branch --index-filter \ 'git ls-files -s | sed "s@\t\"*@&AAAAA/@" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new
はじめに Gitのブランチを活用できていますか? Gitが人気を博している理由のひとつには、手軽に使えるブランチの存在があります。ブランチを効果的に使えなければ、Gitの真価を発揮することはできません。しかし複数人での開発で、特になんの決まりもなくブランチを使っていると、無秩序にブランチの作成やマージが行われ、リポジトリが混沌としてきます。 こうした問題を解決するために、「ブランチモデル」というブランチ管理方法が考案されました。 今回紹介するのは、Gitのブランチモデルのひとつである「git-flow」です。 ブランチモデルの中では比較的歴史が長く、git-flowをサポートしているツールも数多くあります。やや複雑なモデルではありますが、ツールを使うことでブランチの操作をある程度自動的に行うことが可能です。コマンドを覚えて流れをつかんでしまえば、それほど難しいことではありません。実際にやっ
gitインストール # sudo apt-get install git リポジトリ作成 # mkdir -p /var/git/repository/test.git # cd /var/git/repository/test.git # git --bare init --shared=group コミット # mkdir ~/test # cd ~/test # git init # echo "Hello git project" > README # git add . # git commit -m "test" # git push /var/git/repository/test.git master nginx fcgiwrapインストール # sudo apt-get install nginx fcgiwrap Nginx設定 location /repository
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
プログラミング 3039 view [git][gitweb][nginx]Ubuntu12.04LTSサーバにgitリポジトリ作って gitweb を入れる やりたいこと Ubuntu 12.04 LTS上にGitの共用リポジトリを作成して、 gitwebをWebUIとして入れて複数人でプライベートで共同開発したい。 Gitのリモートリポジトリの作成 Gitのインストール Gitのインストールは単純に [ubuntu@remote] $sudo apt-get install git でOK! リモートリポジトリ作成 まずgitユーザーを作成してグループの設定をする。 [ubuntu@remote] $sudo adduser git $sudo usermod -a -G git zuqqhi2 $sudo usermod -a -G git test $sudo su - git [
nginxでgitリポジトリを公開してみます。 Smart HTTPというのが使えるようですが、こちらの例ではApache HTTP Serverでしたが、 特別なことは必要なさそうなので、nginxで試してみます。 80番ポートで通信できるとか、認証方法によっては鍵が必要なかったりといろいろ使い道がありそうですね。 こちらを参考にしました。 Smart HTTP Transport git-http-backend(1) Manual Page fcgiwrap nginx 1.2.1を使用しますが、インストール手順は省略します。 上記の記事によるとgit-http-backendを動かす必要があるので、fcgiwrapを使ってみます。 fcgiwrapインストール fcgiwrapインストール yum -y install fcgi-devel.x86_64 cd /usr/loca/
tester@b4b4r07:~/git_test$ ls abc def tester@b4b4r07:~/git_test$ git init Initialized empty Git repository in /Users/tester/git_test/.git/ tester@b4b4r07:~/git_test (master #%)$ git add . tester@b4b4r07:~/git_test (master #)$ git commit -m 'first commit' [master (root-commit) 42698c8] first commit 2 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 abc create mode 100644 def tester
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 (これ以降の記事中のリモートは全てoriginとします。) このコロンは何?? リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか? 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く