create-projectコマンド 既存のパッケージから新規プロジェクトを作成することができます。 git clone / svn checkoutの後に composer installを実行するのと同じです。 https://getcomposer.org/doc/03-cli.md#create-project
![Composerコマンドについて - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ea18b33cc249503659f476d16b2237316a6886ba/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9Q29tcG9zZXIlRTMlODIlQjMlRTMlODMlOUUlRTMlODMlQjMlRTMlODMlODklRTMlODElQUIlRTMlODElQTQlRTMlODElODQlRTMlODElQTYmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTY4NWMwODQxNjQ2NjkxNTc2NWNiMGQyNzllZDZjNDIw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDByZWZsZXQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWRlNDZiYjIzZDNmYTljOTM1OTlmYjg3NjFlMGRhMzhm%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D27ea052f75c38164d51169b2e586d083)
今日は Git コマンドの奥深さを感じた! 結構 Git には詳しい方だと自負していたけど,全然知らないことあるなーと痛感した. git show git show で「特定のブランチにあるファイル」や「特定のコミットでのファイル」を見ることができる.コロンを忘れずに! git show ${branch}:${file} git show ${commit}:${file} git checkout git checkout ${branch} ${file} で「特定のブランチにあるファイルをコピー」できる.今日活躍したコマンドだった.コミット単位なら git cherry-pick を使えば良いけど,コミット数が多かったりすると面倒だし,ファイル単位で操作することはできないので,そういうときに使える. git checkout ${branch} ${file} 関連記事 kakak
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる? コミットが綺麗になる! 以上です! この一言に尽きる! 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか? 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います! マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
空ブランチ Gitではコミットやブランチを作成する場合、必ず親を指定する必要があります。今までの歴史を全て辿れるようにするためです。 空ブランチを作成すると、今までの歴史とは全く別の新たな歴史を、同じリポジトリ内で開始することができます。 作成方法1: Github pagesの場合 Github pages ではプロジェクトサイトを作成する際にはプロジェクトのリポジトリ内で空ブランチを作成します。 空ブランチを使う理由はわかりませんが、プロジェクト本体には影響させず、リポジトリ内に同梱させるためにこの手法を採用したのだと思います。 # HEADをnew_branchに切り替える。 git symbolic-ref HEAD refs/heads/new_branch # symbolic-refを直接変更した場合はインデックスとワーキングツリーが残るので削除する rm .git/inde
この記事は Git Advent Calendar 2016 の 20 日目です。git コマンドを日常的に実行するわけですが、外部スクリプトなどで個人的に日々改善しているお話についてまとめてみました。 ブランチ切り替えを手早くする git オペレーションで add,commit 並に多用すると思うのがブランチ切り替えで、特に remote にある branch の切り替えなどをショートカットしたくスクリプトを書きました。 $ git br で fzf/peco などのフィルタで切り替えてくれます。ブランチ切り替え系はよくある tips なのですが、何が便利かというと、remotes/origin/HOGE などのリモートにしかないブランチは git checkout -b HOGE remote/origin/HOGE してくれるようになっているので気にせずに checkout できます
githubを使っていて、プルリクエストのMergeボタンが灰色になってて、 あ、コンフリクトが起きそう! と思った時にどう対応するのが一番よいのか考える。 前提条件 github flowを使っている hogehogeブランチ→masterに対してpull requestを送っている。 自分がhogehogeブランチで作業していて、最新の状態がローカルにある。 案 僕がいいと思った順に書いていきます。 案1.灰色になっていたのを確認した瞬間にgit rebase masterして解消する 前提 自分一人しかそのbranchで作業していない ある程度rebaseがどういうものなのかわかっている。 作業内容 git fetch origin git checkout master git pull origin master git checkout hogehoge git rebase
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん?ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
ついに発売しました! RPGツクールMV!!!ということで早速触ってみました。 http://store.steampowered.com/app/363890/ (日本語版は12月。何故か英語版の方が発売が早い・・・) ちなみに、ツクール触るのは2003ぶりです。 RPGツクールMVって? RPGツクールの最新作。 今回はWindowsの他に、Mac, iOS, Androidそしてhtml5にも出力できちゃいます。 https://tkool.jp/mv/ あと、オンラインゲームとか作れちゃうみたいです。 GitHub Pagesって? GitHubには、GitHub Pagesというリポジトリをそのままwebサイトとして公開できる便利な機能があります。 https://pages.github.com/ そして、RPGツクールMVのプロジェクトは、 「アップロードすればwebサイト上
Gitは速く柔軟性がありますが、理解に時間のかかる分散型バージョン管理システムです。Gitを始める前に次を理解しておきましょう。 通常のバージョン管理 分散型バージョン管理 本 や 学習書 、 指南書 はGitを理解するのに役に立ちました。しかし、その他にもGitの理解に至ったきっかけがありますのでご紹介します。 ステージング・エリアがある Gitにはステージング・エリアがあります。繰り返しますが、 ステージング・エリアがあるのです 。 これには混乱しました。リポジトリ(「オブジェクトデータベース」)とステージング・エリア(「インデックス」と呼ばれる)の両方がGitにはあります。チェックインには2段階あります。 git add foo.txt インデックスにfoo.txtを追加します。これだけでは、チェックインは完了していません。 git commit -m "message" リポジトリ
はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか?と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
はじめに 「開発者(個人)のための」としているのは、別に自分でやっても良いんだけど Jenkins に任せられるなら任せたい、くらいのモチベーションを表現したつもりです。 環境 Ubuntu 14.04 LTS Jenkins 1.573 Bootstrap になって雰囲気が変わりましたね 初期設定 Jenkins 初期設定 Plugin のインストール Git Plugin 依存しているPluginも自動的にインストールされます。 Git Parameter Plugin は、ビルド時に Extended Choice Parameter plugin の Single Select ようなパラメータ形式で、リビジョンやタグを選択できるプラグインです。 Git 初期設定 Git Install Git がインストールされていないなら、apt や yum でインストールしておいて良いでしょ
git 1.7からsparse checkout機能が利用できるらしい。 ざっくりとした使い方は以下の通り、 $ git clone リポジトリURL hoge $ cd hoge $ git config core.sparsecheckout true $ echo "hoge.txt" > .git/info/sparse-checkout $ git read-tree -m -u HEAD こうするとワーキングディレクトリ下はhoge.txtファイルだけチェックアウトされる様になるらしい。 これまで制作部スタッフにhtmlファイルを編集してもらうのに社内共有フォルダでファイルの受け渡しをしていたんだけど、この機能を使ったらもう少しスマートにならないかなと考え中。 gitスキルのない制作部スタッフにいきなり今日からgit運用にします。ってのは、ハードル高すぎるので、gitアクセスは
ABOUT SEIRYOU GROUP 清凉グループについて 清凉グループでは、「あふれる笑顔~慈悲の心で~」を経営理念として掲げ、 地域における介護・保育ニーズにお応えすべく、複数の施設を運営しております。 今後も地域の皆様の生活に寄り添う場所として、個々の施設と連携し、よりよいサービスを追求していく所存です。 清凉グループからのお知らせinformation
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く