git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
Magit User Manual.html
Magitユーザーマニュアル Magit は、バージョン管理システムGitリポジトリへのインターフェースで、 Emacsへの拡張機能として実装されています。 Magitは、GNU Emacsのバージョン22以降をサポートしています。 それは、他のemacs達も動作するかもしれませんが、Magit開発者は、サポートされていないバージョンで表示されたバグを調査し、修正するつもりは ありません。 でも、他のemacs達のバグ修正パッチや、互換性を維持するボランティア活動は歓迎します。 はじめに 謝辞 セクション ステータス 追跡されていないファイル ステージングとコミット 履歴 Reflogs...
DockerHubのAutomated Buildsをフックして最新のDockerコンテナをデプロイする
DockerHubのAutomated Buildsをフックして最新のDockerコンテナをデプロイする DockerHubのAutomated Buildsは，GithubやBitbucketへのgit pushをフックしてレポジトリ内のDockerfileを元にDockerイメージをビルドする機能である． イメージを使う側からすれば，それがどのようなDockfileから作られているか可視化され，常に新しいイメージがあることが保証されるので安心感がある．イメージを提供する側からすればDockerfileを更新してgit pushすれば自動でビルドしてくれくれるので楽という利点がある．そのためDockerHubにイメージを上げる場合は，docker pushを使うことはほとんどなくてこのAutomated Buildsを使うのが普通である． このAutomated BuildsはWeb h
Devicons | The developer's iconic font
Meet Devicons, an iconic font made for developers, code jedis, ninjas, HTTPsters, evangelists and nerds.
Web制作者のための実践Git | 第1回 適切な履歴の作り方
上記の例の場合、変更した箇所が近いため同じhunk（変更の塊）として表示されています。ですので、hunkをさらに分割する必要があります。そのためにはsを選択します。そうすると次のような表示になります。 Split into 2 hunks. @@ -1,5 +1,5 @@ <ul> <li><a href="/">Home</a></li> - <li><a href="/about.html">About</a> + <li><a href="/about.html">About</a></li> <li><a href="/help.html">Help</a></li> </ul> Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 変更が分割されて閉じタグ忘れだけの変更が表示されています。ここでyを押してこの変更をステージングします。すると次は以下の表
Jenkinsの使い勝手をよくするための見直し6点 ｜ Developers.IO
今回の課題 こんにちは植木和樹です。7月にserverspecを使ったChefの自動テストのエントリを書きました。 【AWS】JenkinsとserverspecでChefのテストを自動化する このエントリは初めてJenkinsを触った時に書いたので、いろいろと流儀がわかっていませんでした。その後弊社にJenkinsマイスターの渡辺修司さんが入社したということで、Jenkinsの設定について見てもらいました。その時に次の6点を見直すよう指摘がありました。 ジョブは意味ある単位で1つにまとめるべし ジョブで実行するシェルスクリプトもgitから取得すべし EC2の起動に失敗したら後続処理を停止させるべし serverspecの実行結果はJUnit（XML）形式で出力すべし 実行結果のXMLをJenkinsで読み込んで統計グラフを出力すべし 定時実行でなくgit push hookを入れるべし
GitHubでプルリクエスト用ブランチを保守するメモ - なんたらノート第三期ベータ
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita
〔提案に対して〕いいと思う；問題ないと思う；〔コードレビュアーが、問題ないコードに対して〕レビュー終了；（コードの）承認
git-gutter.el - naoyaのはてなダイアリー
寝れないので変な時間にブログを書いたりする。 時折思い立ったように Emacs Lisp を見直して色々導入を試みたりするも、結局割り当てたキーバインドを忘れてたりして定着しない、というものは多い。そんな中でもここ1, 2ヶ月くらいで定着したのが git-gutter.el。 このように緑のプラス記号なんかが出て git で管理しているファイルを編集した場合の差分がどこかが一目でわかる。 多くの elisp がそうなんだけど、導入する前までは便利そうだけどそこまで必要かな? と思いつつ入れてみたらもう手放せなくなった、そういう類です。ぼーっとしながらコード書いてる時でも、あそことあそことあそこを編集したんだなってのが git diff とかしなくても分かる。 これを入れるとちょっと動きがモッサリするみたいな話もあるけど、作者の id:syohex さんが鋭意改善中 (http://d.ha
愛知県の社会福祉法人 清凉会は、老人ホーム・デイサービス・特別養護老人ホーム・保育園などを運営しております。
ABOUT SEIRYOU GROUP 清凉グループについて 清凉グループでは、「あふれる笑顔～慈悲の心で～」を経営理念として掲げ、 地域における介護・保育ニーズにお応えすべく、複数の施設を運営しております。 今後も地域の皆様の生活に寄り添う場所として、個々の施設と連携し、よりよいサービスを追求していく所存です。 清凉グループからのお知らせinformation
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitignore.io - Create useful .gitignore files for your project
GitHub - tiimgreen/github-cheat-sheet: A list of cool features of Git and GitHub.
index - やる夫で学ぶ gitcore-tutorial
英語コミットコメントに使えるオシャレフレーズ集
はじめてのGit #gitkyoto
submoduleの削除 - 呆備録
layer8.sh
GitHub Flow (Japanese translation)
http://blog.inouetakuya.info/entry/20130602/1370173582
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
