君には1時間でGitについて知ってもらう(with VSCode) - Qiita
おことわり この記事はプログラミング＆業務未経験の新入社員に、Gitについて1時間程度で説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達することはできませんが、今後Gitを使う必要がある人にとって学習の足がかりになれば幸いです。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って頂きます。 Windowsでの説明を行いますが、Macの方は適宜読み替
Gitの良さが分からない？ ちょっとそこに座れ | To Be Decided
Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。) 本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
モノリシックなバージョン管理の利点 | POSTD
以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ：git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
Subversionを使用し続けているプロジェクトがGitに移行することを考えてみた - Qiita
このページについて 中央集権型バージョン管理のCVSとSVN、分散バージョン管理のGit両方を各プロジェクトで使用してきた経験から、新規開発、保守開発でSVNを使用し続けているプロジェクトがGitを使うメリットについて考えて書いてみるページです。 あくまでも経験を下に主観で書いていきますので、いやいやその考え方は間違っているよ！とか、これも書いといて！というのがあれば、コメントやら編集リクエストなどください。 想定読者 Gitを使ってみたいけど、保守開発だからSVNからGitに乗り換えるのなんて無理だよ！と半ば諦めている方 SVNからGitに乗り換える提案をしたいから、乗り換えることで生じるメリット・デメリットが知りたいよ！という方 うちはSVNで構成管理をしてきたんだ！Gitなんか誰も使ったことないから何かあったら誰が責任取ってくれるんだ！と使用を許してくれない上司を説得したいという方
これまで知らなかったGit機能を調べたまとめ - Qiita
変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch commit-v # You are currently bisecting, started from branch 'test-git-bisect'. # # Changes to be committed: #>modified: fruits.txt # # -------
[新人教育] 何も知らない人がGitとGitHubを独学で知る - Qiita
一通りやりましたがめちゃオススメです。 画面の指示に従って進めていくだけで Gitの概念からプルリクエストのフローまで学べます。 ※実際にプルリクエストを送ることができます。 ※章末ごとに正しく操作できているかのチェック機能があります。 所要時間は、Git使い慣れてる人で1時間未満。 未経験者でも3時間あればなんとか！(ハマり具合による) Git・GitHub始めたばかりの人から復習したい人まで！ また、研修でも使えると思います。 日本語版も出来たみたいですのでぜひお試しあれ！ ...と勝手に宣伝。 [git-it-electron(概要)] https://github.com/jlord/git-it-electron#user-content-git-it-desktop-version [ダウンロードページ(日本語版)] https://github.com/jlord/git-i
![[新人教育] 何も知らない人がGitとGitHubを独学で知る - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4d82e6a6e6fca5cf7fbdaf994ac8ef11637763f/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU2JTk2JUIwJUU0JUJBJUJBJUU2JTk1JTk5JUU4JTgyJUIyJTVEJTIwJUU0JUJEJTk1JUUzJTgyJTgyJUU3JTlGJUE1JUUzJTgyJTg5JUUzJTgxJUFBJUUzJTgxJTg0JUU0JUJBJUJBJUUzJTgxJThDR2l0JUUzJTgxJUE4R2l0SHViJUUzJTgyJTkyJUU3JThCJUFDJUU1JUFEJUE2JUUzJTgxJUE3JUU3JTlGJUE1JUUzJTgyJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1kOGJlZmViOWQ0MDQ4MDcxYzE5NTJlNzU1NWM4ZTk2Ng%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBpa2VuamkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTdjNDNjNTJlMjExZjZlY2IxMGQyMzM5NGZkZmQ3ZWUw%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gZ2lmdGVl%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Da21fc58da4a14ff468039b5829ff4e02)
新人さんにより良いコミットメッセージを書いてもらうための対話式スクリプト - Qiita
作ったもの コミット時に対話式で質問を表示させるものをつくりました。 ↓こんな感じ↓ 回答の内容をつなげたものがコミットメッセージになります。 質問リストは別のファイルで自由に設定できるので、 チーム内でコミットメッセージへ書いて欲しい内容をゆるく共有したい場合に。 How to use スクリプト本体はこちら #!/bin/sh set -e # core.editorに設定したいもの # merge,rebaseなどの時に起動する CORE_EDITOR=vi # commitじゃなかった場合(mergeとかrebaseとか)の場合はCORE_EDITORに渡す if [[ ! "$1" = *COMMIT_EDITMSG ]]; then $CORE_EDITOR $1 exit 0 fi CURRENT_DIR=$(cd $(dirname $0); pwd) MSGLIST_FI
開発現場で使える管理システム「Git」をモチーフにしたRPG「ギットクエスト」が入門に最適だと話題に
Webやソフトウェアの開発現場でソースコードなどの変更履歴を記録するバージョン管理システム「Git」。これをモチーフにしたユニークなRPG「ギットクエスト」が登場しました。PCやスマホのWebブラウザから無料でプレイできます。 ギットクエスト サブバー村に巨大なドラゴンの姿をした敵「並行開発」が襲ってくるところから冒険がスタート。あっけなく敗れてしまったレベル1のプログラマーである主人公は、「Subversionでは限界」と言われ、Gitを学ぶためにGit学園へと向かいます。のっけからRPGの雰囲気に似合わない専門用語がガンガン飛び出すシュールな世界観がさく裂しています。 巨大なドラゴン「並行開発」が出現 とんでもなく強い サブバー村の「Subversion」では限界らしくGitを学ぶことに Git学園でのチュートリアルや登場人物たちとの会話では、妙に本格的なGitの知識が学べます。それら
SVNを捨ててGitを使うべき5つの理由 - Qiita
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです（たぶん）。 それが今で
GitHub おじさん スターターキット - Qiita
この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する機会が多いので、その経験から、どんなことに注意しながら進めていけばいいか書いてみます。 記事は 「紹介編」,「導入後編」,「おじさん編」の３つの編から構成されています。 紹介編 Git はバージョン管理ツール、 GitHub は Git のホスティングサービ
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は怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Flow (Japanese translation)
