気をつけて！Git for Windowsにおける改行コード - Qiita
これをみるとinputやfalseはLF -> CRLFの自動変換を行わないので、これらを選んでしまいそうですが、 大規模開発で多数の開発者がtrueでインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか？がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。 core.autocrlfをtrueに設定をした場合 core.autocrlfをtrueに設定をした場合について整理します。 チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。 上記の図から確かにwroking directory上ではCRLFとLFが混在してしまう可能性がありますが、 repository上のファイルがLFである以上、core.
GithubでPull Requestは絶対消せない。ヤバい＼(^o^)／ｵﾜﾀ - アジャイルSEの憂鬱
2013/10/16: Githubのhelp「Remove sensitive data」について追記 先日、初めて知ったのですが、GithubのプルリクをCloseは出来ても、削除は出来ない。(*1) 普段使う上では困らないのですが、パスワードなどの公開すべきでない情報がプルリクに含まれると、結構ヤバい事になる。 結論 結論を先に書くと「リポジトリを作り直すしかない」 試したこと プルリクしてるブランチを上書きする パスワードなどの情報をコミットから(rebase -iなどで)消してからブランチを上書きしてみた。 $ git push -f origin topic_branch プルリクに上書き前後の履歴が全て表示される... プルリクエストしたブランチを削除する 実はGithubでプルリク中のブランチを削除すると、自動的にプルリクがCloseになる。 Closeになるだけだった..
めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
Gitのブランチで効率的に開発・運用・保守・管理する方法 - (DxD)∞
はじめに 最初に、Gitに関するリソースとして、本では「入門Git」と「実用Git」、Web上では「Pro Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。 特に、他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。 しかし、Gitを利用していくにつれて色々と疑問も出てきます。局所的なワークフローについては、様々なリソースによって理解することができます。では、効率的に開発・運用・保守・管理を行うために、大局的・継続的なワークフローをどのように採ればよいのか、特にGitの柔軟性を活かすにはブランチをどのように使えば
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
