.gitignore書き忘れて add & commit しちゃったとかよくありますよね。そんな人いないっすよね:-) そんな時は git rm。 ファイルも一緒に削除したいとき〜
Git管理下、いわゆるローカルで作業してて、内容を保存。 ファイルを閉じる。 あ、やっぱ今の保存なし! ・・・閉じてしまったからCtrl+Zも効かねぇ! って時に使うコマンド。 git checkout branchの切り替えに使ったこのコマンドが、そういう用途でも使えるそうな。 # そのディレクトリ全部 git checkout . # 単品 git checkout hoge.htmlでもあくまで戻せるのは、「最後にコミットした時点まで」 何回も開いて保存して閉じてしてた場合に、2回閉じる前まで!ってのはできません。 ・・・できたら良かったのに。 そんでもってこのコマンドは、以下と同じ。 git checkout HEAD hoge.htmlチェックアウト=作業開始の宣言と捉えるならば、 最後に作業開始しようとした瞬間=最後にコミットした直後 そのコミットした瞬間に立ち戻る・・って意味
1週間ぐらい作業した内容をgithubのmasterにpushした後、よく考えたらこれ全部別プロジェクトにしたほうがいい・・ という事に気づき、1週間前の状態に戻した。 せっかくの1週間分の作業を失ってしまうのも何なので、あとで別プロジェクトにコピペするために黒歴史ブランチとしてとっておく事にした。 git push origin :masterでgithubのmasterを削除してpushしなおせばいいかと思ったけど、なぜかmasterだけは削除できなかった。 masterを黒歴史branchにする git checkout master git checkout -b black_history git push origin black_history git branch -D master 黒歴史をgithubにもpushした。ローカルのmasterは削除。 1週間前の状態をma
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
次回以降の流れは?(2016/04/11 0時 追記) マンガでわかるGitの構成は、ざっくり下記の構成を考えています。 最初の一歩: Gitとはなんぞや? 第一フェーズ: 1人で使ってみる 第二フェーズ: 複数人で使ってみる 第三フェーズ: 実務上でのハウツー(応用) これは、まだ私が頭の中で考えているだけの仮段階のものですので、細部はみなさんからのコメント・需要を拝見しながら変更していくと思われます。 ちなみに、はてブコメントで要望の多かった「SVNとGitの違い」 → こちらのマンガ化はやってみたいですね。 #マンガでわかるGit 全体の構成(仮)考えるの楽しい♫ Gitってそもそも何?メリットは? ↓ 一人でGit😃 ↓ 複数人でGit😃😃 の流れで考えています。 はじめてコミット、チェックアウトしたときの感動といったら! pic.twitter.com/uyCl1zAxAF
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request(プルリクエスト)機能を使ったことはありますか? GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork(コピー)してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール(Hg、Bzr など)にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している(Git Lover)と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう? 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです(たぶん)。 それが今で
SourceTreeでいろいろ取り消してみる 修正を破棄する(git checkout) 何かファイルを修正して、作業ツリーに修正ファイルが表示された状態。 この修正を破棄する場合は、破棄したいファイルで 右クリック(または[操作]メニュー)から[リセット...]を選ぶ。 [OK]ボタンを押すと修正が破棄される。 [リポジトリ]メニューの[リセット...]からも破棄することが可能。 ステージしたファイルの取り消し(git reset) Indexにファイルをステージした状態。 チェックボックスを外せば、ステージを取り消せる。 前回のコミットの修正(git commit --amend) コミットメッセージの修正 ファイルを修正してコミットした状態。 プッシュはしていない。 コミットメッセージを修正する場合は、 [コミット]をクリックして、下記の画面を表示する。 [オプションのコミット]で[
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く