はじめに GitHubのページを見ながら、GitHub PagesによるHello Worldページを作成したい。 手順 新しいレポジトリ作成 GitHubで「Create a new repository」ページでRepository nameを{ユーザ名}.github.ioを入力する。 レポジトリをクローン 今回はMacのTerminalで行うこととする。 ページでは該当のフォルダーでgit clone https://github.com/{ユーザ名}/{ユーザ名}.github.ioでクローンするということだが、remote: Repository not found.エラーが出た。 SouceTreeでCloneしたらremote: Repository not found.となった時の対応方法によると、上記エラーの原因がユーザー名とパスワードを入力しないと認証できないためらしい。 上記エラーが出たら、下記コマンドでクローンする。 $ git clone https://{ユーザ名}:{パスワード}@github.com/{ユーザ名}/{ユーザ名}.github.io.git Hello World 該当ディレクトリで、index.htmlを作成。 $ cd {ユーザ名}.github.io $ echo "Hello World" > index.html プッシュする Gitの一連のコマンドを入力。 $ git add --all $ git commit -m "Initial commit" $ git push -u origin master ブラウザで確認 https://{ユーザ名}.github.io 上記URLで「Hello World」できているか確認する。
GitHubのページを見ながら、GitHub PagesによるHello Worldページを作成したい。
GitHubで「Create a new repository」ページでRepository nameを{ユーザ名}.github.ioを入力する。
今回はMacのTerminalで行うこととする。 ページでは該当のフォルダーでgit clone https://github.com/{ユーザ名}/{ユーザ名}.github.ioでクローンするということだが、remote: Repository not found.エラーが出た。
git clone https://github.com/{ユーザ名}/{ユーザ名}.github.io
remote: Repository not found.
SouceTreeでCloneしたらremote: Repository not found.となった時の対応方法によると、上記エラーの原因がユーザー名とパスワードを入力しないと認証できないためらしい。 上記エラーが出たら、下記コマンドでクローンする。
$ git clone https://{ユーザ名}:{パスワード}@github.com/{ユーザ名}/{ユーザ名}.github.io.git
該当ディレクトリで、index.htmlを作成。
$ cd {ユーザ名}.github.io $ echo "Hello World" > index.html
Gitの一連のコマンドを入力。
$ git add --all $ git commit -m "Initial commit" $ git push -u origin master
https://{ユーザ名}.github.io 上記URLで「Hello World」できているか確認する。
Gitではユーザー名とメールアドレスが、コミットのログなどに記録されます。 ユーザー名とメールアドレスを確認するには、以下のコマンドを使います。 $ git config user.name $ git config user.email ユーザー名とメールアドレスを設定するには、以下のコマンドを使います。 $ git config --global user.name "Your Name" $ git config --global user.email "your.mail.account@gmail.com" --globalオプションは、ユーザごとの設定を行う ~/.gitconfig ファイルに対して、値を設定するという意味です。
Gitではユーザー名とメールアドレスが、コミットのログなどに記録されます。
ユーザー名とメールアドレスを確認するには、以下のコマンドを使います。
$ git config user.name $ git config user.email
ユーザー名とメールアドレスを設定するには、以下のコマンドを使います。
$ git config --global user.name "Your Name" $ git config --global user.email "your.mail.account@gmail.com"
--globalオプションは、ユーザごとの設定を行う ~/.gitconfig ファイルに対して、値を設定するという意味です。
はじめに mac osを使ってチーム開発をしています。 備忘録も兼ねております。 初心者のため、間違い等あれば教えていただけますと幸いです。 マージできない コードレビューでLGTMをもらい、さあ初めてのマージをするぞ！ と思ったらmerge pull requestが押せない… app/.DS_Storeという記述が出ているけどそんなファイルどこにもない… 解決法 カレントディレクトリで以下の作業をする 1.ファイルを検索 $ find ./ \( -name ".DS_Store" -or -name "._*" \) 2.ファイルを削除 $ find ./ \( -name ".DS_Store" -or -name "._*" \) | xargs rm -rf 3..gitignoreに記述を追加 .DS_Store これでmerge pull requestが押せるようになるのと、 .DS_Storeがgitの管理下に入らなくなります。
mac osを使ってチーム開発をしています。 備忘録も兼ねております。 初心者のため、間違い等あれば教えていただけますと幸いです。
コードレビューでLGTMをもらい、さあ初めてのマージをするぞ！ と思ったらmerge pull requestが押せない… app/.DS_Storeという記述が出ているけどそんなファイルどこにもない…
merge pull request
app/.DS_Store
カレントディレクトリで以下の作業をする
1.ファイルを検索
$ find ./ \( -name ".DS_Store" -or -name "._*" \)
2.ファイルを削除
$ find ./ \( -name ".DS_Store" -or -name "._*" \) | xargs rm -rf
3..gitignoreに記述を追加
.gitignore
.DS_Store
これでmerge pull requestが押せるようになるのと、 .DS_Storeがgitの管理下に入らなくなります。
自分用のメモとして残します。 ■やり方 コミットの移動（コピー） 1.移動したいコミットRevを確認する。 移動したいコミットがあるブランチをチェックアウトしてコミットRevを確認してFrom~Toを控える。 git checkout 移動したいコミットRev群があるブランチ名 git log --oneline 何故か、ここで確認したはコミットRevじゃないとcherry-pickできないみたい(; ･`д･´) 2.コミットの移動先ブランチをチェックアウト git checkout 移動先ブランチ名 3.コミットをコピー 1で確認したFromToのコミットRevを指定 git cherry-pick ＦＲＯＭコミットRev^..ＴＯコミットRev ＦＲＯＭコミットRev^の ^ はＦＲＯＭコミットRev含むという意味です。 4.コピーまでの情報をリモートに反映する。 git push 移動して不要になったコピー元コミットを削除する 5.コピー元コミットがあるブランチをチェックアウト git checkout コピー元コミットがあるブランチ名 6.コミット削除 下記の例はブランチのHeadから3つ前まで履歴を削除するという例です。 git reset --hard HEAD~3 つまり、headを含む2つのコミットをコピーした場合は 上記のように3つ前をそのブランチのHeadとするということになると思います。 7.コピー元コミット削除をリモートに反映する。 git push -f origin ブランチ名 以上。
自分用のメモとして残します。
移動したいコミットがあるブランチをチェックアウトしてコミットRevを確認してFrom~Toを控える。
git checkout 移動したいコミットRev群があるブランチ名 git log --oneline
何故か、ここで確認したはコミットRevじゃないとcherry-pickできないみたい(; ･`д･´)
git checkout 移動先ブランチ名
1で確認したFromToのコミットRevを指定
git cherry-pick ＦＲＯＭコミットRev^..ＴＯコミットRev
ＦＲＯＭコミットRev^の ^ はＦＲＯＭコミットRev含むという意味です。
^
git push
git checkout コピー元コミットがあるブランチ名
下記の例はブランチのHeadから3つ前まで履歴を削除するという例です。
git reset --hard HEAD~3
つまり、headを含む2つのコミットをコピーした場合は 上記のように3つ前をそのブランチのHeadとするということになると思います。
git push -f origin ブランチ名
以上。
３月から独学で勉強し続けて、最近やっとgitをチーム開発で扱うようになれたので、 もし自分が最初からgitを勉強しなおすとしたらどういう手順でやれば覚えやすいか、 抵抗感なく取り組めるかを記事に残しておこうと思ったのと、 初心者に教える予定のある方にどうやって理解したか聞かれたのがきっかけでこの記事を書くに至りました。 はじめに 学習したてのころは、gitとGithubってあるけど、 どうして二つも名前があるの？と疑問にすら思いませんでしたが、 完全に別物であるということを理解した上でgitの学習に取り組んだ方が スムーズではないかと思います。 なのでざっくりでいいので概要を知り、二つの違いを知り、gitの重要性を知ってもらった上で、 実際に触るといった方が頭に入ってくると思います。 Gitってなあに？ GitとGithubの違い どうして履歴を管理するの？ まずは一人でGitを使ってGithubにデータを上げてみましょう！ ブランチを切るということを覚えよう！ 今度は二人以上で練習をしてみよう！ コンフリクト解消まで一通りできるようになってみよう！ というような目次の流れで紹介しようと思います。 ■使用教材のおすすめ サル先生のGit入門 https://backlog.com/ja/git-tutorial/ progate（有料） https://prog-8.com/languages/git チュートリアル（中級者向け） http://k.swd.cc/learnGitBranching-ja/ 1.Gitってなぁに？ https://blog.sixapart.jp/2014-03/mttips-02-what-is-git.html Gitとは、プログラムのコードの変更履歴を管理する分散型のバージョン管理システムのことです。 分散型、難しそうな言葉が出てきました。 https://wa3.i-3-i.info/word12358.html わかりそうでわからないによると‥分散型のシステムとは、 システムの分類の一つであり、 やるべきお仕事を複数のコンピュータで分担してやる形態になっているシステムのこと。 分散型の何がいいの？ 分散システムのメリットは、チームプレーのメリットと同じです。 1. みんなで分担できるので、一人ひとりの負担が小さい 2. 仲間を増やせば、いろんなことができる 3. ケガをしても影響範囲が限定的 デメリットは 大人数でわちゃわちゃしているので管理が大変という事くらいです。 はい、ここまでで分散型のシステムについては理解が出来たかと思います。 バージョンってなあに？ 説明しろといわれたら、知ってるようで知らないなぁと思う人もいると思います。 https://wa3.i-3-i.info/word11073.html バージョンは、そいつの年齢みたいなものです。 変更前のやつと区別するために着ける数字や文字のことです。 まとめるとつまり何なの？ 絵で例えますね。壁画などを想像してください。 膨大な線や色を、いろんな人で手分けして、 線を加えていき、段階的に色をどんどん塗り重ねていき、その塗られた状態（レイヤ）の履歴を 監督さんが管理しているんですね。 手戻りしたいよ～って時に監督さんに言うと、戻してくれたりします。 その監督がGitです。 プログラムのコードを複数人で作業し、その履歴を管理するのがGit。 これが分散型のバージョン管理システムというわけです。 ふわっとでもつかめて頂けると嬉しいです。 GitとGithubの違い。 Githubって何よ？ このGitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデザインデータなど)を保存、公開することができるようにしたウェブサービスの名称です。 GitHubはGitHub社という会社によって運営されており、 個人・企業問わず無料で利用することができます。 GitHubに作成されたレポジトリは、基本的にすべて公開されますが、有料サービスを利用すると、 指定したユーザーからしかアクセスができないプライベートなレポジトリを作ったりすることができます。 レポジトリという言葉が出てきました。 リポジトリレポジトリという言われ方がしますが二つは同じ意味です。 リポジトリは、プログラムなり設定情報なり、何等かの「保管場所」を カッコつけていった表現です。 リポジトリという言葉が出てきたら、保管場所なんだなあと思ってください。 GitとGithubの違いは Gitは管理システムで、Githubは「それをみんなでシェアできたらいいね！」というサービスです。 どうしてバージョン管理をするの？ 詳しくはこちらの記事がおすすめです。 https://qiita.com/MasayaMizuhara/items/9503eb66d3125d8c5f41 １．以前の状態に戻る 間違えちゃった！というときは当然元に戻したいですよね。 バージョン管理ができるから、手戻りが可能になるんですよね。 ２．変更履歴を調査する せっかくここまで作ったのに１から作り直しかぁ‥ なんて経験をしたときはありませんか？ ある地点からやり直しが出来たら楽ちんですよね。 共同で誰かと何かを作っているとしてその人のやってる作業を、ずっと監視はできません。 バージョン管理システムでは、その誰かが「何をどう」変えたかがわかるわけです。 変更された各場所を確認して、「おっそこは違うよ！」と思えば、 そこだけを取り消したり、な～んてことも出来るようになるわけですね！ 便利ですね！ ３．プロジェクトを管理する、４．変更者と変更理由を知る プロジェクト開発においてはファイルは一つではありませんよね。 複数のファイルやディレクトリが重なって一つのプロジェクトとなるわけです。 例えば、あるプロジェクトで問題が起こったとしましょう。 A君が任されたファイルの中に書いた一文、 例えば system.out.println('こんにちは'); この文章が実は「こんにちは」ではなく「こんばんは」としたかった時に、 何も言わずに変えてしまっては、A君に何を変えたの！？といちいち聞かなくてはなりません。 それは面倒なのでＡ君は "「こんにちは」から「こんばんは」に出力文字を変更しました。" などを記録に残しておけば、Ａ君の上司は ほうほう、ここ変更したのね、と知れるわけです。 まとめ ・以前の状態に戻る ・変更履歴を調査する ・プロジェクトを管理する ・変更者と変更理由を知る これがバージョン管理をするための目的です。 まずは一人でGitを使ってGithubにデータを上げてみましょう！ ここで、やっとおすすめの教材の登場です。 https://backlog.com/ja/git-tutorial/intro/01/ こちらのGitの基本を読んでみましょう。 ふわっと概要を理解したあなたなら、 「ふむふむ、そういうことね」とすらすら読めると思います。 一通りサル先生を読み終わったら次は実際に手を動かしてみましょう。 ここでやっとコードに触れてもらいます。長かったですね。 はいここで、progateさんに登場して頂きます。 ここでgit init～git pushまでが出来れば、一人でGitにデータを上げるということはできたと言っても過言ではないでしょう。 以下おそらく出てくるであろうコマンド git init git add . git status git commit -m "index.htmlにheaderを追加しました" git push -u origin master コマンドの説明はprogateさんに預けます。笑 リポジトリにpush（ファイルを上げる） リポジトリからクローン（ファイルをローカル上に複製する） リモートリポジトリからプルする（ファイルの内容をリポジトリからそのまま上書きする） ここまで出来れば一人でGitが使えるようになっています。 ブランチを切るということを覚えよう！ ブランチとは ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。 その名の通り枝です。 あまり自分は覚えてはいないのですが、 progateでこんなコマンド出てきませんでしたか？ git branch git checkout -b feature/add-header-logo progateさんを非難するわけではありませんが、一人で上げるということを教えてくれましたが、 二人以上のgit操作にはあまり触れてくれていません。 共同開発となるとまた話が変わってきます。 共同開発において、 masterにいきなりpushしてはいけません 大事なことなのでもう一度言います。 masterにいきなりpushしてはいけません。 なんで～？って思いますよね。 共同開発におけるmasterブランチとは、成果品をつくる上流工程のことです。 たとえ話です、あなたが子供に料理をてつだってもらっているとします。 あなたはカレーを作りたいとしましょう。 カレーを作るのにも工程がありますね。 野菜を切る→野菜を鍋にいれる→野菜を煮込む（または炒める？）→ルー溶かし茹でる→完成！ マスターはこの全ての工程を管理してカレーを完成させます。 あなたはそれぞれの子供に作業を分担しています。 ・野菜を切るかかりの子供（cut） ・野菜を鍋に入れるかかりの子供（through） ・みんながちゃんとできてるか確認する係の子供(attend) （（）内をブランチ名としますね。） この子供たちがそれぞれのブランチです。 確認係は当然野菜を切るかかりの子供を待っていますが、 野菜を鍋に入れるかかりの子供はわからずに、 切る前のそのままのにんじんをなべに放り込もうとしました。 確認係は止めるわけです。 「いきなり鍋に入れちゃダメだよ～」 野菜を切るかかりの子供が野菜を切れてるか確認してもらい、 それがOKなら野菜を鍋に入れるということが出来るようになります。 雰囲気だけでも伝わりましたでしょうか？ https://backlog.com/ja/git-tutorial/stepup/01/ サル先生にもう一度登場して頂きましょう。 この枝の図が分かりやすいです。 マスターから分岐し、それぞれの工程が終わったうえで再度マスターに合流しています。 ブランチを切ることが何となくお分かりになってくれていると嬉しいです。 6. 今度は二人以上で練習をしてみよう！ これは自分以外にもう一人登場人物が必要になってくるのですこし難しいのですが、 どうしてもという方はアカウントをもう一つつくって実際にやってみると分かりやすいかと思います。 マスターブランチと、デベロップブランチに分かれてやってみましょう。 ファイルは何でもよいです。 ここでやる練習は ・プルリクエスト ・マージ になります。 チュートリアル http://k.swd.cc/learnGitBranching-ja/ 7.コンフリクトを解消しよう！ ここからは少し上級編になります。 のでたくさん良い記事があるので、気になる方はそちらをご覧になってください。 （短めになってしまって申し訳ないです。笑 おわりに 最後の方説明が雑になってしまいましたが、いかがでしたでしょうか。 Git、Githubの違いも理解し、二人以上での開発が出来るようになれば、 あとは細かいコマンド覚えていくだけで楽になります。 ここまで稚拙な文章を読んでいただいて有難うございました。
３月から独学で勉強し続けて、最近やっとgitをチーム開発で扱うようになれたので、 もし自分が最初からgitを勉強しなおすとしたらどういう手順でやれば覚えやすいか、 抵抗感なく取り組めるかを記事に残しておこうと思ったのと、 初心者に教える予定のある方にどうやって理解したか聞かれたのがきっかけでこの記事を書くに至りました。
学習したてのころは、gitとGithubってあるけど、 どうして二つも名前があるの？と疑問にすら思いませんでしたが、 完全に別物であるということを理解した上でgitの学習に取り組んだ方が スムーズではないかと思います。 なのでざっくりでいいので概要を知り、二つの違いを知り、gitの重要性を知ってもらった上で、 実際に触るといった方が頭に入ってくると思います。
Gitってなあに？ GitとGithubの違い どうして履歴を管理するの？ まずは一人でGitを使ってGithubにデータを上げてみましょう！ ブランチを切るということを覚えよう！ 今度は二人以上で練習をしてみよう！ コンフリクト解消まで一通りできるようになってみよう！
というような目次の流れで紹介しようと思います。
■使用教材のおすすめ サル先生のGit入門 https://backlog.com/ja/git-tutorial/
progate（有料） https://prog-8.com/languages/git
チュートリアル（中級者向け） http://k.swd.cc/learnGitBranching-ja/
https://blog.sixapart.jp/2014-03/mttips-02-what-is-git.html
Gitとは、プログラムのコードの変更履歴を管理する分散型のバージョン管理システムのことです。 分散型、難しそうな言葉が出てきました。 https://wa3.i-3-i.info/word12358.html
わかりそうでわからないによると‥分散型のシステムとは、
システムの分類の一つであり、 やるべきお仕事を複数のコンピュータで分担してやる形態になっているシステムのこと。
分散システムのメリットは、チームプレーのメリットと同じです。 1. みんなで分担できるので、一人ひとりの負担が小さい 2. 仲間を増やせば、いろんなことができる 3. ケガをしても影響範囲が限定的
デメリットは 大人数でわちゃわちゃしているので管理が大変という事くらいです。
はい、ここまでで分散型のシステムについては理解が出来たかと思います。
説明しろといわれたら、知ってるようで知らないなぁと思う人もいると思います。 https://wa3.i-3-i.info/word11073.html バージョンは、そいつの年齢みたいなものです。 変更前のやつと区別するために着ける数字や文字のことです。
絵で例えますね。壁画などを想像してください。 膨大な線や色を、いろんな人で手分けして、 線を加えていき、段階的に色をどんどん塗り重ねていき、その塗られた状態（レイヤ）の履歴を 監督さんが管理しているんですね。 手戻りしたいよ～って時に監督さんに言うと、戻してくれたりします。 その監督がGitです。
プログラムのコードを複数人で作業し、その履歴を管理するのがGit。 これが分散型のバージョン管理システムというわけです。 ふわっとでもつかめて頂けると嬉しいです。
このGitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデザインデータなど)を保存、公開することができるようにしたウェブサービスの名称です。
GitHubはGitHub社という会社によって運営されており、 個人・企業問わず無料で利用することができます。
GitHubに作成されたレポジトリは、基本的にすべて公開されますが、有料サービスを利用すると、 指定したユーザーからしかアクセスができないプライベートなレポジトリを作ったりすることができます。
レポジトリという言葉が出てきました。 リポジトリレポジトリという言われ方がしますが二つは同じ意味です。
リポジトリは、プログラムなり設定情報なり、何等かの「保管場所」を カッコつけていった表現です。
リポジトリという言葉が出てきたら、保管場所なんだなあと思ってください。
Gitは管理システムで、Githubは「それをみんなでシェアできたらいいね！」というサービスです。
詳しくはこちらの記事がおすすめです。 https://qiita.com/MasayaMizuhara/items/9503eb66d3125d8c5f41
１．以前の状態に戻る 間違えちゃった！というときは当然元に戻したいですよね。 バージョン管理ができるから、手戻りが可能になるんですよね。
２．変更履歴を調査する せっかくここまで作ったのに１から作り直しかぁ‥ なんて経験をしたときはありませんか？ ある地点からやり直しが出来たら楽ちんですよね。
共同で誰かと何かを作っているとしてその人のやってる作業を、ずっと監視はできません。 バージョン管理システムでは、その誰かが「何をどう」変えたかがわかるわけです。 変更された各場所を確認して、「おっそこは違うよ！」と思えば、 そこだけを取り消したり、な～んてことも出来るようになるわけですね！ 便利ですね！
３．プロジェクトを管理する、４．変更者と変更理由を知る プロジェクト開発においてはファイルは一つではありませんよね。 複数のファイルやディレクトリが重なって一つのプロジェクトとなるわけです。
例えば、あるプロジェクトで問題が起こったとしましょう。 A君が任されたファイルの中に書いた一文、
例えば
system.out.println('こんにちは');
この文章が実は「こんにちは」ではなく「こんばんは」としたかった時に、 何も言わずに変えてしまっては、A君に何を変えたの！？といちいち聞かなくてはなりません。 それは面倒なのでＡ君は
"「こんにちは」から「こんばんは」に出力文字を変更しました。"
などを記録に残しておけば、Ａ君の上司は ほうほう、ここ変更したのね、と知れるわけです。
・以前の状態に戻る ・変更履歴を調査する ・プロジェクトを管理する ・変更者と変更理由を知る
これがバージョン管理をするための目的です。
ここで、やっとおすすめの教材の登場です。 https://backlog.com/ja/git-tutorial/intro/01/
こちらのGitの基本を読んでみましょう。 ふわっと概要を理解したあなたなら、 「ふむふむ、そういうことね」とすらすら読めると思います。
一通りサル先生を読み終わったら次は実際に手を動かしてみましょう。 ここでやっとコードに触れてもらいます。長かったですね。 はいここで、progateさんに登場して頂きます。
ここでgit init～git pushまでが出来れば、一人でGitにデータを上げるということはできたと言っても過言ではないでしょう。
以下おそらく出てくるであろうコマンド
git init git add . git status git commit -m "index.htmlにheaderを追加しました" git push -u origin master
コマンドの説明はprogateさんに預けます。笑
リポジトリにpush（ファイルを上げる） リポジトリからクローン（ファイルをローカル上に複製する） リモートリポジトリからプルする（ファイルの内容をリポジトリからそのまま上書きする）
ここまで出来れば一人でGitが使えるようになっています。
ブランチとは ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。
その名の通り枝です。
あまり自分は覚えてはいないのですが、 progateでこんなコマンド出てきませんでしたか？
git branch git checkout -b feature/add-header-logo
progateさんを非難するわけではありませんが、一人で上げるということを教えてくれましたが、 二人以上のgit操作にはあまり触れてくれていません。 共同開発となるとまた話が変わってきます。
共同開発において、 masterにいきなりpushしてはいけません
大事なことなのでもう一度言います。 masterにいきなりpushしてはいけません。
なんで～？って思いますよね。
共同開発におけるmasterブランチとは、成果品をつくる上流工程のことです。 たとえ話です、あなたが子供に料理をてつだってもらっているとします。 あなたはカレーを作りたいとしましょう。 カレーを作るのにも工程がありますね。 野菜を切る→野菜を鍋にいれる→野菜を煮込む（または炒める？）→ルー溶かし茹でる→完成！ マスターはこの全ての工程を管理してカレーを完成させます。
あなたはそれぞれの子供に作業を分担しています。 ・野菜を切るかかりの子供（cut） ・野菜を鍋に入れるかかりの子供（through） ・みんながちゃんとできてるか確認する係の子供(attend) （（）内をブランチ名としますね。） この子供たちがそれぞれのブランチです。
確認係は当然野菜を切るかかりの子供を待っていますが、 野菜を鍋に入れるかかりの子供はわからずに、 切る前のそのままのにんじんをなべに放り込もうとしました。 確認係は止めるわけです。 「いきなり鍋に入れちゃダメだよ～」
野菜を切るかかりの子供が野菜を切れてるか確認してもらい、 それがOKなら野菜を鍋に入れるということが出来るようになります。 雰囲気だけでも伝わりましたでしょうか？
https://backlog.com/ja/git-tutorial/stepup/01/ サル先生にもう一度登場して頂きましょう。
この枝の図が分かりやすいです。 マスターから分岐し、それぞれの工程が終わったうえで再度マスターに合流しています。
ブランチを切ることが何となくお分かりになってくれていると嬉しいです。
これは自分以外にもう一人登場人物が必要になってくるのですこし難しいのですが、 どうしてもという方はアカウントをもう一つつくって実際にやってみると分かりやすいかと思います。
マスターブランチと、デベロップブランチに分かれてやってみましょう。 ファイルは何でもよいです。
ここでやる練習は ・プルリクエスト ・マージ になります。
チュートリアル http://k.swd.cc/learnGitBranching-ja/
ここからは少し上級編になります。 のでたくさん良い記事があるので、気になる方はそちらをご覧になってください。 （短めになってしまって申し訳ないです。笑
最後の方説明が雑になってしまいましたが、いかがでしたでしょうか。 Git、Githubの違いも理解し、二人以上での開発が出来るようになれば、 あとは細かいコマンド覚えていくだけで楽になります。
ここまで稚拙な文章を読んでいただいて有難うございました。
git logで以下のようなログが表示されることを前提としたとき、 $ git log commit 1413718bb40c9a1ebd4ffe037f934076df4c70eb (HEAD -> master, origin/master, origin/HEAD) ... 以下のようにして最新commitのハッシュを取得する $ git log | head -1 | cut -d' ' -f 2 1413718bb40c9a1ebd4ffe037f934076df4c70eb 備考 何かもっと良い方法があるような気もする
git logで以下のようなログが表示されることを前提としたとき、
$ git log commit 1413718bb40c9a1ebd4ffe037f934076df4c70eb (HEAD -> master, origin/master, origin/HEAD) ...
以下のようにして最新commitのハッシュを取得する
$ git log | head -1 | cut -d' ' -f 2 1413718bb40c9a1ebd4ffe037f934076df4c70eb
何かもっと良い方法があるような気もする
