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 する際には
「追跡ブランチ」って言うのやめましょう - Qiita
TL;DR 突然ですがクイズです。「追跡ブランチ (tracking branch)」という言葉の使い方で正しいのはどれだと思いますか？ origin/master はリモートリポジトリの master を追跡する追跡ブランチである origin/master はローカルの master に追跡される追跡ブランチである ローカルの master は origin/master を追跡する追跡ブランチである 現在の正解は多分3番です。過去には1番でした。 分からなかった方、分かったけど他人に「追跡ブランチ」と言って伝わるか不安な方。大丈夫です。正確な用語1で言い換えることにしましょう。 origin/master はリモートリポジトリの master を追跡するリモート追跡ブランチ (remote-tracking branch)である origin/master はローカルの master
[Git][GitHub]GitHubにPushする際に認証失敗する
GitHub で2段階認証の設定をしてから push 時に認証が失敗するようになりました。 いつもどおり以下のコマンドを実行すると ID/PW を聞かれます。 git push origin master Username for 'https://github.com': Password for 'https://github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/wada811/AndroidLibrary-wada811.git/' [Git][GitHub]やっておくと地味に便利なこと2つ | DevAchieve で .netrc に ID/PW を書いているので 聞かれるのはおかしいなぁと思いながら ID/PW を入力しま
![[Git][GitHub]GitHubにPushする際に認証失敗する](https://cdn-ak-scissors.b.st-hatena.com/image/square/fd365f3298946835d1a3a2dc01010e3766b0ec06/height=288;version=1;width=512/https%3A%2F%2F2.bp.blogspot.com%2F-6Mr2ivhd670%2FUyQFrJ7bwPI%2FAAAAAAAAAi0%2FHy6L5VvxM9g%2Fw1200-h630-p-k-no-nu%2FOctcat.png)
githubで2段階認証を設定したらpushできなくなった - Qiita
$ ssh -T git@github.com Warning: Permanently added 'github.com,192.30.252.128' (RSA) to the list of known hosts. Hi myoan! You've successfully authenticated, but GitHub does not provide shell access. Username for 'https://github.com': myoan Password for 'https://myoan@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/myoan/repository.git/' しかも、
tbaggery - A Note About Git Commit Messages
19 Apr 2008 I want to take a moment to elaborate on what makes a well formed commit message. I think the best practices for commit message formatting is one of the little details that makes Git great. Understandably, some of the first commits to rails.git have messages of the really-long-line variety, and I want to expand on why this is a poor practice. Here’s a model Git commit message: Capitaliz
Git の Commit Author と Commiter を変更する - Qiita
Git のコミットには、Author と Commiter の2つが存在します。 例えば、いつもと違う PC を使ったときに、.gitconfig の設定が違うと、コミットに意図しないメールアドレス・ユーザー名が入ったりします。 Git で見るとこんな感じ $ git log -1 --pretty=full commit befdbcd2389373088fe3e83d9c0d401a9de7717d Author: hogehoge <dummy@example.com> Commit: fugafuga <test@example.com> add test.txt GitHub 上では、コミットに表示される、いつもの自分のアイコンが表示されなくなるので、ちょっと気になります。 そこですでにコミットしてしまった、コミットの Author と Commiter を変更する方法についてま
Gitでブランチを統合する方法 — 裏紙
#!/bin/sh rm -fr .git *.txt .gitignore git init echo init.sh>.gitignore && git add .gitignore && git commit -m "Initial Commit" echo b>b.txt && git add b.txt && git commit -m "master 1" git branch other echo c>c.txt && git add c.txt && git commit -m "master 2" echo d>d.txt && git add d.txt && git commit -m "master 3" git checkout other echo e>e.txt && git add e.txt && git commit -m "other 1" echo
Big Sky :: 意外と知られていない github 技
github で git diff from..to を表示する - #生存戦略 、それは - subtech で text/plain な diff が表示される。.. じゃなくて ... 。 http://subtech.g.hatena.ne.jp/secondlife/20121225/1356421602 github のコミットページ URL は、実は凄く良く出来ている。 例えば pull request のページ Add each Gem bundled data pointer in mrb_state by masuidrive - Pull Request #605 - mruby/mruby - GitHub Showing 17 changed files with 183 additions and 36 deletions . Show Diff Stats H
iOS開発とGitタグ
いままでAppleにアプリを申請するタイミングでタグを打っていて、 その後にリジェクトされると以下のようなタグが残ることがありました。 非常にダサいですね。 1.0.0 1.0.0-2 1.0.0-3 最近は少し学習して、QAに入る段階でrelease/1.0.0といったブランチを切るようにしました。 審査に出した段階ではまだタグは打たず、もしもリジェクトされた場合は引き続きrelease/1.0.0を更新します。 審査を通過した場合はそこでタグを打って、release/1.0.0をmasterにマージします。 以下の図のようなイメージです。 このように運用することで、余計なタグが打たれることはありませんし、審査中のバージョンを見失うこともありません。 もしかしたら普通のiOSデベロッパーは当たり前のように実践していることなのかもしれませんが、 自分は最近までダサいタグを打ったり、タグを打
Octotree - GitHub code tree
GitHub on steroids Browser extension that enhances GitHub code review and exploration. Features * Fast IDE-like code tree * Quick search in tree format * Bookmark repos, issues, PRs, files * Support GitHub themes * Support private repositories * High performance, working with repositories of any size PRO features * File icon themes * Code font settings * Quick PR navigation * Unlimited bookmarks *
tigでgitをもっと便利に！ addやcommitも - Qiita
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
git add -p のときの e(手動編集) - 肉とビールとパンケーキ by @sotarok
自分ではあまり add -p の e ってつかったことなかったんだけど友達がよくわからんってことだったので調べてみた。 以下のような diff を add -p して、 e してみます。 $ git add -p diff --git a/fuga b/fuga index 1a39df0..5bc676d 100644 --- a/fuga +++ b/fuga @@ -1,5 +1,5 @@ // hoge -fuga piyo hogera +fugera Stage this hunk [y,n,q,a,d,/,s,e,?]? e で、エディタが起動するわけです。以下のような感じで書いてあります。 # Manual hunk edit mode -- see bottom for a quick guide @@ -1,5 +1,5 @@ // hoge -fuga piyo ho
Git で変更されたファイルを簡単に無視する設定 - 永遠に未完成
管理下に置かれてるんだけどなぜか無駄に変更されてしまうファイルというのがたまにあって、まあ管理方法見直せという話もあるんだけど、それも叶わない場合、そういうのは無視したい。 その方法についてはこの記事が詳しいのだけど、私はこれを以下のように alias 設定している。 [alias] ignore = update-index --assume-unchanged unignore = update-index --no-assume-unchanged ignored = !git ls-files -v | grep "^[a-z]"これで、 git ignore {file} ファイルを無視する git ignored 無視されたファイルの一覧を表示する git unignore {file} 無視されたファイルを元に戻す という風に直感的に扱えるので便利。
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
研究室でGithub勉強会をしました。 - FromAtoMemo
@10月18日 世はまさに、大ソーシャル時代！ というわけで、研究室でGithub勉強会をしました。 ある日私は、研究室の課題で『もじたま』を作っていました。この課題はグループワークだったのですが、"1台のパソコンにグループメンバーが集まってコーディングやデバッグをする"という、つらぽよ案件が多発していて、「このまま放置しておいたら、人が死ぬぞ……。」と思ったのが、勉強会をしようと思ったきっかけです。 ローカルな不幸を減らす為に 恐らく、学生がよく聞く（言う）セリフとして 「研究室にソースコード忘れて、家でデバッグできない。」 「最新データ入れたUSBメモリ忘れた。」 「パソコンクラッシュして、全データ死んだ。」 があります。これをそのまま放置しては大変に不幸。論文・レポート提出間際に、これらの不幸によって死の覚悟をするのは、精神衛生上でもよろしくないです。 オンラインストレージサービスな
天下一gitconfig大会
天下一gitconfig大会(サイボウズ社内git勉強会@2012/11/20)の@teppeisの資料です。 ぎっとぎとにしてやんよ GistDeck gistでmarkdown書いたらbookmarkletでプレゼンになるよ。 ↓これをBookmarkに登録してこのページで実行してみよー！ javascript:(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.setAttribute(%27src%27,%27https://raw.github.com/teppeis/gistdeck/fix/gistdeck.js%27)%3Bdocument.getElementsByTagName(%27head%27)%5B0%5D.appendChild(s)%3B%7D)()%3B 複数行のcodeとかが微
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitのuser.nameとuser.emailを会社/個人で自動的に切り替える方法 - Qiita
［初心者向け］こんなときどうする⁉︎ GitのTips31選！ - Qiita
Loading...
GitBook – Knowledge management for technical teams
