gitでマージ作業を中止して元の状態に戻す | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 例えば新機能Xを実装する場合、 X用のトピックブランチを作成し、実装を進めて、完成したら統合ブランチへマージする というのが普通です。 具体的にコマンド例を挙げると以下のようなものになります: $ git checkout -b topic-x master Switched to a new branch 'topic-x' $ $EDITOR $ git add foo.x bar.x baz.x $ git commit -m 'Implement X' [topic-x 0000001] Implement X 3 files changed, 8 insertions(+), 5 deletions(-) $ $EDITOR $ git add qux.x $ git commit -m 'Fix
Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
gitのdiffとかで長い行の表示が切れないように設定する - すぎゃーんメモ
git diffした時に、横に長い行の表示がコンソールの右につきぬけてしまって、右のほうが見えなくなってしまうんだけど、どうすればコンソールの右で折り返して表示してくれるのか誰か教えてくれませんか。MacのTerminalです。 http://twitter.com/shin1ogawa/status/13489861413 というのがあって、 git diff --color | less -Rとかで出来るっぽいという話になったんだけど、そんなのやらなくても設定でどうにかできるはずだよね、という話をhokaccha氏にしてみたら、すぐに調べて教えてくれた。ありがとうございます！ $HOME/.gitconfig に、 [color] ui = auto [core] pager = less -rと書いておけばいいだけらしい。 git diffとかで表示が切れてしまうときの対象方法 -
git lola - bettamodokiのブログ
なにこれ, ちょー便利. So, just copy the following into ~/.gitconfig for your full color git lola action: [alias] lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --decorate --pretty=oneline --abbrev-commit --all [color] branch = auto diff = auto interactive = auto status = auto http://blog.kfish.org/2010/04/git-lola.html
Git Golf, Git Kata あるいは Git-99 - @kyanny's blog
今日の #shibuyarblunch で「詰めvi のような git の練習問題が欲しい」という話で盛り上がった。正解の操作をなぞる -> 詰めvi -> 手数を競う？ -> Code Golf だ！という流れで Git Golf と呼んでいたけど、競技性は重要ではないし、 Code Kata に例えたほうが適切なのかもしれない。あるいは L-99 か。 レポジトリと「トピックブランチをマージせよ」のようなお題が与えられて、指示を満たすように git の各種コマンドを使ってレポジトリをいじる。操作の練習が目的なので、答え合わせは適当でいい。 git log --graph の結果を見比べる、とか。最初は簡単なのからはじめて、徐々に難しくなっていく。あまりお目にかからないシチュエーションのお題で、そうそう使わないようなコマンドを使う、組み合わせる、など。 バージョン管理システムはプログラミ
Git のおさらい - 今日も適当ダイアリー
8/21（日）にタイレルシステムズさんに会場提供いただいて行われた TDDBC Tokyo 1.7 for PHP に参加してきました。 参加登録に出遅れ補欠だったのですが、@shishi4tw さんから、 LT してくださる方を 1 名補欠の方の中から募集します。LT してくださる方は LT 枠として、本編にも参加していただけるようにします。題材は広く PHP や TDD に関することなら何でも良い、つまり、開発に関することなら何でも良い、とします。 との言葉をいただき、参加したかったので、LT表明をして参加させていただけることになりました。 そこで、「Gitのおさらい」というLTをしてきましたので、その内容をまとめておきます。 なお、勉強会本編の感想は別記事でアップする予定です。 下にあるスライドと併せてお読みください Git 「ぎっと」と読みます バージョン管理システムの一つ CVS
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
master ブランチで pull request してもいいのは覚悟のあるヤツだけ - ヤルキデナイズドだった
GitHubへpull requestする際のベストプラクティス master ブランチで pull request していいのは小学生までってこともない このへん読んでて思ったことです。 master から pull request して reject されたとしましょう。この master は上流の master と食い違ったままになります。 しかし、自分のブランチと上流の同名のブランチは一致しているか、自分のブランチのほうが進んでいる状態にあると面倒事がなくて好ましいです。食い違った master をふたたび一致させる手段は2つ： さらに master を変更して再度 pull request し、どうにか merge してもらう master に変更を加える前のコミットを強制的に push し、 master のコミットをなかったことにする 1つ目の手を取るなら、なんとしても pu
hub - git with github
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Top 10 Git Tutorials for Beginners
President of WebFX. Bill has over 25 years of experience in the Internet marketing industry specializing in SEO, UX, information architecture, marketing automation and more. William’s background in scientific computing and education from Shippensburg and MIT provided the foundation for MarketingCloudFX and other key research and development projects at WebFX. As a web designer or web developer, yo
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Introduction
DVCS談議
Pengeluaran HK: Keluaran HK, Result HK, Data HK, Togel Hongkong Hari Ini 2022
Contributing Code — Societo
Gitのおさらい
kuroigamen.com
http://blog.yuku-t.com/entry/20110625/1309004464
