Githubの Issue & Project(カンバン)でプロダクトバックログ/タスクを管理する(アジャイル開発の運用)

  • アジャイル開発におけるバックログ管理をGitで完結させる手法について、説明用のメモ
    • プロダクトバックログとは?
      • ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリスト
      • アジャイル開発においてはタスクや検討事項を”プロダクトバックログ”として定義する(フィーチャーとも呼ぶ)
        • バックログをリスト化 ⇒ 優先度付け ⇒ 順次消化 ⇨ チームのベロシティを計測 ⇨ 次期計画策定 というサイクル(イテレーション/スプリントと呼ぶ)を回す方式が一般的
    • 他のタスク管理ツールも色々試したが、個人的にはこの手法が最も効率が良いと感じた
    • Zennなどを組み合わせてバーンダーンチャート化すると、より状況を可視化しやすい(Velocityを計測しやすい)

前提知識

  • Issue

    • ここにバックログを登録していく
    • ラベルでカテゴリライズする
      • Ex. Question(質問), Bug(バグ), enhuncement(追加機能), Documentation(ドキュメント整備)
    • Assigne
  • Projects (カンバン)

    • Issueを一覧化するGitの機能
    • 複数リポジトリに分割して開発する場合でも、Projectを使ってissueをまとめることが可能

これらのGitの機能を使って、プロダクトバックログの管理を実施する。
他のタスク管理ツールは使用しない。

バックログ管理の大まかな流れ

  1. Project(カンバン)を作成する

  2. バックログをIssueとして登録

    • 小タスクをチェックボックス形式で設定
    • 生成したIssueはカンバン(Project)のTo Doに自動的に反映される
  3. カンバンよりバックログ(Issue)一覧を確認。着手するものを選択

    • 着手を開始したIssueは、カンバン内でIn Progress columnへ移動
  4. 完了したタスクにチェックを入れていく

    • Pull Request時にはIssue番号をコメントに入れる
    • そうすることでPRのClose時に自動的にIssueもDoneとなる
  5. 全タスクが完了したIssueはDone columnへ移動

    • 1スプリントに幾つのIssueをDoneに持っていけるか?でチームのVelocityを計測する
    • Velocityを元に、次スプリントでどこまでやるか?を決める。アジャイルは適当に進めて良いというのは間違い
    • 可視化ツールとの連携でバーンダーンチャート化するとより状況を可視化しやすい
      • 経験上、企業の開発環境(Github Enterprise)では使えないことが多い

0. Project(カンバン)を作成する

バックログ一覧(Issue一覧)を確認する画面だと考えてよい
Issueとしてバックログを登録する前に、Project(カンバン)を作成する必要がある
後に登録したIssueがこちらのTo doに自動的に表示される

Github Project

  • github 任意のリポジトリ画面
    • Projctsタブ
    • Creaate a Project
  • プロジェクト設定画面
    Project Setting
    • PJ名と説明文を入力
    • Template (今回はAutomated kanban)
      • None: デフォルトのもの
      • Basic kanban
        • To do, In progress, Doneの列を持つ基本的なカンバン式ボー
      • Automated kanban
        • 各列にある課題やプルリクエストを自動的に移動させるためのトリガーが組み込まれている
      • Automated kanban with reviews
        • プルリクレビューのためのトリガーを追加したカンバン
      • Bug triage
        • To do、High priority、Low priority、Closedの各カラムでバグのトリアージと優先順位付けを行うもの
    • Create project
  • 作成されたカンバン
    git project kanban

1. Issueでタスクを登録

次にIssueでタスクを登録していく。ここで作成するIssueに事前に作成したProjectを紐づけすることで、カンバンから一覧として確認可能になる。

  • Issueの作成方法
    • GHE Issueタブ
    • New Issue
    • 右側の各種設定
    • コメント入力
    • Submit new issue
  • タスク以外の相談事項もIssueで発行する
    Issueを活用した相談例
    Issue作成時に記載するコメントのテンプレートや、設定のルールをチーム内で事前に定めておく
    Read.meやWikiに載せておく

Issue作成時の設定ルール

以下を一通り設定することでタスク管理の効率化を図れる。
後でカンバンからIssueの設定を変更することも可能。

  • Assignees
    • タスクの担当者を指定する
  • Labels
    • バックログをカテゴライズ可能
      • 元々主なカテゴリのラベルが用意されており、追加も可能
        • Ex. bug(バグの修正時), documentation(資料作成), enhancement(機能拡充)
      • タスクの重要度や、重さまでラベル化するかはチームで相談して決める
  • Milestones
    • 期限を指定する

Issueコメントフォーマット

Issueを生成する際に.md形式で説明を書くことができる
以下のようなフォーマットをチームで定めておくとよい

  • ルール例

    • WHY/WHATを必ず書く
      • 根本的な内容の後戻りを防ぐため
    • タスクリスト記法で未完了/完了の変更を行う
      • 以下のように書くと、チェックボックスとして扱うことが可能になる
        • これでバックログに含まれる小タスクを表す
          1
          - [ ] Task
  • Issueコメントフォーマット例

    • バックログ毎にissueを生成する場合の例。より細かい単位でタスク毎にissueを作るチームも多い
    • 各メンバがGitに慣れていれば、タスク単位でIssueを切るとうまくいく
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      ## 概要
      ### WHY
      なぜこのIssueが必要になったのか?
      ### WHAT
      何をするのか?
      ## タスク
      以下の書式で書くとチェックボックスとして扱える
      - [ ] Task a
      - [ ] Task b
      ### 関連課題
      ---
      関連する課題があればここにリンク形式で載せる(Backlog)
      ### 親課題
      ---
      親の課題があればここにリンク形式で載せる(Backlog)
      ### 備考
      ---
      別途記載する必要があれば書く
      ## Reference
      参考文献があれば記載
  • こういったフォーマットをテンプレートとしてGitに登録しておくと利便性が高まる

    • 守らないメンバが出て形骸化してしまう事態を防ぐ
    • 少なくともREADMEか、Wiki等のメンバが閲覧可能な場所に置いておく

issueテンプレートの登録方法

先ほどの様なフォーマットを複数種登録して、issue生成時にユーザに選択させることができる

  • Settingsタブ/Options/Features/issues/setup templateを押下
    github issue Setup Templates
  • Add Template
    • Custom templateを選択することでチーム独自のTemplateを登録できる
    • 元々Bug ReportとFeature requestが用意されている
    • 以下のようにTemplateを追加していき、後は”Preview and edit”から用途に応じたフォーマットを用意する
      • 混乱を避けるために一種にするか、用途ごとに分けるかはチームで相談する
        github issue add template
  • 元々用意されているFeature requestの中身は以下
    • これを利用すれば、機能提案を非同期コミュニケーションで行うことが可能になる
    • 開発の中で思いついた機能をミーティングの場を待たずにすぐさま提案でき、開発スピードの向上を見込める
      github issue Feature Request
  • custom issue template
    • ここに独自のフォーマットを登録する
    • 設定項目は以下
      • Template name
      • About
        • tempalteの説明
      • Template content
        • 上記のプロダクトバックログの登録用のフォーマットをここに入力
      • Optional additional items
        • Issue default title
          • デフォルトのタイトルを指定可能
        • Assignees
          • このテンプレートを活用してissueを生成する際の担当者を設定可能
          • 対応者が確定するレベルで細かくテンプレートを用視するのであれば有用
        • Labels
          • このテンプレートを活用してissueを生成する際のlabelを指定可能
          • 指定しておけばLabelのつけ忘れを回避できる
  • 各Templateの編集後
    • propose changes
    • Commit changes

Project(カンバン)の運用フロー

以下の流れで、バックログの進捗状況を可視化する

  • 着手を開始したIssueをIn Progressへ移動
  • 完了したタスクのチェックボックスを埋めていく
  • 全タスクが完了したIssueをDoneへ移動

Pull Request関係のルール

  • Pull Request発行時には、コメントに #Issue番号 と書く

    • GitHubではPull Requestも1つのIssueとして扱われる
    • 対象Issueのコメント欄上部に、タイムライン形式でコミットが表示されるようになる
    • Issue番号をPull Requestのコメントに追加することで、Pull Request(小さなIssue)を束ねたIssue が作成できる。これをうまく利用することで、細かいタスクが各所に散らばる問題を防ぐことが出来る
  • Issue完了時にはPull Requestのコメントに Fix #issue-id と書く

    • Tips: : Pull Requestのマージと同時にIssueを閉じる方法
    • commitメッセージ、Pull Requestのメッセージ、もしくはPull Requestのコメントで、issue idの前にfixかcloseが含まれていると、Pull RequestがマージされたタイミングでIssueも同時に閉じられることになる。
    • 記載例
      1
      Fix #1234
      1
      To close #3456
    • このように書くとIssueの閉じ忘れが減る
  • アジャイル開発自体については以下にまとめた


参考

関連記事

その他


[Google cloud shell x Hexo] 環境構築&記事編集

Google Cloud Shell上にHexo環境を構築した際のメモ

前提

git連携 & リポジトリのclone

  • git configでユーザの情報を登録してから、cloneでデータを持ってくる
    • cloud shellにはgit cliが元から入っているので楽
      1
      2
      3
      git config --global user.name "user-name"
      git config --global user.email "e-mail"
      git clone your repository
  • hexoをinstall
    • cloud shellにはNode.jsが元から入っているのでHexoを入れるだけ
      1
      2
      3
      cd your-repository/your-blog
      npm install -g hexo
      npm install hexo --save

記事のプレビュー表示における注意点

  • Hexo serverでlocalhostを起動する際に、-pでポートを8080に指定する必要があります

    • デフォの4000はcloud shellでは見れないため
      1
      hexo server -p 8080
  • previewは右上のアイコンから開けます
    cloud shell open preview

  • 以上でブラウザでWEBページの画面を確認可能です

Githuにpush時にログイン

  • 以下のようにユーザ名とパスワードの入力求められます
    1
    2
    Username for 'https://github.com': 
    Password for 'https://user-name@github.com':

関連記事

Google Cloud Shell

Hexo

Github

git複数アカウントの使い分け設定

社内開発/他社との共同開発/個人開発等でgitのアカウントを使い分けたい人向けのメモ

gitアカウント情報の設定方法

端末上のLocalリポジトリとgit上のRemoteリポジトリ間でデータをやり取りするには以下の情報が必要です

  • gitの認証に必要な情報
    • gitのユーザ名
    • 登録したメールアドレス

上記の情報の設定方法は以下の二種があり、利用頻度によって使い分けるのが一般的です

  • git認証情報の設定方法
    • グローバル変数として設定
      • メインのアカウントを登録
      • リポジトリ毎の設定が無い場合には、ここに設定した情報が使われる
    • リポジトリ毎の設定
      • サブのアカウントを登録
      • 設定したリポジトリ内でのみ影響

メインアカウントの設定

global(~/.gitconfig)に設定

業務で良く使うアカウントは、globalに設定する

  • git config –globalで設定
    1
    2
    $ git config --global user.name "account-name"
    $ git config --global user.email "account-mailaddress"
  • 確認
    1
    2
    3
    4
    5
    $ cat ~/.gitconfig

    [user]
    name = account-name
    email = account-mailaddress

サブアカウントの設定

サブのアカウントは、リポジトリ単位でアカウント情報を設定する

リポジトリ内の./.git/configに設定

  • git config –localで設定

    1
    2
    3
    cd repository
    git config --local user.name "subaccount-name"
    git config --local user.email "subaccount-mailaddress"
  • ./.git/configを確認

    1
    2
    3
    4
    5
    repository> cat ./.git/config

    [user]
    name = subaccount-name
    email = subaccount-mailaddress
  • git logで確認

    • それぞれのアカウントでgit commitsした後にgit logで反映されているか確認可能
    • サブアカウントを登録したリポジトリ以外はメインアカウントの情報が出るはず
      1
      2
      3
      4
      5
      git log

      commit XXXXXXXXXXXXX
      Author: subaccount-name <subaccount-mailaddress>
      Date: Xxx Xxx 00 00:00:00 2020 +0000

参考

関連記事

その他

[Github入門] branchをLocalで生成~Remoteに反映

Github Flow

基礎知識

  • branch(ブランチ)とは

    • 履歴の流れを分岐して記録していくためのもの
      • 直訳すると枝/分岐
    • なぜ必要か?
      • githubで開発する際には、リポジトリの中のソースコードを弄っていくわけですが、複数のメンバがいる場合には、同時進行になります。そこで、各メンバ毎にbranchという単位で作業場所を枝分かれさせる必要があります
    • 分岐したbranchの中身は後で合流(merge)させることができます
    • 開発メンバ毎にbranchを作成するのが一般的です
  • 複数人での分散開発のざっくりイメージ

    • メンバ毎のbranchで開発
    • 担当範囲の開発完了後にレビュー(Pull Request)を経て、各branchで編集した内容を合わせる(merge)
    • 各メンバの編集内容をmergeした完成版をmaster branchに置く

手順

  • branchの生成

    1
    git branch <branch-name>
  • branchが作成されたことを確認

    • 下記のコマンドでbranch一覧を確認可能
      1
      git branch -a
    • *がついているのがカレントブランチ(今いるbranch)
    • VSCodeの場合赤字で表示されるbranch(remotes/origin/…)がremote上(Github上)のbranch
      • 先ほど作成したbranchはLocalにはあるが、remoteにはまだ存在しないことが分かる
  • branch間の移動

    1
    git checkout <branch-name>
  • remoteにLocalのbranchを反映

    1
    git push origin <branch-name>
  • remote側にもbranchができたか確認

    • 赤字で”remotes/origin/branch-name”が表示されればOK
      1
      git branch -a
  • 以降の作業はgit checkoutでbranchを移動しながら行います

  • branch間の変更内容を合わせる際には以下の学習も必要です

    • git mergeやgit rebase等のコマンド
    • Pull Request
    • そのうちまとめます

Trouble Shooting

  • 誤って生成したbranchの削除
    1
    git branch -d <branchname>

Github x Teams Webhook/Notificationによる連携方法

TeamsとGithubの連携方法について解説します。GitにpushやPull Requestdを出す度にメンバにメッセージを送る手間を自動化しましょう。
Slackとの連携方法は沢山出てくるのですが、Teamsは古いものしか無かったので纏めておきます。

1. TeamsとGithubの連携方法

  • 2種類あります
    連携イメージ

1.1. Webhooks

  • Githubの機能
  • 任意のEventを起点に発火
    • ex.) masterへのpush, PullRequest…
  • 特定のURLに対して通知を飛ばす
    • Teamsの特定チャンネルのコネクタ宛
  • Teams側ではコネクタでリクエストを受け取る
    • ex.) Incoming Webhook or Githubアプリ

1.2. Notification

  • Githubの機能
  • Eventを起点に発火
    • 自分でEventを絞ることはできない
  • 特定のメールアドレスに対して通知を飛ばす
    • Teamsの特定チャンネルのメールアドレス宛
    • Teamsのチャンネルにはそれぞれ一意なメールアドレスが与えられている

1.3. どちらを使うべきか?

  • 社内セキュリティや機能制限でWebhookを使えない or メーリングリスト等にも通知を飛ばしたい
    • Notification
  • 特に制限無し
    • Webhook

2. WebhookでTeams x Githubを連携

  • Gituhubアプリは社内の機能制限で入れられなかったのでIncoming Webhookを利用します
    • TeamsのGithubアプリ
      • Teams App Storeかここで入手可能

2.1. Teamsにコネクタを追加

  • チャンネル名の右にある・・・からコネクタを選択
    コネクタ

  • Incoming Webhookの構成を選択
    Incoming Webhook

  • 接続名

    • Github等判別可能な名前を指定
  • イメージを設定

    • Botがメッセージを投稿する際のアイコンになる

Incoming Webhook

  • 作成を押下

  • 出てきたURLを控えて完了
    URL

  • チャンネルにメッセージが投稿される
    Message

2.2. GithubのWebhook設定

  • 設定画面
    • 任意のリポジトリのページに移動
    • Settings
    • Hooks
    • Add webhook

Github Webhooks

  • Payload URL
    • 送信先のURLを指定
    • 控えておいたTeamsのコネクタのURLをコピペ
  • Secret
    • パスワードが必要であれば設定
  • Which events would you like to trigger this webhook?
    • 通知を飛ばすイベントを絞りたい場合は ”Let me select individual events”を選択
    • 出てきた選択肢から必要なものをチェック

Events

  • 設定が完了したらAdd webhook
  • 以上でpush時にTeamsに通知が投稿されるようになります

3. NotificationでTeams x Githubを連携

3.1. メールアドレスを取得

  • チャンネル名の右にある・・・から”メールアドレスを取得”を選択
    Teams channnel mail address

  • 出てきたアドレスをコピー

    • <>で囲まれている箇所がメールアドレス
    • 通常のメールからここに対してメールを送ればTeamsに内容が投稿される

3.2. GitのNotificationに設定

  • 任意のリポジトリのSettings/Notificationsへ移動
    • Addressに先ほど控えたTeamsチャンネルのURLをコピペ
      image
  • 以下のようになれば設定完了
    image

  • 試しにpushをすると、Teamsに投稿されます
    image

4. その他

Microsoft FlowやAutomationによる自動化

  • 通知が来たタイミングでワークフローを実行させることもできるようです
    • Slackのワークフロー機能のようなもの
  • 社内の機能制限により試せなかったので、変えさせられたら追記します

参考

関連記事

その他

Github入門 ~入社初日の完全な素人でも分かる優しい説明~

今回はGithubというツールについて解説します。学生や新入社員等、これからアプリ開発を始める方が初めに覚えるツールなのですが、専門用語を並び立てた説明だらけで戸惑う方が多いため、極力丸めた言葉で優しく書きました。
 Githubはエンジニアに取っての読み書きのようなものです。当然の前提知識として暗黙知にされることが多く、アプリ開発を学ぶ中では必ず使うシーンがあります。あくまで作業を楽にするための便利なツールなので、食わず嫌いをせずに早めに覚えましょう。

image

1. Githubとは

  • 猫のようなキャラはマスコットのOctocatです
    image

  • ソースコード(アプリを構成するファイル群の事)を保管/共有する場所

    • アプリケーションはコードを書いたファイルの集まりで構成されます
    • 複数人で開発するには、各メンバが編集したソースコードを集めて合体(mergeと言います)させ、最新版を保管しておく共通の場所が必要
  • バージョン管理ツール

    • 時系列に沿ったソースコードの編集内容の変化を管理可能です
      • 差分の視覚化
        • 他メンバが開発した箇所がマーキングされて表示されます
          • ソースを1行づつ見比べる手間を省略できます
      • 任意のタイミングに戻せる
        • 例えば、誤ってアプリを壊してしまった際に、直前のタイミングに戻せます
  • コードレビュー(評価)

    • Pull Requestという機能を利用すると、自身の編集内容と共にメンバーに確認依頼を飛ばせます
    • 差分が一目で分かるため、レビューが効率的です
      • 指摘箇所のコードとコメントをセットで登録でき、対話形式で解決できます
    • 昔はExcelにレビュー表を作って一つ一つチェックしていたようです
      • このファイルのXX行目の~~がと毎回書いて照らし合わせる作業は恐ろしく非効率的なのでやめましょう
  • 連携機能

    • WEBhook
      • Slack等のチャットツールに通知を飛ばす機能です
    • Github Actions
      • 自動化機能
        • 例えば、Gitに編集したコードをアップした際に本番環境(アプリが動くサーバー等)に自動的に送ってくれたりします(デプロイという作業)
      • ある程度開発に慣れたら使ってみましょう
        • CI/CDやDevOpsというワードと一緒に勉強してみてください

2. Githubの利用に必要な準備

  • まずはアカウントを作成して、自分のPC上でGitのコマンドを実行できるようにインストールする必要があります

2.1. アカウントの作成

  • gitubでアカウント登録を行いましょう
    • 必要事項を入力してSign up
    • 通知メールから承認

image

2.2. IDEの準備

  • 開発を行うにはIDEというものが必要です

  • IDEは以下の二つの要素でできています

    • エディター
      • コードを編集する場所
    • CLI
      • コマンドを打つ場所
        • 基本的にここでgithubを操作するコマンドを打つので、用意が必要です
  • 以下をPCにインストールしましょう

  • 以降は上記のIDEのCLI(VS Codeの画面下部)にコマンドを打つという前提で説明を書きます

2.3. インストール

3. リポジトリ作成~クローン

  • リポジトリとは
    • ソースコードを格納する一つの箱のようなもの
    • 基本的にアプリ単位で作成します
    • これをGithub上と自分のPC上に対になる形で配置します(clone)
      • 中身のファイルを編集して、コマンドで行き来させます
        • ざっくりイメージ
          1. pullコマンドで自分のPCに持ってくる
          2. 編集
          3. pushコマンドでGithubに返す

3.1. リモートリポジトリの作成

  • githubにログインして”New Repository”から作成してみましょう

3.2. リポジトリをLocal端末へのClone

  • リポジトリ作成後の画面を開く

  • “Clone or download”を押下

    • 戻りのボタンです
    • 出てきたURLを保存します
  • 以下のコマンドをCLIで実行

    • Github上に作ったリポジトリが自分のローカル端末(PC)にコピーされます
      1
      git clone <url>
  • ここまででGit ⇔ PC間で、データを行き来させることが可能になりました

4. 編集した内容をリモートに送るまで/基本コマンド

基本的な流れを以下に示します

  • Github上から最新のソースコードを取得

    1
    git pull
  • 開発

    • ファイルを開いて編集
      • リポジトリ生成時にReadme.mdというファイルができていると思います
        • リポジトリの説明を書くファイル
        • ここに開発のルール等をメモしてメンバと共有するのが一般的です
    • VS Codeなら以下のコマンドで開けます
      1
      code <ファイル名>
  • add: リモートに送るファイルを指定

    • 厳密にはCommitに含めるファイルを指定
      1
      git add <編集したファイル名>
  • commit: 編集の完了を宣言

    • commitのタイミング毎にバージョン管理がされます
      • 好きなタイミングに戻れるようにこまめにcommitしましょう
        1
        git commit
  • リモートに編集内容を送る

    • ここで送られるのはcommitに含まれるファイルのみ
      1
      git push
  • ここまでで、個人開発はできます。次は複数人が関わるパターンを勉強しましょう。ブランチという概念の理解が必要です。

4. Githubを用いた分散開発

Cheat Sheat

関連記事

git merge & コンフリクトの解消(複数名の編集内容を集約)

Githubで初級者がハマりがちなポイントについてです。
複数メンバの編集内容をGitで効率的にまとめる手法を解説します。

git merge image

基礎知識

githubの分散開発

  • 基本的な進め方
    1. 開発メンバ数のbranchを作成
    2. 別々のbranchを各メンバが編集
    3. 作業完了後にmerge
      • ※本記事で解説する内容

git mergeとは

  • githubのコマンド

  • 機能

    • 複数branchのmerge
    • つまり各メンバの編集内容を反映して合わせることができます
  • メリット

      1. 差分の可視化
      • githubであれば、編集箇所がマーカーで表示されます
        • 編集日時・編集者も一目で判別可能
      • 目視でソースの変化を比較するにはすさまじい労力を伴います
      1. 変更の反映・集約の自動化
      • わざわざコピペする手間を削減可能
      • 複数名が別々の編集をしたファイル
        • 開くと各メンバの変更箇所が並んで表示されます
        • ボタン一つでどれを採用するか決定可能です
          • ※詳細は手順内で説明

mergeの楽さと過去の改修内容を時系列で遡れることが、gitを活用して分散開発を行う主な理由です

手順

  • 他人が編集していた別branchの変更内容を、自分のLocal端末上でmergeするまでを書きます

    merge

    1. リモートから別branchを取得
    • Localに未登録であれば実行(git branch -aで別branchが出ない場合)
      1
      git fetch
    1. 追加されていることを確認
      1
      git branch -a
    1. branchへ移動して内容を確認
      1
      git checkout <branch-name>
    1. 元のbranchに戻る
      1
      git checkout master
  • ※Commitが未実行のファイルが無いか確認

    • そのままmergeすると変更の取り込みが漏れてしまうため
    • 以下のように出ればOK
      1
      2
      3
      4
      5
      6
      git status

      On branch master
      Your branch is up to date with 'origin/master'.

      nothing to commit, working tree clean
    1. merge
      1
      git merge <branch-name>
  • 別々のファイルを改修していた場合は、以上で完了です

    • merge実行時に”CONFLICT”が出力されれば、次の処理も必要です

コンフリクトの解消

  • コンフリクトとは

    • 編集内容の衝突のこと
    • それぞれのbranchで同じファイルを編集していた際に発生する
    • どちらの編集内容を採用するか決める必要がある
      1
      CONFLICT (content): Merge conflict in <conflict-file>
  • コンフリクトの解消方法

      1. 上記のコンフリクトが発生した各ファイルを開く
    • VS Codeの場合

      • コンフリクト箇所をマーカー表示

        • 緑のマーカー

          • 以下から始まる箇所
            1
            <<<<<<< HEAD (Current Change)
             
          • 現在のbranch側の編集内容
        • 青マーカー

          • 以下から始まる箇所

            1
            >>>>>>> branch-name (Incoming Change)
          • 現在のbranchにmergeしようとしているbranch側の編集内容

      • マーカー上部に表示されるメニュー

        • Accept Current Change
        • Accept Incoming Change
        • Accept Both Changes
        • Comppare
      1. マーカー表示箇所のどちらを採用するか決定
      • 方法は二つ
        • マーカー上部のメニューから選択
          • 例:Accept Current Changeを選択
            • Current branchの内容(緑マーカー)が採用され、Incoming branch(青マーカー)の内容が消去されます
            • つまり、差分を一目で確認して、一押しで取捨選択可能です
        • 要らない方のマーキング箇所を手動で消去
  • ファイルの編集後

    • addまでしてコンフリクトが解消された状態になります
      1
      git add <conflict-file>
  • 確認

    • 赤字でコンフリクト中のファイルが表示されなければOK
      1
      git status
  • Remoteに登録

    1
    2
    git commit
    git push

 今回の解説は以上です。pull, commit, push等のgitの基礎と今回の内容を覚えれば、一先ずチームで分散開発を始めることができると思います。ここで手間取ると初動からPJが遅延するので、未修得のメンバがいれば放置せずに教えてあげましょう。細かい機能は使わないものも多いので、走りながら必要に応じて覚えていけば大丈夫です。

Github.comからGithubEnterpriseへの移行手順

概要

  • リポジトリ移行(Github⇒GHE)の備忘録です
  • 想定する状況
    • Organizationごと中身をまるまる移行したいパターン
    • Commitログ等は特に移行する必要無く、シンプルな手法で手早く終わらせたい
  • 事前調査
    • organization単位の以降はできない
    • リポジトリ単位の移行は可能
    • GHE内に同じ名称のOrganizationやリポジトリを作成可能
      • ★一意性のチェックがGithub側とは隔絶されている

手順

1. GHEでOrganizationを作成

  • Githubと同様の名称で問題無し
    • URLは前半が企業ごとのものに変わる
    • SiteAdmin権限が必要
      • GUIで操作

2. GHEでリポジトリを作成

  • Github.com側と同様の名称で問題無し
    • 空のリポジトリを一通り作成
      • GUIで操作

3. Local端末で移行対象のリポジトリのデータを退避

  • 各リポジトリの中身をデスクトップ等へコピー
  • Gitリポジトリの管理場所:Dドライブから削除
    • この後、GHEから同様の名称のリポジトリをCloneするため
    • Dドライブでlsコマンドを打って削除されたことを確認

4. GHEからLocalへClone

  • 各リポジトリ(空)を端末へClone
    • URLはリポジトリのページの”Clone or download”タブより確認
      1
      git clone <リポジトリのURL>

5. Cloneした空リポジトリに退避データをコピー

  • GHEからCloneした空リポジトリへ、退避場所からコピー

6. GHEのRemoteにデータを登録

  • 各リポジトリで以下の作業を実施する
  • 変更内容を保存
    1
    2
    git add *
    git commit "Repository Migration"
  • Remoteへ送信
    1
    git push

    Github Pagesが含まれている場合

  • _config.ymlに設定する公開URLを変更する必要がある
  • GHEにおけるGithub PagesのURLは以下のようになる
    1
    https://pages.<gheのURL>/<Organization名 or ユーザ名>/<リポジトリ名>.io

7. GHEで確認

  • GHEの問題無くデータが移行できていることを確認

  • Github pagesが含まれていたため、ブラウザで表示されるようにする

  • リポジトリのSettingsより、以下のようにGithub pagesを有効にしてSave

  • GHEにおけるGithub PagesのURLは以下
    1
    https://pages.<gheのURL>/<Organization名 or ユーザ名>/<リポジトリ名>.io

8. Github.comより移行元を削除

  • リポジトリを削除
  • Organizationを削除
    • 管理者権限が必要
@EventEmitter @Input @Output @ViewChild ACM AMP API Gateway AR AR.js AR.js Studio AWS AWS Amplify AWS Budgets AWS Cost Explorer AWS SDK for JavaScript AddThis Adobe XD Alexa Amazon CloudWatch Amazon Honycode Amazon SNS Android Angular Angular Material AngularFire AppSync Augury C CDN CI/CD Cloud Craft Cloud9 CloudFormation CloudFront CloudTrail Cognito Cost Anomaly Detection Cubase ai Cubasis LE DTM Disqus DynamoDB Elgato HD 60S Firebase Firebase Hosting Former2 Github Github Actions Github.com GithubEnterprise GithubPages Google Chrome Google Cloud Shell GraphQL Hexo Hosting IAM Ionic JSON JavaScript LadioCast Logging LowCode MFA MS Authentication MacBook Pro 16 Mind Node NETDUETTO Netflix Party Netlify Network NoCode Observable PO PdM Promise RPA ReactiveForm Recognition Route53 S3 SAM(Serverless Application Model) SAR SSL SYNCROOM Schematics ScrumInc Serverless Service Siri Sitemap Spark AR Steinberg UR44C Teams Touch Cast Studio Treetable TypeScript UI UI Bakery WAF WAFv2 WEB Page Dev WEB会議 WebAR WebSocketAPI Webhook Windows Power Automate Wireshark aot async/await aws config cloud9 display.land draw.io e2e test filter() forkJoin() google search console hexo-generator-amp iOS iPad Pro iPhone icarus map() mat input mat tree mat-checkbox mat-input mat-selection-list mmhmm ngFor plantUML popIn Aladdin2 then() vscode ”global is not defined” らくがきAR アジャイル アジャイル開発 クロスプラットフォーム ショートカット スクラム スクラム開発 テレワーク ファイル操作 ブラウザ型IDE プロダクトオーナー プロダクトマネージャー プロトタイピング リモートセッション 共同開発 双方向データバインディング 待ち合わせ処理 認定スクラムマスター 静的WEB Hosting 静的WEBサイトHosting
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×