bitbucketにpushできない - Qiita
ERROR: Repository not found. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 解決策 bitbucketに再度sshキー登録したらpushできた sshキーの登録はこちらからできる（XXXは自分のID入れる） https://bitbucket.org/account/user/XXXXXXXX/ssh-keys/ 違うレポジトリには普通にpushできるのでsshキーが登録されてないってことはないと思ったのだが、何がいけなかったのか。 前やった時はリモートの設定を削除して登録しなおしたら出来たんだけどな
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
SubversionのリポジトリをGitリポジトリに移行する - ぱろっと・すたじお
私が一番最初に使ったバージョン管理システムはCVSでした あれがなければ、当時の無茶なチーム開発は不可能だったと思いますが、 使いづらい面もあって、ある程度運用でカバーしなければなりませんでした それを解決したのがSubversionで、 今の会社に至るまで、公私ともに使い続けていました しかし、時代は流れ、分散型リポジトリが主流となり、 私自身、数年前から使い出したGitに慣れてしまったのもあって、 もうSubversionには戻りたくありません(´-ω-) ちょうど、こちらのコラムにもそんな話が WEB+DB PRESS 総集編 [Vol.1?60] 作者: 森田創,cho45,ミック,増井俊之,山本陽平,角谷信太郎,中島拓,縣俊貴,大塚知洋,伊藤直也,小飼弾,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2011/10/15メディア: 大型本購入: 52人 ク
git reset --hard HEAD を安全にした - 永遠に未完成
昨日、git reset --hard HEAD してしまって大変なことになった話を書いた。私は普段これを cancel と言う名前に alias して使っている。 [alias] # 中略 cancel = reset --hard HEAD しかし前回のようなことがまたあってはたまらない。人間はミスするものだ。 alias があって実行しやすいのが問題なのだろうか? いや、割とよくする操作*1だし、alias しなくても使うだろう。 てことで、cancel が安全になるようにしてみた。 [alias] # 中略 cancel = !git commit -a -m 'Temporary commit for cancel' && git reset --hard HEAD~ 一旦コミットしてからそのコミットを消す。こうしておけば最悪 git reflog から元に戻せる。特にコミットす
死んで覚える本当のGitの使い方 - mizchi log
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
git-nowをサブコマンド化してみた - 林檎パーク
最近プロジェクトのVCSがSubversionからGitに移行して、ホクホク顔でgit stashしまくっている今日この頃ですが、みなさんいかがおすごしでしょうか? さてそんなお寒い時候(?)の挨拶はおいといて、hotfixとかfeatureのbranch上でgit-now使いまくっているわけなんです。 git-nowには--rebaseってオプションがあって、あとからcommitをいじっちゃうわけなんですが、それにさらにオプションはやしたり云々やってたらサブコマンド化したくなってやってしまいました＞＜ homebrew化とかもしっちゃった関係(謎)でGitHub上にあげてるんですが、元々のscriptがgistでGitHubとしてforkできなくてid:sinsokuさん、すいません＞＜ git-nowって? temporaryのcommitを簡単にできるコマンドラインツールです。 詳し
Gitで特定のファイルだけをマージする - 大規模サービス開発日誌
cherry-pick Gitを使っているとたまにあるブランチからファイル単位でマージしたくなる。しかし、Gitを使ってる以上コミットをベースに生きるべきなのでそんな気分のときもcherry-pickを使おう。 git cherry-pick これは特定のコミットを選んでマージする機能である。自分が欲しい程よいコミットがなかったらコミットを分割したりして何しかコミット単位でマージするように心がける。そうすることでGitの強力なマージ機能を未来永劫使えるようになるのだ。 実際のところ とはいえ、どうしてもそんな諸々を無視してファイル単位でマージしたい時は以下のようにする。 git checkout branch file... 入門Git作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/19メディア: 単行本購入: 28人 クリック: 6
git initしたあとにリモートを追加してorigin masterを省略するメモ - がぶちゃんの日記
先に結論 git remote add origin git://gabuchan.git git push -u origin master どういう場合に便利？ git cloneすると.git/config が [remote "origin"] url = git://gabuchan.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/masterみたいになるので、git pushでorigin masterを省略できる。 ローカルでgit initしてリポジトリを先に作って、 ちゃっちゃか開発して、 「そろそろリモートにアップしとくかー」って感じでリモートを作って、 git remote addすることが多い。 ちょっと開発をはじ
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
Why I Switched to Git From Mercurial — Extra Cheese
A blog by Gary Bernhardt, Creator & Destroyer of Software I used Mercurial for three years, but started switching to Git about a year ago. I now grudgingly recommend Git to anyone who intends to be a full-time programmer. Git's interface is bad in many ways, which is the main complaint about it, and it's a legitimate one. It's just an interface, though, and this is a tool you're going to use all d
【翻訳】あなたの知らないGit Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
~/.ssh/config で簡単に複数ホストへのSSH接続を管理する - すぱぶらの日記
ssh で鍵やユーザ名を複数のホストで使い分けないといけない場合、それら設定を覚えておくのは面倒です。 それらホスト毎の設定は ~/.ssh/config で簡単に管理することができます。 複数の鍵を管理する場合 identity, id_rsa などのファイル名で保存しますが、これでは複数の鍵を置くことができないので、 test.org の場合、「id_rsa.test.org」 hoge.in の場合、「id_rsa.hoge.in」 など、ホスト名や用途名の prefix, suffix を付けて管理しています。 どの鍵をどのような用途で利用しているのかが分かればファイル名は何でも構いません。 ~/.ssh/configを記述する Host test.org HostName test.org IdentityFile ~/.ssh/id_rsa.test.org User test
Git超入門："git push origin master"の"push"と"origin"と"master"の意味がわからないあなたへ · DQNEO日記
Home Subscribe この２行のコマンドを見て((；ﾟДﾟ))ｶﾞｸﾌﾞﾙした経験はないでしょうか？ 私は恐怖を感じました。 "remote"と"add"と"origin"と"push"と"master"の意味がわからん！！ 人間（というか私は）は、わからないものが３つ以上同時に登場すると、ストレスを感じるものです。 この場合は５つもあるのでものすごいストレスです。 でもご安心を！ これから超わかりやすく解説します！ git remote add origin ... の意味は？ ずばり、 URLに"origin"という短縮名(ニックネーム)を付ける したがって、git remote add unko .... と書いてもかまいません。 慣習上、"origin"という名前が使われることが多いというだけのことです。 そして、ここが重要なのですが 別にニックネームをつけなくてもよい。(
GitHub Flow (Japanese translation)
GitHub Flow Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで git-flow についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチを master ではなく develop から開
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
github を用いた開発フローテンプレート
Git で不要になったローカルブランチ・リモートブランチの削除 - sotarokのお勉強
