サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
VP ofTechnology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティやAWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時はPDF で保存 版管理は Word の編集履歴 +PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
The document describes various Git commands andworkflows for managing branches and changes.It shows how to clone a repository, check out atopic branch, commit changes, rebase and merge branches, resolve conflicts, revert commits including merges, and cherry-pick commits. Key steps include checking out branches, committing code, pulling latest changes, rebasing and merging branches, resolving co
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim とEmacs やLinux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
GitFlowの説明 GitFlowのグラフ GitFlowにあるブランチの説明 masterブランチ、developブランチがメイン featureブランチ、releaseブランチ、hotfixブランチが補助 masterブランチは常にリリースできる状態 developブランチから、featureブランチを切って開発を進める featureブランチは機能追加用(通常の開発用) releaseブランチはdevelopブランチからブランチを切ってリリース直前用（例：受入テスト、総合テストのため利用） hotfixブランチはリリース後の緊急対応用 GitFlowの流れ フェーズ1:開発フェーズ 1.developブランチからfeatureブランチを切って、開発 2.他の人が開発したら自分のfeatureブランチにマージ 3.開発が終わったらfeatureブランチをdevelopにマージして、f
会社のブログに書こうかと思ったけれど、ちゃんと調べられてないのでメモがてらQiitaに書いておく。本稿ではチーム開発においてフローを選ぶ際のポイントについて述べる。 TL;DR 運用フローは次のポイントに注意して選ぶと良い。 リリースサイクルの長短（長く計画的 or 短くアドホック） メンテするバージョンの数（1つ or 多数） 並行して開発するバージョンの数（1つ or 複数） フロー リリース メンテ 開発github-flow 短 1つ 複数git-flow 中 1つ 1つ stable trunk 中〜長 1つ 複数 mainline 中〜長 複数 1つ git運用フローとは VCS一般には「ブランチ戦略」とも言われる。 ここでは以下のように定義する。 git(VCS)を使う上で、どのブランチで作業し、 どのタイミングでブランチを分け、マージするかを定めたルールのこと。 よく
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Gititself came into being. In those 10 years,git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treatingit like a standard of sorts — but unfortunately also as a dogma or panacea. Du
# aというファイルを追加し、一旦コミットする $ git commit -m "add a file" # その後、aに修正を入れる $ git status Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: a # <- aが修正されている $ git add . # 変更をインデックスに登録 $ git commit --amend --no-edit # 登録されたインデックスを直前のコミットにまとめる $ git status On branch master nothing to co
問題 git push しようとしたら、rejectされた。どうしよう。 C:\tmp\gittest\testB>git push c:\tmp\gittest\test master To c:\tmp\gittest\test ! [rejected] master -> master (non-fast-forward)error: failed to push some refs to 'c:\tmp\gittest\test' hint: Updates were rejected because the tip of your current branch is behind hint:its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again.
Subversion vsGithub 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか？ 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である（ｷﾘｯ」by @HIROCASTER さんGithubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します！ (Piece of Cakeさんを追加しました。） (サイボウズさんを追加しました。） これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 ＼（サイボウズ）／ ＼（ペイパーボーイ）／技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
久しぶりにHeroku で運用しているサービスを修正しようとしたらプッシュするときにエラーが発生したのでメモ。 まずは clone。 $ git clone git@heroku.com:{repos-name}.git もろもろ修正したあと、push。 $ git pushheroku master fatal: 'heroku' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 怒られる。 .git/config を確認してみる。 $vim .git/config [remote "origin"] url
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus): 大塚 弘記: 本
Amazon.co.jp: 【改訂新版】Gitポケットリファレンス: 岡本隆史, 武田健太郎, 相良幸範: 本
Amazon.co.jp: Gitポケットリファレンス: 岡本隆史, 武田健太郎, 相良幸範: 本
