新しい SSH キーを生成して ssh-agent に追加する - GitHub Docs
SSH キー パスフレーズについて SSH (Secure Shell プロトコル) を使用して、GitHub.com 上のリポジトリ内のデータにアクセスし、書き込みを行うことができます。 SSH 経由で接続する場合は、ローカル コンピューター上の秘密キー ファイルを使用して認証します。 詳しくは、「SSH について」をご覧ください。 SSH キーを生成するときに、パスフレーズを追加してキーをさらにセキュリティで保護できます。 キーを使用するときは、必ずパスフレーズを入力する必要があります。 キーにパスフレーズがあり、キーを使用するたびにパスフレーズを入力したくない場合は、SSH エージェントにキーを追加できます。 SSH エージェントでは SSH キーを管理し、パスフレーズを記憶します。 SSH キーがまだない場合は、認証に使う新しい SSH キーを生成する必要があります。 SSH キー
お前らのコミットは汚い - Qiita
お前らのXXXXは<ネガティブな形容詞>シリーズ で失礼します。 日頃gitをお使いの皆様におかれましては、キレイなコミットを心がけていらっしゃいますでしょうか。 私も心がけてはいますが、なかなか難しいものがあります。 参考までにこちら、最近業務で書いたプルリクエストのコミットログです。 控えめに言って汚いと思われたかと思います。 ではキレイなコミットの例を。 プルリクエストというのは、やはり先達の方に見ていただいてご指摘いただこうというものですから、 当然コミットハッシュもゾロ目等でキレイにするというのがマナーです。 では今回はこのキレイなコミットをどうやって作るのか、という話を書きます (ショート)コミットハッシュ コミットハッシュとは、gitのコミットごとに生成される、40桁の[0-9a-f]からなる文字列です。 お手元のリポジトリ上で git log --format=%H を叩く
Disable warning about detached HEAD
In git if you checkout a commit directly you get a big fat warning starting with: "You are in 'detached HEAD' state. You can look around ..." It's fine - I intend to be in detached HEAD state. However I am using this in a script and I don't want this warning in the output logs but I do want the normal output. My "ugly" workaround now is to run the same command twice, first with -q to hide the warn
Git のトラッキングブランチの確認と設定方法
Git のトラッキングブランチの確認と設定方法 作成日 2018.08.11 更新日 2018.08.15 Git Git でリモートブランチをトラックするローカルブランチをトラッキングブランチと言いますが, トラッキングブランチとはどういうものなのか, どのように確認できるのか, 設定できるのかということを紹介します. Git のバージョンは 2.18.0 です. トラッキングブランチとそうでないブランチの違い そもそもとしてトラッキングブランチとそうでないブランチの違いを軽く説明させていただきたいと思います. まずトラッキングブランチは git clone <repository> でクローンすると自動的に, <repository> のアクティブなブランチが, トラッキングブランチとして作られます. 通常は master というブランチが, トラッキングブランチとして作られます. そ
[日本語訳]A successful Git branching model - Qiita
2010年、オランダのエンジニアVincent Driessenさんの一提案に過ぎなかったgitのブランチモデル A successful Git branching model はその後、世界中に広く浸透し今やgit運用モデルとしてデファクトスタンダードになりました。 今回、Vincent Driessenさんにご快諾いただき日本語訳を掲載することになりました。 Org: http://nvie.com/posts/a-successful-git-branching-model/ Contact: me@nvie.com twitter.com/nvie github.com/nvie keybase.io/nvie はじめに 私がとあるプロジェクト(業務、プライベート双方)で1年ほど前に実際に運用してみて、とてもうまく運用できたと判った開発モデルに関して紹介してみた
![[日本語訳]A successful Git branching model - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d797e30e3c10e12ec8cbeed04d030092bf1b56a8/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-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU2JTk3JUE1JUU2JTlDJUFDJUU4JUFBJTlFJUU4JUE4JUIzJTVEQSUyMHN1Y2Nlc3NmdWwlMjBHaXQlMjBicmFuY2hpbmclMjBtb2RlbCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NmRiY2Q0MDdjYjFiZWRiMDMzYjc2MmIzMmZiYzhhNzY%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaG9taG9tNDQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWRlNWYwMmMwMzU4YjViMWJlMDQ2YmY1MDFjYTUwZmUx%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D9fcb73d6360f3fbc0f6b94d6dc472b97)
リモートリポジトリの巻き戻しが拒否される - tknotebook
現象 リモートリポジトリに誤って登録したコミットを取り消したい場合は、 revert で打消しのコミットを登録するのがまっとうな方法です。 SCMは一度登録したものは取り消さないのが大原則で、登録したコミットを多くの人が 既にpullしていた場合、コミットの削除は大災害に発展する恐れがあるからです。 でも少人数でリポジトリを使っていて、最近誰も pull していないことがわかっているなら、 間違いで登録してしまったコミットはきれいさっぱりを削除したくなるのが人情でしょう。ごみは残したくないものです。 そういう場合は、ローカルリポジトリから git reset HEAD~ --hard git push -f として、push で強制的にリモートのコミットを削除するのが定石ですが、 Total 0 (delta 0), reused 0 (delta 0) remote: error: de
gitでマージコミットが含まれるブランチをrebaseする - 作業ノート
確認したのは以下のバージョン。 $ git --version git version 1.7.12.4 例えば以下のように、マージコミットを含むブランチのコメントを編集したいとき。 $ git log --graph --pretty=format:'%h -%d %s' --abbrev-commit --date=relative * cd00264 - (HEAD, master) Merge branch 'branch-b' |\ | * 8f7b4c7 - add b.txt |/ * 521e66f - Merge branch 'branch-a' |\ | * f5622e4 - add a.txt |/ * 0d8bbff - new この状態でrebaseを行うときに $ git rebase -i HEAD~~ -iオプションだけでは pick f5622e4 a
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
コミットログのエンコーティング指定 - tkmtmktの日記
PowerShellの$OutputEncodingについての説明を読むと、PowerShellがテキストを他のアプリケーションに渡すときに使用するエンコーディングとなっている。 以下のコマンドの結果からすると、PowerShellがgit logの結果のテキストを受け取るときにどのようになっているかは分からないが、nkf32にはUTF8で渡していることが分かる。 PS C:\repo> git log | nkf32 -g ASCII PS C:\repo> $OutputEncoding = [Text.Encoding]::UTF8 PS C:\repo> git log | nkf32 -g UTF-8 処理結果はというと、やはり文字化けする。nkfの処理結果をPowerShellが表示のエンコーディングであるシフトJISに変換して化けてるのか？？？ コンソール表示のエンコーディン
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
GIT clone repo across local file system in windows
I am a complete Noob when it comes to GIT. I have been just taking my first steps over the last few days. I setup a repo on my laptop, pulled down the Trunk from an SVN project (had some issues with branches, not got them working), but all seems ok there. I now want to be able to pull or push from the laptop to my main desktop. The reason being the laptop is handy on the train as I spend 2 hours a
git でディレクトリを管理対象から外す - それマグで！
git に登録したディレクトリで不要になった ものや、実は管理対象じゃなかったものを外すには フォルダを消すコマンド git rm -r --cached /path/to/dir/ フォルダを誤って含めた場合、本当は歴史を書き換えるんだろうけど、そこまではやらなくていい場合。これくらいで十分じゃないでしょうか。 この場合「削除されたこと」が 「deleted」として記録されます。 やってみた git rm -r --cached ./vendor 消したことが記録されます。 On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: vendor/autoload.php deleted: vendor/composer/ClassLoader.php del
Git
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Silent or Unattended Installation
バージョン管理統合サポート | PyCharm ドキュメント
Branches | Bitbucket Data Center 8.19 | Atlassian Documentation
How to get a git subtree diff?
Giving Linux user git access but not shell access? - Stack Overflow
Release Git for Windows 2.8.1 · git-for-windows/git
How to convert a Git shallow clone to a full clone?