Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 今更ですけどプルリク開発イイですよね。 自分がいるちょっと堅めの組織では、プルリク駆動が浸透するまでに1年半くらいかかりました。ただ、導入後のアンケートでははsvnを使いたいという人が皆無になるくらい、プルリク駆動開発には価値があると現場にわかってもらえましたので、導入時に効果的だった口説き文句をまとめてみました。 えらい人も説得しないといけないし、現場も説得しないといけないので、それぞれに向けたフレーズになっています。 なお中には、gitにもかかわらずtrunkという言葉を使っているケースがあります。これはgitのmasterブ
# スクリプト読み込み source $HOME/.git-completion.bash source $HOME/.git-prompt.sh # プロンプトに各種情報を表示 GIT_PS1_SHOWDIRTYSTATE=1 GIT_PS1_SHOWUPSTREAM=1 GIT_PS1_SHOWUNTRACKEDFILES= GIT_PS1_SHOWSTASHSTATE=1 ############### ターミナルのコマンド受付状態の表示変更 # \u ユーザ名 # \h ホスト名 # \W カレントディレクトリ # \w カレントディレクトリのパス # \n 改行 # \d 日付 # \[ 表示させない文字列の開始 # \] 表示させない文字列の終了 # \$ $ export PS1='\[\033[1;32m\]\u\[\033[00m\]:\[\033[1;34m\]\w\[
7e64dc5 2015-12-09 12:40:08 +0900 update version comment c37b62c 2015-12-09 12:39:18 +0900 add LF if str does not have 57c205a 2015-12-09 07:11:53 +0900 comrelay() takes \r also as new line 7c78970 2015-12-05 09:39:19 +0900 show concrete error message 591b8c3 2015-12-05 09:34:00 +0900 avoid udp send error when the network is not a 290838a 2015-12-03 12:33:31 +0900 add x access mode to Log/ 7981543
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ? Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる(知らない間に容量の大きいファイルがコミットされている可能性がある) 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
巨大な git レポジトリがあった場合に、できる限りそれを fetch することはさけたい。必要な branch だけ、 shallow clone して利用したい。その際に次のようにすればいいだろう、というメモ。 git shallow clone した場合、素直に fetch しても、最初に clone してきたときの branch しか取得できない。 .git/config の [remote "name"] の fetch を複数個化すれば、その分だけ fetch してくれるようになる。 これを変更する正規の手順は、 git remote set-branches. git には、 clone せずとも、 remote の branch をリスト表示する機能がある。
Git, GitHub, GitLabそれぞれの特徴 *注意事項:当初は、GitHub Flowを入れる想定で調べていましたので少しGitHub Flowとの比較の観点が強いです Git Flow 使用するブランチ master マイルストーン用のブランチ develop 開発用のブランチ feature 機能追加用 (hot)fix 不具合修正用 release リリース準備用 Git Flowの良さ fix(不具合)の数が一目瞭然 masterを見ればマイルストーンの遷移が一目瞭然 参考:git-flowとプロジェクトの運営 Git Flowのまずさ ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない hotfixブランチをdevelop, master共に反映しなければならない点が面倒 参考:【翻訳】GitLab f
gitで最低限のデプロイ環境を作る際のメモ。 いろいろなCIツールを使うまでもない、小規模なコンパイルいらずのWebアプリのデプロイ環境を作る。 CIツールを使う場合でも基礎となる知識なので整理しておく。 やりたいこと ローカルで開発。 リモートにpush pushを拾って、公開ディレクトリにpull イメージ 図で書くとこんな感じ。 今回は、独自のリモートリポジトリを使うが、ここがGitHubとかでもいい。 前提条件 ローカル、リモートにgitがインストールされていること(Mac想定) リモート(サーバ)にはsshで透過ログインできること 手順 まずは、push,pullの流れを手動でやってみる。 リモートリポジトリの用意(リモート) とりあえず、外からは非公開かつ、チームがアクセスできるディレクトリを用意し、リモートリポジトリにする。
インストール方法から参考リンクまで。 自分の勉強ついでに、Tigについて基本の すべてをまとめてみました。 合わせて読みたい 【おすすめ】MacのFinderをカスタマイズする魔法のコマンドたち 【おすすめ】これからWebする人はここ読んどけ(HTML/CSS/JS/Ps/Ai.etc) 【おすすめ】Qiitaを使い倒す方法一覧 Tigとは 定義 Tig is an ncurses-based text-mode interface for git. It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands. 要
こんにちは@a_suenamiと申します。 これはGit Advent Calendar 2012の17日目の記事になります。 前日はid:akiyokoさんのGitコマンド総選挙でした。 Gitの内部構造 みなさんはGitがどういう風にデータを管理しているか意識したことはありますか? コマンドの使い方に関するTipsはよく見かけるのですが、なかなかデータ構造に着目した解説は少ないのが実情かと思います。 そこで本日は僕が以前社内で行ったGit勉強会の話をもとにして、Gitの内部でどのようなデータがやりとりされているのかという話をしたいと思います。以下が以前僕が社内で勉強会をしたときの資料です。 http://www.slideshare.net/asuenami/git-15199548 タイトルの通り、非プログラマ向けの内容なのですが、PART2ではGitの内部構造を擬人化して説明すると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く