GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
git mergetoolでvimdiffを便利に使う - haya14busa
Mergeしんどい 今までConflict起きたら直接コンフリクトしたファイルを編集して完全手動で直してたんですが、mergetoolの存在とかvimdiffとかで出来そうと思って調べました。 Gitの設定 git config --global merge.conflictstyle diff3も紹介されていたけど共通祖先を表示する必要性を感じなかったので無視した。 promptをfalseにすることでmergetoolした時のpromptを省略して編集を始めるようにし、keepBackupをfalseにすることでmergetoolがデフォルトでは自動的に生成する*.origファイルを生成しないように出来る。 Vimの設定 左から1,2,3って覚え方でよさそう。Local,Base,Remoteの頭文字とかでもKeymapに余裕があるならよさそう。 一度diffgetしたあとUndoする
2013/09/27/ブランチやタグを指定してgit cloneできることを知った - ヽ（´・肉・｀）ノログ
git clone する時に HEAD 以外が欲しいことがある． その場合 git clone して，その後 git checkout (branch-name) としていた．そんなに手間でもないので，特に困ってはいなかった． ふと直接指定できないかと調べてみたところ，できそうだったのでこの驚きを共有したい． man git-clone すると –branch <name>, -b <name> Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository’s HEAD, point to <name> branch instead. In a non-bare repository, this is the branch that will be checkedou
【Tig全まとめ】Gitを自由自在に操るための必殺ツール - Qiita
インストール方法から参考リンクまで。 自分の勉強ついでに、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. 要
Gitチートシート - Qiita
用語 リポジトリ バージョン管理システムにおいて，プログラムやファイルを蓄積しておく場所． Gitではローカルリポジトリとリモートリポジトリの二種類のリポジトリを扱える． ローカルリポジトリ 現在作業中のリポジトリ．主に自分のPCや開発サーバーなどで作業する場合はローカルリポジトリとなる． また，リモートリポジトリからリポジトリをクローンして，自分のPC上やサーバー上に環境を構築することもできる． リモートリポジトリ 外部にあるリポジトリ．リモートリポジトリはローカルリポジトリを通じて作業を行う． 複数人での作業やインターネットに公開する場合に利用できる． ワーキングツリー ユーザーが編集したり新しいファイルを作成したりする場所． インデックス ワーキングツリーでの編集後，リポジトリへのコミットの前に次のコミットの対象となる状態を保持している場所． ブランチ 履歴の流れを分岐して記録してい
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
合肥便民家电维修服务网点
大部分不被重视的部门启动新项目时困难重重�� ，业务落后又难以突破����，逼着一个个网易员工们出去创业�����。数字阅读也是一个很成熟的付费市场�����，还有以爱奇艺为首的视频网站����，它们从最初三大运营商的付费模式衍生到VIP会员的付费模式 ���，给视频网站补充资金并且创造了盈利的可能性� �。...... 查看更多
zshでgitのコマンドやブランチ名を補完できるようにする | qnyp blog
zshでのgitコマンドの入力補完を設定する方法はいくつかあるようですが、最近はgitのソースツリーにcontrib/completion/git-completion.zshというものが含まれているので、今回はそれを利用する手順を紹介します。 設定を行うと、以下のようにコマンドやリモートリポジトリ、ブランチ名の補完ができるようになります。 今回、動作を確認した環境は以下の通りです。 Mac OS X 10.8.3 zsh 5.0.2 git 1.8.2.3 zshとgitをHomebrewでインストールしている場合は、zshの設定を行うだけで作業完了です。git 1.8.2.2に含まれる補完定義ファイルとgit 1.8.2.3に含まれるそれとでは結構違いがあるようなので（コミットログ）、gitはできるだけ最新版にアップデートしておきましょう。 Homebrewを使っていない場合は、補完定
dotfilesをGitHubで管理，vimプラグインをNeoBundleで管理する方法メモ - c-bata web
ドットファイルをGitHubで管理する 最近知ったのですが，.vimrcや.bashrc等のファイルのことをドットファイルというようです。 これらをGitHubで管理することでどのマシンでも同じ設定がすぐに使える！っていうのが流行っているらしいなので、早速取り入れてみる。 まずはGitHubのページから「Create new Repository」を選択。「dotfiles」という名前のリポジトリを作成。 この時，README.md等を作成するのところにチェックを入れると後でpushするときに面倒くさくなるので，リポジトリ名だけを指定してリポジトリ作成。 それが終わったら次はローカルにdotfilesディレクトリを作成して，GitHubで管理したいファイルを移動する。 $ cd $ mkdir dotfiles $ mv .vimrc dotfiles $ mv .gvimrc dotfi
gitのサブモジュールの使い方 - sugoi wada blog
gitのサブモジュールの追加と削除を簡単にまとめ。 なお、本記事のgitのバージョンはこちら。 1 2 $ git --version git version 1.8.5.2 サブモジュールを追加 1 $ git submodule add git://xxxxxxx.git DIR ※DIRは任意 ブランチを加える場合は-bでブランチを指定する。 1 $ git submodule add -b branch_name git://xxxxxxx.git サブモジュールを削除 1 2 3 $ git submodule deinit path/to/submodule $ git rm path/to/submodule $ rm -rf .git/modules/path/to/submodule サブモジュールの初期化・更新 サブモジュールを含むリポジトリをクローンしたときは、まず始
ブランチの作成 - 千鳥足プログラマーの歩む道@shimosuk
msys.batで"MINGW32"をというのを使ってます。 git checkout -b <作成名> <ブランチ基> 今までにこんなerrorが出た $ git checkout -b <作成名> <ブランチ基> error: The following untracked working tree files would be overwritten by checko ut: "※※" Please move or remove them before you can switch branches. Aborting解決した方法は、 rm "※※"でファイルを削除。 そしたらブランチ作れました。 branchの確認 git branch※remoteも見る場合は"-a"をつける
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Gitコンフリクト解消ガイド（git mergetoolの使い方） - Qiita
ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita
あらまし 大きな作業をする場合、こまめにローカルレポジトリのブランチにコミットして、何かあったときにすぐに戻せるようにしたくなります。 また、パフォーマンス改善など、実験や研究の色合いの強い作業は、試行錯誤しながらブランチに"とりあえず"保存しつつ、「あっちのほうが良かったかな〜」と思ったときに取り出せるようにしておきたくなるものです。 また、ローカルレポジトリだけでなく、リモートレポジトリに置いたほうがチームみんなで共有できたりしていろいろ便利です。 ですが、最終成果物はなるべく少ないコミットにしないと、マージが大変です。 メインブランチにこんなコミットが入るとゲンナリしますよね？ $ git log --oneline bcdef12 Revert foo abcdef0 Add foo cdef123 Refactor bar again def1234 Refactor bar e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitで複数のコミットを1つにまとめる | Webシステム開発／教育ソリューションのタイムインターメディア
GitでMerge CommitをRevertする方法 - Qiita
英語コミットコメントに使えるオシャレフレーズ集
良い Commit Messageを書きましょう(翻訳)
gitコマンドチートシート - Qiita
git addの取り消し - 恥知らずのウェブエンジニア -web engineer, shameless
