What's New Qiita

20210303のGitに関する記事は5件です。

  • 投稿日：2021-03-03T22:20:30+09:00

コミットせずに他のブランチで作業したい

シチュエーション

ある対応をしている時に別の依頼をされることは仕事ではよくあること。
現在行っている対応が、コミットするには中途半端で、
コミットせずに別の依頼の対応を行いたいときのGitのTIPSです。

git stashを使います。

手順

①　現在行っている対応（now-branch）を一時退避

$ git stash

②　別の対応のブランチに切り替え

$ git checkout other-branch

③ 止めていた対応のブランチに切り替える

$ git checkou now-branch

④ 一時退避していたものを戻す

$ git stash pop

最後に

とても便利なTIPSです。同じようなことで悩んでいる方はぜひ使ってみてください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-03-03T21:35:51+09:00

実務未経験者が共同開発をして公開するまで

1.はじめに

オンラインサロンにて共同開発のお知らせがあり、チームリーダーとして開発を行いました。
未経験者が共同開発を終えて学んだこと、気をつける点を書いていきます。
これから共同開発に参加する方の少しでも参考になれば幸いです。

2.簡単な自己紹介

・学習期間2020年10月〜　
・実務未経験
・転職に向けて学習中

3成果物について

（トップ画面）
1.jpg

成果物はこちら(架空サイト）

4.概要

概要
・開発期間は3週間
・週1のミーティング
・完全再現ではなく、納期優先

メンバー構成
・現役エンジニア（メンター）1名
・実務未経験者3名

環境 / 技術
・EJS
・Sass
・Javascript（jQuery)
・Node.js
・記法 Scss
・CSS設計（FLOCSS)
・GitHub（ソースコード管理）

5.事前準備、環境構築

【実施事項】
・初回ミーティング
・Trelloでタスク管理
・実装内容をissueに登録
・チーム内のルール決め
・Node.jsのバージョンを統一
・GitHubでリポジトリ作成


【実施したこと】
チームリーダーとしてスケジュールの管理、進捗の確認、ミーティングの日程調整を行いました。
また、1日の進捗報告を必ず行うことでメンバー全員で個々の状況を把握することができました。

【学んだこと、気をつけた点】
Trelloのガントチャートでタスク管理。ヘッダーやお問い合わせフォーム等の担当ページをチーム全体で管理・共有することでスケジュールを把握して、デプロイから逆算して実装を進めていくことができました。

6.実装

【実施したこと】
・GitHubでソースコードを管理
・npmでパッケージをインストール
・ブランチの作成
・担当部分の実装
・CSS設計：FLOCSS記法


【学んだこと、気をつけた点】
メンバー全員が仕事の合間を縫って開発に取り組んでいたため、質問する時は何を、どのように、試したこと、実装したい内容を詳細に説明するように心がけました。また、わからないことはSlackで質問して記事の共有やコードの確認、修正をして開発を進めていきました。

コードの記述はSassを使用。
FLOCSS記法で開発を進める仕様でした。初見でしたが、FLOCSSについての記事を読んだり、メンバーのコードを確認することで書き方を知ることができました。FLOCSSを使用して一番最初に実感したことは、CSSの記述が少なく済むことです。Project、Componentでコードの再利用ができたり、BEMを取り入れることで要素と要素の繋がりがわかりやすくなりコードの可読性が上がります。チーム開発やコードを確認するときには重要な記法だと開発を通じて経験することができました。

→FLOCSSを使ってCSSファイルを20,000行から9,000行にした話

ブランチはmasterと担当ページごとにブランチを切り、pushしていきました。個人でブランチを切ることは少ないと思いますが、共同開発でのmasterブランチは本番環境リポジトリになるため、誤ってmasterブランチにpushしてしまうと他のメンバーにも影響してしまうので、gitコマンドを調べたり、git branchで現在の作業ブランチの確認を行い、慎重にpushするようにしました。結果として、gitコマンドの理解が深まりました。

7.実装ページ

・TOPページ
・ROOMページ
・AREA GUIDEページ
・ACCESSページ
・CONTACTページ
・Faqページ
・Header
・Footer

【学んだこと、気をつけた点】
開発中に大変だったことは以下の2点です。
①実装したいコードの書き方がかわからない
②エラーの修正


①実装したいコードの書き方がかわからない
実装を担当したHeader、Footer、ARIA GUIDEページを進めていく中で、JavaScriptの実装では動作がうまくいかないときが何度もありました。そのときに実践していたことは、似たようなサンプルをGoogle検索やQiitaで調べてコードを少し書き換えてみる。それでもうまくいかないときはメンバーやメンターに質問をするようにして実装を進めていきました。


②エラーの修正
エラーコードの内容がわからないときはGoogle翻訳で日本語に変換してから、ネットで検索したり、コードがどこまで動作しているかconsol.logを使い検証ツールで確認作業を行いました。

また、エラーはメモに保存してエラーの内容と解決方法を残しながら進めていき、同じエラーが起きてもメモを見返して対処するようにしていきました。

8.コードレビューまでの流れ

【実施したこと】
・ローカルリポジトリへ保存
・リモートリポジトリ（現在と同じ作業ブランチ）にプッシュ
・プルリクエスト
・チーム内でコードレビュー
・レビュー結果に基づき修正
・メンターによるコードレビュー
・再度、修正
・リモートリポジトリ（masterブランチ）へプッシュ


【学んだこと、気をつけた点】
gitコマンドの一連の流れを学習することができました。特に頻繁に使うコマンドやエラーはメモを取るようにして、次回以降に同じ内容のエラーが出てもすぐ対処できるようにしていきました。

また、メンバーやメンターからコードレビューをしていただいたことで、コードを変更する時の注意点や、文章が事前に用意されているときは手打ちせず、コピペをすることだったり、修正依頼が来たときに対処しやすいコードの書き方をご教授いただき見本に近い実装をすることができました。

9.まとめ

共同開発でデプロイするまでの開発フローやコミュニケーションの取り方を経験することができました。
特にGitHub、Git、コミュニケーションの取り方は重要だと考えます。

GitHubのリモートリポジトからローカルリポジトリにクローン、ブランチを切って作業を進めることや、ローカルリポジトリにコミット、プルリクエストしてissueを閉じるまでの流れを理解すること、Gitはコマンド操作、コミュニーケーションを取るときには詳細を伝えることで開発をうまく進めていけると思います。

最後にここまで読んでいただきありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-03-03T21:35:51+09:00

未経験者が共同開発をして公開するまで

1.はじめに

オンラインサロンにて共同開発のお知らせがあり、チームリーダーとして開発を行いました。
未経験者が共同開発を終えて学んだこと、気をつける点を書いていきます。
これから共同開発に参加しようと思ってる方の少しでも参考になれば幸いです。

2.簡単な自己紹介

・学習期間2020年10月〜　
・実務未経験
・転職に向けて学習中

3成果物について

（トップ画面）
1.jpg

成果物はこちら(架空サイト）

4.概要

概要
・開発期間は3週間
・週1のミーティング
・完全再現ではなく、納期優先

メンバー構成
・現役エンジニア（メンター）1名
・実務未経験者3名

環境 / 技術
・EJS
・Sass
・Javascript（jQuery)
・Node.js
・記法 Scss
・CSS設計（FLOCSS)
・GitHub（ソースコード管理）

5.事前準備、環境構築

【実施事項】
・初回ミーティング
・Trelloでタスク管理
・実装内容をissueに登録
・チーム内のルール決め
・Node.jsのバージョンを統一
・GitHubでリポジトリ作成


【実施したこと】
チームリーダーとしてスケジュールの管理、進捗の確認、ミーティングの日程調整を行いました。
また、1日の進捗報告を必ず行うことでメンバー全員で個々の状況を把握することができました。

【学んだこと、気をつけた点】
Trelloのガントチャートでタスク管理。ヘッダーやお問い合わせフォーム等の担当ページをチーム全体で管理・共有することでスケジュールを把握して、デプロイから逆算して実装を進めていくことができました。

6.実装

【実施したこと】
・GitHubでソースコードを管理
・npmでパッケージをインストール
・ブランチの作成
・担当部分の実装
・CSS設計：FLOCSS記法


【学んだこと、気をつけた点】
メンバー全員が仕事の合間を縫って開発に取り組んでいたため、質問する時は何を、どのように、試したこと、実装したい内容を詳細に説明するように心がけました。また、わからないことはSlackで質問して記事の共有やコードの確認、修正をして開発を進めていきました。

コードの記述はSassを使用。
FLOCSS記法で開発を進める仕様でした。初見でしたが、FLOCSSについての記事を読んだり、メンバーのコードを確認することで書き方を知ることができました。FLOCSSを使用して一番最初に実感したことは、CSSの記述が少なく済むことです。Project、Componentでコードの再利用ができたり、要素と要素の繋がりがわかりやすいため、コードの可読性が上がりチーム開発やコードを確認するときには重要な記法だと開発を通じて経験することができました。

→FLOCSSを使ってCSSファイルを20,000行から9,000行にした話

ブランチはmasterと担当ページごとにブランチを切り、pushしていきました。個人でブランチを切ることは少ないと思いますが、共同開発でのmasterブランチは本番環境リポジトリになるため、誤ってmasterブランチにpushしてしまうと他のメンバーにも影響してしまうので、gitコマンドを調べたり、git branchで現在の作業ブランチの確認を行い、慎重にpushするようにしました。結果として、gitコマンドの理解が深まりました。

7.実装ページ

・TOPページ
・ROOMページ
・AREA GUIDEページ
・ACCESSページ
・CONTACTページ
・Faqページ
・Header
・Footer

【学んだこと、気をつけた点】
開発中に大変だったことは以下の2点です。
①実装したいコードの書き方がかわからない
②エラーの修正


①実装したいコードの書き方がかわからない
実装を担当したHeader、Footer、ARIA GUIDEページを進めていく中で、JavaScriptの実装では動作がうまくいかないときが何度もありました。そのときに実践していたことは、似たようなサンプルをGoogle検索やQiitaで調べてコードを少し書き換えてみる。それでもうまくいかないときはメンバーやメンターに質問をするようにして実装を進めていきました。


②エラーの修正
エラーコードの内容がわからないときはGoogle翻訳で日本語に変換してから、ネットで検索したり、コードがどこまで動作しているかconsol.logを使い検証ツールで確認作業を行いました。

8.コードレビューまでの流れ

【実施したこと】
・ローカルリポジトリへ保存
・リモートリポジトリ（現在と同じ作業ブランチ）にプッシュ
・プルリクエスト
・チーム内でコードレビュー
・レビュー結果に基づき修正
・メンターによるコードレビュー
・再度、修正
・リモートリポジトリ（masterブランチ）へプッシュ


【学んだこと、気をつけた点】
gitコマンドの一連の流れを学習することができました。特に頻繁に使うコマンドやエラーはメモを取るようにして、次回以降に同じ内容のエラーが出てもすぐ対処できるようにしていきました。

また、メンバーやメンターからコードレビューをしていただいたことで、コードを変更する時の注意点や、文章が事前に用意されているときは手打ちせず、コピペをすることだったり、修正依頼が来たときに対処しやすいコードの書き方をご教授いただき見本に近い実装をすることができました。

9.まとめ

共同開発でデプロイするまでの開発フローやコミュニケーションの取り方を経験することができました。
特にGitHub、Git、コミュニケーションの取り方は重要だと考えます。

GitHubのリモートリポジトからローカルリポジトリにクローン、ブランチを切って作業を進めることや、ローカルリポジトリにコミット、プルリクエストしてissueを閉じるまでの流れを理解すること、Gitはコマンド操作、コミュニーケーションを取るときには詳細を伝えることで開発をうまく進めていけると思います。

最後にここまで読んでいただきありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-03-03T16:39:51+09:00

Git覚え書き

Gitチュートリアル

準備

apt-get update
apt-get install -y git
apt-get install -y vim

設定

git config --global user.name "Shoichiro Kanno"       # 名前(必須)
git config --global user.email "s-kanno@example.com"  # メールアドレス(必須)
git config --global color.ui true                     # カラー表示(任意)
git config -l                                         # 設定内容確認
git config --global --unset {key}                     # 設定項目の削除
git config --global credential.helper 'store --file ~/.git_credentials' # 認証情報を記憶

基本的な使い方

git init             # 初期化
git add hogehoge.txt # 特定のファイル・変更を追加
git add .            # すべてのファイル・変更を追加
git rm hogehoge.txt  # ファイル削除
git mv hogehoge.txt foofoo.txt # ファイル移動
git commit           # コミット
git commit --amend   # 直前のコミットの変更を変更する
git log              # 履歴表示
git log --oneline    # 履歴表示(1行表示)
git log -p           # 履歴表示(変更箇所付き)
git log --stat       # 変更履歴(変更ファイル名付き)
git status           # 状態を表示
git checkout -- hogehoge.txt # commitされている状態に戻す
git diff             # 変更箇所を表示
git diff --cached    # ステージングエリア(コミット前)の変更箇所

vi .gitignore        # 無視するファイルを設定

git reset --hard HEAD       # コミットされている状態に戻す(ファイルの変更、追加も打ち消す)
git reset --hard HEAD^      # HEADから1つ前のコミットに戻す(すべて打ち消す)
git reset --soft HEAD^      # HEADから1つ前のコミットに戻す(ワーキングツリー・インデックスはそのまま)
git reset --mixed HEAD^     # HEADから1つ前のコミットに戻す(ワーキングツリーはそのまま)
git reset --hard {id}       # 特定のコミットに戻る
git reset --hard ORIG_HEAD  # 持っどったのを戻る

git reflog                  # HEADが辿ってきた履歴

git branch                    # ブランチの一覧
git branch {branch_name}      # ブランチの作成
git branch -d {branch_name}   # ブランチの削除
git checkout {branch_name}    # ブランチの切り替え
git checkout -b {branch_name} # ブランチを作成、同時に切り替え
git merge {branch_name}       # ブランチのマージ
git merge --squash {branch_name} # マージするブランチのコミットを1コミットにまとめる ※別途コミットすること

git tag {tag_name}      # 直近のコミットにタグを付ける
git tag {tag_name} {id} # 特定のコミットにタグを付ける
git tag -d {tag_name}   # タグの削除
git show {tag_name}     # タグのコミットを表示

git clone {url} {dir_name} # クローン
git push                   # プッシュ
git pull                   # プル
git push --set-upstream origin {branch_name} # ブランチを作って初回のプッシュ

git stash -u                      # 変更内容を退避(-uを付けるとaddをしていないファイルも退避する)
git stash -u save "stash message" # メッセージを付けて変更内容を退避
git stash list                    # stashの一覧を表示
git stash apply stash@{0} --index # stashした状態に戻す(--indexを付けないとaddを行った情報がなくなる)
git stash drop stash@{0}          # stashを削除

# branch1へbranch2を取り込む。その歳、branch1の最新のコミットからbranch2のコミットを追加する。
git rebase {branch1_name} {branch2_name}

git cherry-pick {id} # 特定のコミットを取り込む

git revert [id] # 特定のコミットを消す

小ネタ

# git logで文字化けする場合の対応
vim ~/.bashrc
export LESSCHARSET=utf-8
source ~/.bashrc
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-03-03T11:18:31+09:00

開発未経験が書く　Git-flow、GitHub-flowの便利なところ

この記事について

この記事は、開発未経験の人間がインプットした内容が書かれています。
実際に開発経験を積まないと身につかない、かといって疎かにしたら後々痛い目にあう、といったジレンマを少しでも解消するために、「頭の中を言語化し、解釈違いを指摘してもらう」という手段を取ることとしました。
気になる点がありましたらツッコミをいただけると嬉しいです。

記事の内容

Git-flowとGitHub-flowの良いところを、Gitのみで開発した場合と比較しまとめる。

インプット教材

git flowとgithub flowとは？その違いは？: https://qiita.com/mint__/items/bfc58589b5b1e0a1856a
Git-flowって何？: https://qiita.com/KosukeSone/items/514dd24828b485c69a05#1ローカルリポジトリにクローンを作成する
Git-flow ～Gitのブランチモデルを知る～ : https://tracpath.com/bootcamp/learning_git_git_flow.html#i
GitHub Flow ～GitHubを活用するブランチモデル～ : https://tracpath.com/bootcamp/learning_git_github_flow.html

開発環境

git version 2.21.0

例題

以下の作業を行う。

  • 猫を愛でるテキストファイルcat_lover_said.txtを作成
  • 文体がバラバラなので統一する作業をする
  • 文末にある「頭おかしい」という表現が過激なため、マイルドにする。

Gitのみで作業した場合

Gitのみで作業した場合は以下の順番で作業することになる。ソースコードは割愛。

  1. 中身が空のレポジトリをGitHubに作成し、ローカルリポジトリにクローンを生成。ユーザー名とアドレスを登録。
  2. developブランチを切り、猫を愛でるテキストファイル"cat_lover_said.txt"を作成してPush
  3. 文体を統一する作業ブランチfeature/unify_stylesを切り作業する。
  4. 文章の末尾にある「頭おかしい」という文章を修正するため、hotfixブランチを切り修正する。Githubにも同名のファイルを作成。
  5. 作業が完了したら、追跡できるようにようにしてPush。
  6. hotfixをmasterにマージ。masterをPush。
  7. hotfixを削除し、Githubの方も同時に削除。
  8. masterをdevelopにマージしてdevelopをPush。
  9. 文体のを統一する作業が終わっているのでPushしたいが、先にPullする必要があるのでPullしてから作業ブランチfeature/unify_stylesをGithubにも作成。
  10. 作業ブランチfeature/unify_stylesをmasterにマージしてmasterをdevelopにマージ。
  11. Pushして完了。

Git-flowで作業した場合

Git-flowには6種類のブランチがあらかじめ定義されている。
1. masterブランチ・・・Git作成時に自動で作成されるブランチ。直接コミットすることはなく、マージを行うだけ。このブランチの最新版が市場に公開される。
2. developブランチ・・・開発の中心となるブランチ。だが、実際の作業はここから枝分かれしたブランチで行い、作業完了後にdevelopブランチへマージする。masterブランチ同様、このブランチも直接コミットしないので注意。Git作成時、最初にmasterから切っておく。
3. featureブランチ・・・機能の追加や変更、バグの修正をするブランチ。一つの変更に対してひとつのfeatureブランチを切ること。ブランチの名称は作業の内容がわかるような名前にする。developブランチから切り、作業終了後にdevelopブランチへマージし、削除する。
4. releaseブランチ・・・製品をリリースするために使うブランチ。リリースに関連する作業をする（タグつけなど）。developブランチから切る。作業完了後にmasterとdevelopにマージし削除する。
5. hotfixブランチ・・・緊急な修正があった場合にmasterからこのブランチを切る。作業後にmasterとdevelopにマージし削除。
6. supportブランチ・・・プロジェクトによっては不要だが、旧サポートし続けなければならないプロジェクトではsupportブランチが必要。このブランチは旧バージョンの保守とリリースを行う。サポートが必要なバージョンのmasterのコミットから派生させ、サポート終了まで独立してバグ修正やリリースを行う。

作業開始

  • 空のレポジトリをGitHubに作成し、クローンを作りユーザー名とアドレスを登録。
  • 作業ディレクトリでgit flow initを実行し初期化する。なんか色々聞かれるが全てEnterで実行で問題なし。Git-flowで定義している各ブランチが設定される。
  • developでは作業を行わず、新しく作業ブランチを切る。作業ブランチはfeatureブランチと言われており、切るときはgit flow feature start branch_nameを実行。実行後、自動的にdevelopからブランチが切られる。
  • "cat_lover_said.txt"を作成し、addとcommitする。
  • git flow feature finish branch_nameでdevelopにマージする。
    • Git-flowでブランチを切る時には、startとfinishというコマンドを使う。 git flow feature start aaaでaaaという名のfeatureブランチがdevelopから自動で切られ、 git flow feature finish aaaでaaaという名のfeatureブランチがdevelopにマージされ、さらにマージ後に自動で消去してくれる。
  • 作業が完了したのでPushしたいところだが、Git-flowにはreleaseブランチが必要である。先にgit flow release start branch_nameでreleaseブランチを作成。これも自動でdevelopから切られる。タグをつけるなど、何かしらのリリース処理をしたら、git flow release finish branch_nameでdevelopをマージしてから、masterへマージする。
  • マージコミットのメッセージとは別にリリースタグの文章がかけるので「初回リリース」と入れておく。
  • Pushする。developはリモートディクトリと連携していないので、連携する。
  • 「頭おかしい」という表現を修正する作業ブランチhotfixを作成。修正後のバージョン1.1を名称にする。
  • 作業が完了したら、git flow hotfix finish 1.1でmasterへマージ。
  • pushする。
  • unify_stylesブランチもすでに終っているのでhotfixの時と同じ流れでmasterへマージ、masterをdevelopへマージする。

Git-flowを使った場合のメリット

  • git flow branch start(finish) branch_nameで自動でブランチを適切なブランチから切ってくれたり、マージしてくれる。
  • 自動で作業が終わったブランチを削除してくれる。

GitHub-flowで作業した場合

GitHub-flowには2種類のブランチ（master, topic）しかない。6種類あるgit-flowのブランチの方が厳密であるが、手間が多くなりがち。厳密な区分けが必要ない場合はGitHubーflowを使った方が楽。また、git-flowでは特熱なイベントとしてdevelopとmasterの間にreleaseがあるが、GitHub-flowにはそれがないのでmasterへのマージにはgit-flow以上に細心の注意が必要である。

注意点

  • 必ずmasterからtopic（作業ブランチ）を切る。masterでの作業はマージするのみ。
  • ブランチは定期的にPushする。GitHub-flowはその名の通り、GitHubを介したコミュニケーションを推奨している。そのため、頻繁にコードレビューを行うことで仲間との情報共有を重視している。
  • プルリクエストを活用し、積極的にコードレビューをしてもらう。
  • コードレビューが通ったら速やかにマージする。他の開発者とマージで衝突が起こる可能性があるため。

作業開始

  • ユーザー名とアドレスを作業ディレクトリに登録。
  • GitHubにレポジトリを作成。この時、他に作業メンバーがいるときは追加する。
  • リポジトリのクローンを作業ディレクトリに生成。
  • 空のコミットを作ってGitHubにPush。
  • topicブランチであるcreate-text-fileブランチを生成し、そこでcat_lover_saidを作成。addしてcommit。
  • pushする。初回push時にGitHubへのログインパスワードを聞かれるので入力。
  • GitHubのサイトからプルリクエストをしてコードレビューをしてもらう。
  • OKが出たらマージする。GitHubからボタンクリックで簡単にできる。
  • GitHubにあるcreate-text-fileブランチを削除する。これもGitHubにボタンがあり簡単にできる。作業ディレクトリのブランチは手動で削除する。
  • 作業ディレクトリのmasterが古いままなのでPullして最新版にする。
  • 「頭おかしい」という表現を修正するhotfixブランチを生成する。あとはcreate-text-fileブランチと同じ流れ。
  • 文体を統一するunify_stylesブランチを生成。同じ流れで作業する。

GitHub-flowを使った場合のメリット

  • 作業ディレクトリで行う作業とGitHubで行う作業がきっちり区分けされていてわかりやすい。
  • 細かいブランチの設定が必要ない。
  • 「ブランチを切る→作業する→push→レビューしてもらう（修正し再提出する）→マージする→作業ブランチを削除→Pull」という流れがわかりやすいので未経験者の私には一番理解が容易で実装しやすいと思った。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧