Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
![Gitで間違えてmasterにコミットしてしまったときの対処法](https://cdn-ak-scissors.b.st-hatena.com/image/square/98f80643594ac5cfbef89332adc925565577f622/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9R2l0JUUzJTgxJUE3JUU5JTk2JTkzJUU5JTgxJTk1JUUzJTgxJTg4JUUzJTgxJUE2bWFzdGVyJUUzJTgxJUFCJUUzJTgyJUIzJUUzJTgzJTlGJUUzJTgzJTgzJUUzJTgzJTg4JUUzJTgxJTk3JUUzJTgxJUE2JUUzJTgxJTk3JUUzJTgxJUJFJUUzJTgxJUEzJUUzJTgxJTlGJUUzJTgxJUE4JUUzJTgxJThEJUUzJTgxJUFFJUU1JUFGJUJFJUU1JTg3JUE2JUU2JUIzJTk1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1mMzllMDk1MmNhMjUyODRjNjEwODY5YzM0OGY4NzQ0ZA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDByaF8mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTY5ZWJmZTcxOWJmODQ0ODdmYmYwMGFhMzAxM2RlZGJl%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D448956930441e5c502eb31cab3b14cde)
Git において バージョン管理の対象外としたいファイル (無視したいファイル) は .gitignore で指定しますが, 通常 .gitignore はプロジェクト全体で共有されます. 自分の環境 (ローカル環境) に存在するファイルを 個人的に 管理対象外にするためにはどうしたら良いでしょうか? あるプロジェクト配下の任意のファイルを 個人的に バージョン管理対象外にしたい.(プロジェクトごとの指定) 当該プロジェクトの .git/info/exclude ファイルに バージョン管理対象外にしたいファイルを指定する. .git/info/exclude ファイル # git ls-files --others --exclude-from=.git/info/exclude # Lines that start with '#' are comments. # For a proje
-b, --ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent. -w, --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none. 要約すると git diff -bはスペースの違いを無視する(ignore-space-change) git d
Git リモートリポジトリのHEADのブランチを変更する方法について記載 1.リモートサーバーにログイン 2.サーバのリポジトリに移動 $ cd /path/to/repos/hogehoge.git 3.HEAD を develop ブランチに変更する $ git symbolic-ref HEAD refs/heads/develop これで、cloneしたときのブランチはdevelopになります Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationWhat you can do with signing up
git diff は色んな場面で本当によく使うんですが、できることが多いだけに全然覚えられずに毎回調べてしまいます。 なので、場面ごとに使えるコマンドを一覧でまとめてみました。 先にワークツリーとインデックス【Gitの基本】- サルでもわかるGit入門を読んでおくと、ここに書いてある diff について理解しやすいと思います。 git pull する前にリモートとの変更点を見る git pull をする前にローカルの最新コミットと pull 先のリモートリポジトリとの変更点が見たいときはこのコマンドで見れます。 ここでいうリモート名は origin とかそういうやつです。 git push する前にリモートとの変更点を見る 上記のコマンドは、こんな感じで逆にもできます。
みなさんgitのsubmoduleって理解して使ってますか? 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか? 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
tl,dr GitHub上でリポジトリトップに [LICENSE] ファイル作ればよろし やりたいこと GitHubでリポジトリを作る時にライセンスを指定できるのは有名ですが、ライセンスを指定しないで作っちゃったリポジトリに後からライセンスを適用したい、ってこともあると思います。 実は楽勝です。 やりかた GitHubの当該リポジトリを表示し、(やりたいのであればブランチ切るとか選択するとかなんとかしてから)リポジトリのトップディレクトリで [Create New File] ファイル名を指定できるので、そこに [LICENSE] と入力 すると右側にライセンス選択のプルダウンが現れる 選んでコミットしておしまい MITライセンスを選べばちゃんとライセンス文章の名前の所をGitHubに登録した名前に変えてくれてますし、そのまま使えるものになっています 参考 : Open source li
% git push origin master To https://github.com/xxxx/xxxxx.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/xxxx/xxxxx.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
ローカルリポジトリに複数のリモートリポジトリを設定する方法になります。remote add を使ってoriginと別のリモートリポジトリをラベルに設定して管理することができるようです。 複数のリモートリポジトリを管理して、作業することがあるのでメモとして残しておきます。 リモートリポジトリの確認 現在のリモートリポジトリを確認するコマンド
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く