Popular git config options
Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options to set? Right now
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
異なるgitリポジトリ間でもcherry-pickはできる - Qiita
git cherry-pickは異なるリポジトリ間でも使える。 なんとなく似てるコードがいろんなリポジトリにある。。。残念な状況だけど。 そんなとき点在している同じコードに問題が見つかったら一生懸命修正して回ることになるけど、ちょっとでも楽したい。 （修正を導入したいリポジトリ内で） git remote add FIXED_REPO {すでに修正を導入したリポジトリのURL} git fetch FIXED_REPO git cherry-pick {FIXED_REPO上のコミットのSHA1} git push origin master （最初に修正を導入したリポジトリ内で） git remote add TO_FIX_REPO {これから修正を導入したいリポジトリのURL} git fetch TO_FIX_REPO git checkout -b TO_FIX_REPO-mast
GitUML
Understanding source code is every programmer's biggest challenge GitUML helps programmers understand new code more quickly. Understand code quickly Rapidly generate diagrams from programming source code. Diagrams from git repositories - automatic diagram updates when you push! Upload source code files Live UML Fiddle converts source code into UML as you type UML Fiddle (Python) UML Fiddle (Javasc
Highlights from Git 2.23
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
GithubでのWeb上からのマージの仕方3種とその使いどころ - Qiita
GithubでWebのGUIからマージしようとすると「Create a merge commit」、「Rebase and merge」、「Squash and merge」の選択肢があります。この記事では、それぞれのマージの動作の違いと使いどころをまとめました。 GithubのWebからのマージ GithubでPull requestをいただいてマージしようとすると以下の3種類が表示されます。 Create a merge commit Rebase and merge Squash and merge この動作の違いをまとめました。 前提 説明するに当たりマージする前の状態を以下の状態として進めていきます。これはAのリポジトリからBがforkして、2つコミットした後にAにPull requestを出して、取り込まれるのを待っている状態だと思ってください。 また、BがY、Zの変更をしてい
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 する際には
tigで見ているコミットをgithubで開く - Qiita
bind main G !@hub browse -- commit/%(commit) bind diff G !@hub browse -- commit/%(commit) 上を~/.tigrcに書いておけば，tig起動中にGを押したとき，選択されているコミットに対応したgithubのコミットページをブラウザで開いてくれる．hubコマンドについてはGitHubユーザーのためのhubコマンド - Qiitaの記事をどうぞ． デフォルトではGはgit gcに割り当てられていて意味がわからない(たまに間違えて押してしまう)ので潰しておく． !@hubの@は出力を捨てる(つまりtigの再描画を避ける)意味がある． 参考 tig/tigrc.5.txt at master · jonas/tig
クソ簡単にgitの説明をする
どこもかしこも妙ちくりんな図で混乱させてくるのうざい 自分で書いてみる gitなんてクソ難しいんだから、きちんと概念を理解させようとかすんなよ なぜgitが必要かバージョン管理のために必要、と言うと意味わからんと思う プログラムみたいなのは少しずつ変更していくんだ だから細かに変更の差分を管理したり、変更を戻せたりしなきゃきつい なぜgitか？他のバージョン管理との違いうるせぇgit使え そんなの来年考えろ gitの基本要素、用語branch： いきなり説明が難しいが、branchがわかればどうにかなる。 例えば、今編集しているプログラムに対して、RPGのセーブデータがあると思ってほしい。 それぞれのセーブデータがそれぞれのブランチにあたる。 セーブデータが1枠しか無いと、難しいだろ？何があるかわからない、戻ったり、試したりしたいからな。 セーブデータと少し違うのは、1個のブランチでも過去
gitのmerge --no-ff のススメ - Qiita
2015年も終わりになって、gitの基本的な使い方の話に更なる需要があるとは思っていないのですが 本日が私のAdventCalender担当日であることと、本日偶然遭遇したトラブルの都合上、もしかしたらまだ需要が微レ存かもしれないと思い記事を書いていきたいと思います。 まとめ 皆しとくといい。 git のデフォルト設定はどうなっているか gitはデフォルトではmergeコマンドを使った際に、mergeコミットを発生させる必要がない場合mergeコミットを発生せずにmergeを行うfast-forwardでのmergeを行うようになっている。 --no-ffというオプションを付けることで意図的にfast-forwardを行わないコミットをすることが出来る。 どういうトラブルが起こるか 仮にmasterにtopicAブランチをmergeしたとする。 fast-forwardであるmergeの場
Gitの最初のコミットは空コミットにしよう
# リポジトリ作成 git init # 最初のコミット git commit --allow-empty -m "first commit" 解説 Gitの最初のコミットを修正したいとなると以下のようなことをする必要がある git commit --amend で最初のコミットを修正する(コメントで教えてもらいました!) この方法なら楽にできますね git rebase -i --rootでrebaseする git update-ref -dで参照を更新する 参照 First commit が git rebase -i できない問題 → git rebase -i --root でできる 初回のコミットを取り消したいときにはgit update-refを使う 上記のよう面倒くさいので first commit は空コミットにしておくと良い。 こうすることで2回目以降が本質的に意味のある
git reset --hardした内容を取り消す (git reset --hard, reflog, HEAD@{x}, 取り消してしまったコミットを元に戻す) - いろいろ備忘録日記
相変わらずGit勉強中です。 以下自分用のメモです。 特定のコミット自体をなかったことにするには git reset --hard ... を利用すればいいのですが、このコマンドはhardとオプションが ついているように、コミット自体が無かったことになってしまいます。 なので、間違えて違うコミットの部分にresetしてしまうと ｱﾜﾜﾜな事になります。（というか、なりましたｗ） でも、さすがgitさん。当然元に戻す方法がありました。 reflogを使って、元に戻せます。 元に戻す場合に利用するコマンドも git reset --hard です。 git reset --hard "HEAD@{x}" xの部分には、reflogの番号が入ります。 通常元に戻す場合は、"HEAD@{1}"になると思います。 # 試すためのブランチつくって切り替え git checkout -b test-br
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - Nutlope/aicommits: A CLI that writes your git commit messages for you with AI
GitHub - sheepla/pingu: 🐧ping command but with pingu
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25
merge commitをcherry-pickする - Qiita
github/gitignore at master - GitHub
Github pages に 特定のディレクトリだけデプロイする - Qiita
GitHub Flow (Japanese translation)
