GitLabもデフォルトのブランチ名を「master」から「main」に変更へ、5月から
GitLabは、5月22日にリリースするGitLab 14.0以降、新規に作成されるリポジトリのデフォルトブランチ名を「master」から「main」に変更することを明らかにしました。 You spoke and we listened. We're joining the Git community and updating "master" to "main".https://t.co/V8UdjxQUBT — GitLab (@gitlab) March 10, 2021 具体的には、4月22日リリース予定のGitLab 13.11でフィーチャーフラグによってデフォルトブランチ名を「main」に変更可能にします。この時点ではまだデフォルトブランチ名は「master」のまま、フラグを切り替えたときのみデフォルトブランチ名が「main」となります。 そして5月22日にリリース予定のGit
実務でどんな git コマンドを使っているか振り返ってみる - Qiita
gitコマンドって実務でどう使うんだろう？ 独学の git コマンドを実務で使いまくり、最近やっとうまく運用できているように感じます。 そのうえで、git コマンドを勉強し始めた頃、「コマンドの説明はいっぱいあるけど、実務でどうコマンドを使うんだろう？」 と感じていたのを思い出しました。 そんな想いから、よく使う git コマンドを実務テイストで振り返ってみました。 本記事に書いていないもの 実務では使うのですが、諸事情により以下は省いています。 submodule 本当はこの記事に含めようかと思ったのですが、長くなりすぎてしまったので、需要がありそうだったら次回作に書こうかと思います。 プルリク コマンドの説明をしたいため、省きます。 Git Flow やら GitHub Flow やらの Flow 系の考え 説明がややこしくなってしまうので省きます。 developブランチ、maste
Git aliases I can't live without – Michał Konarski
People are often surprised and curious at the same time when they see how I work with Git: My Git workflow My love for aliases started when I installed zsh and its addon suite oh-my-zsh for the first time. It contains a big set of predefined aliases and helper functions for different command line programs. I immediately liked the concept of typing just few letters instead of regular, long, paramet
git push -f をやめて --force-with-lease を使おう - Qiita
force push問題 rebaseなどの作業の際、強制PUSHが必要なタイミングが出てくるが --forceではローカルの内容を破壊的にリモートレポジトリを上書きしてしまう。 同じブランチで複数人開発していた場合にタイミングによっては 「◯◯さんのコミットを吹き飛ばしちゃった//」 が発生する可能性が十分ある。 そもそも上記の運用方法に問題がある気はするが、どんな運用をしていたとしても force pushする際は --force-with-leaseオプションを必ずつけるようにしておいて損はないと思う。 TIPS: Github上でブランチを削除できないようにする 消されるとまずいブランチは [Settings] → [Branches]でさまざまなprotectionルールをかけておきましょう！
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
意外と知らない？ Gitコマンド 100本ノック - Qiita
概要 みなさん、Git使ってますか？ もしくは、使いこなしていますか？ 独習Gitを読んで、思いの外Gitコマンドが多かったので、 タイトルの通り、Gitコマンドで100本ノックをまとめてみました。 Gitの環境構築が終わっている状態からを想定しています。 git initでローカルにリポジトリを用意してください。 問題に対して、直後に回答を載せる形式にしています。 Git初心者の方も、目を通して知らないオプションをググれば勉強になると思います。 参考文献 独習Git Gitに馴染む 1. メールアドレスをGitのグローバル設定に追加 git config --global user.email "Your E-mail@example.com" 2. user.nameの設定値を表示 git config user.name 3. user.emailの設定値を表示 git config
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
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回目以降が本質的に意味のある
Mac / Windows / Linuxに対応した無料のGUI Gitクライアント「GitKraken」 | ソフトアンテナ
クロスプラットフォームのGUI Gitクライアント「GitKraken」が公開されています。現在パブリックベータテスト中で、公式サイトよりMac / Windows / Linuxに対応した実行ファイルを無料でダウンロードして使用することができます。 最近流行のElectronを使用して作成されたソフトウェアのようで、libgit2やNodeGitといったオープンソースライブラリも組み込まれています。 Electron風の美しいGUI ▼メイン画面は以下の通り。 コミット履歴やブランチの分岐が美しく表示されているのが印象的です。コミットやブランチの作成/マージ、pull/pushといったGitの操作をGUIを使って行う事ができます。 ▲設定画面を使って「git config」の設定や、sshの鍵の管理、GitHubやBitBucketといったサービスの認証情報の管理、Git Flowの設定
Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
気付いたら.gitignoreはgiboで自動生成する時代になっていた - Qiita
$ gibo --version gibo 1.0.4 by Simon Whitaker <sw@netcetera.org> https://github.com/simonwhitaker/gibo $ gibo java ### https://raw.github.com/github/gitignore/8c9b77cb5c85f6464c0bb31abdf4cfcfdf6833bb/java.gitignore *.class # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.ear # virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml hs_err_pid*
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
地震や火事など緊急時に使うgit-fireのススメ - Qiita
$ git-fire "やばい" Switched to a new branch 'fire-master-[メールアドレス]-1444060029' [fire-master-[メールアドレス]-1444060029 bc88227] @a 1 file changed, 13 insertions(+) create mode 100644 index.html Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 384 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gith
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tig操作 超簡易版 - Qiita
GitHub - git-town/git-town: Additional Git commands for easier branch management and support for stacked changes
gitでパッチを適用したい - インターネットのリソースを無駄遣いして検索におけるUXを下げてごめんなさい
GitHub、“GitHub Flow”に最適化した新しいクライアント「GitHub Desktop」を公開
