タグ付けされた質問 「workflows」

私はこの質問を何度も何度も熟考しています。私は物事を正しい方法でやりたいと思っています：保守しやすい、クリーンで理解しやすい正しいコードを書くことです。しかし、私がやることは、パッチの上にパッチを書くことです。時間がない、クライアントが待っている、バグを一晩で修正する必要がある、会社がこの問題でお金を失っている、マネージャーが一生懸命押すなどの理由で。 長期的にはこれらのパッチにより多くの時間を浪費していることを私は完全によく知っていますが、今回は数か月にわたる作業なので、誰も気にしません。また、私のマネージャーの一人が言っていたように、「今すぐ修正しないと長期になるかどうかわかりません。」 これらの無限の現実/理想の選択サイクルに巻き込まれているのは私だけではないと確信しています。私の仲間のプログラマー、あなたはどのようにこれに対処しますか？ 更新：この興味深い議論に感謝します。非常に多くの人々が、コードの量と品質の間で毎日選択しなければならないのは悲しいことです。それでも、驚くほど多くの人々が、この戦いに勝つことができると考えているので、この励ましに感謝します。

180 project-management  programming-practices  management  workflows  software-schedules 

gitを学んでいますが、2段階のコミットプロセスがあることに気付きました。 git add <files> git commit 最初のステップでは、リビジョンを「ステージング領域」または「インデックス」と呼ばれるものに配置します。 私が興味を持っているのは、この設計上の決定が行われる理由と、その利点は何ですか？ また、gitユーザーとしてこれを行うか、単に使用しgit commit -aますか？ この機能を持っていないbzr（Bazaar）から来たので、これを尋ねます。

174 version-control  git  workflows 

私はCVS-crazyとBugzilla-nutsのある場所で働いています。 各リリースには非常に多くのブランチがあるため、それらをカウントすることはできません。誰もが絶えず自動マージされています。 この仕事には流動性がありません。すべてがロックステップを感じます。簡単なことでも25ステップかかります。工場の生産ラインにいるようなものではありません。毎日自分で工場を立ち上げるようなものです。 状況の例： 単一のバグを修正するには、最初にクリーンで新しい仮想マシンを入手します。次に、Bugzillaレポートで説明されている別のブランチに基づいて、その単一のバグ修正用のブランチを作成します。マシンにブランチをインストールし、セットアップします。バグを修正します。私はそれをチェックインし、他の人がテストするためにマシンとマシンを残します。次に、バグ管理ソフトウェアにアクセスして、自分が何をしたかを説明し、すべての手順でテストケースを作成する必要があります。最終的に他の誰かがそれをリリースとマージします。 どんなに小さなバグであっても、これらすべてのことをしなければなりません。時々、人々は複数のバグの作業を結合しますが、私が言ったように、これはほとんど不可能であるほど多くのブランチがあります。 他の仕事では、バグを修正するだけです。私が持っていたすべてのジョブがそれを使用していますが、私はかろうじてさえ、SCMを使用して覚えている：他のすべての仕事で、彼らは何とかそれを守っているからです邪魔になりません。 プロセスが邪魔をして、それ自体で終わりになるポイントはありますか？それもエンジニアリングですか？

50 issue-tracking  workflows  svn 

同じソフトウェア/プログラム/アプリ/スクリプトの2つの異なるバージョンを作成し、バージョン管理下に保存しているとしましょう。最初のバージョンは無料の「ベーシック」バージョンで、2番目は有料バージョンの「プレミアム」バージョンで、無料バージョンのコードベースを取得し、いくつかの付加価値機能で拡張します。新しいパッチ、修正、または機能は、両方のバージョンへの道を見つける必要があります。 現在、有料版のサイドとブランチに沿って、メインコードベース（無料版）のブランチを使用することmasterを検討していdevelopます。無料版に変更が加えられ、ブランチにマージされると（もちろん徹底的なテストの後）、さらにテストするためにコマンドを介してブランチにコピーされ、にマージされます。master-premiumdevelop-premiummasterdevelopdevelop-premiumcherry-pickmaster-premium これは、この状況を処理するのに最適なワークフローですか？認識すべき潜在的な問題、警告、または落とし穴はありますか？私がすでに思いついたものよりも良い分岐戦略がありますか？ あなたのフィードバックは大歓迎です！ PSこれはGitに保存されているPHPスクリプト用ですが、回答はすべての言語またはVCSに適用する必要があります。

45 version-control  workflows 

私は過去にいくつかのワークフローエンジンでプログラマーとして働いてきましたが、なぜワークフローエンジンを最初に選んだのかについて明確にすることはありませんでした。そして、プログラマーとして、コードを書いているときに何かをする方法が少なくとも100あることを知っていますが、最良の方法はごくわずかです！ 優れたDI対応アプリケーションを設計することよりも、どのユースケースがワークフローエンジン（またはその概念）によって最もよく解決されるかはまだわかりません。ワークフローエンジンが最適なオプションの1つである、ドメインに中立なユースケースの一般的な特性を探しています。 私の質問は次のとおりです。要件の一般的な特性は、優れたワークフローエンジンを選択し、その周りにコーディングするためのシグナルと見なすことができますか？

41 workflows 

だから私はGitHubで私の本当のプロジェクトを始めました。物事はかなり順調に進んでおり、アイデアは当初思っていたよりもずっと速く流れていました。物事を整理するために、いくつかのブランチをセットアップして、異なる機能を個別に開発できるようにします。 私はGitHubのに私の枝を押すと今、私は私は2つのボタンがあり、そのセクションがありますPull Requestし、Compare私は最近にプッシュブランチの名前を持ちます。Compareボタンの目的は理解していますが、自分のリポジトリでプルリクエストを作成する理由がわかりません。 誰かが私がそうする理由を説明できますか？自分が唯一の開発者である場合、自分のリポジトリでプルリクエストを行うことは有用ですか？

38 github  workflows 

現在、4台または5台のコンピューターがあり、すべてを同期するためのより良いシステムが必要です。私はgitとgithubを使用してプログラミングプロジェクト用にファイルを同期していますが、データベース、.bash_profileファイル、bashスクリプトなどがあります。ファイルを同期する代わりに、あるコンピューターから別のコンピューターにsshするだけです。しかし、これはかなり混乱しています。私のコンピューターのいくつかはUbuntuであり、他のコンピューターはOS Xです。 複数のパソコンにまたがるワークフローを管理するための提案はありますか？

31 development-environment  workflows 

私の会社はGitを使用しており、独特の分岐スキームを使用しています-作業はマスターで行われ、分岐はリリース用に予約されています。これは、反復で行われたすべての作業がブランチに行われる限り正常に機能しますが、重大な生産上の問題が発生した場合、作業が何らかの方法で両方のブランチに行われるようにする必要があります。 最近、私たちはそれらのブランチで「楽しい」ことをしてきました。これは管理上の頭痛の種であり、すべての作業がすべてのブランチに反映され、1つのブランチで修正された一部のバグは、誰かが指摘するまでマスターになりません。 しばらく前にGit Flowに出会いましたが、それが私たちの問題の解決策だと感じています-コードがリリースまで浸透していないか、ずっと下に浸透していません。唯一の問題は、私のリードがこの種の開発はアンチパターンであると述べていることです。つまり、2週間にわたって猛烈に開発し、マージの競合を解決するために3を費やしました。 同意するかどうかは定かではありませんが、それを育ててから、仕事は通常のように再開しました。ごく最近になって、これに関していくつかの大きな問題がありました。 私は知りたい-なぜこの種の開発スキームはアンチパターンと見なされるのですか？ で、それは本当にアンチパターン？

30 git  workflows  branching  gitflow 

組み込みデバイスやその他の奇妙な世界向けに開発する場合、ビルドプロセスに非常に特殊なバージョンを使用する複数の独自のバイナリが含まれる可能性が非常に高くなります。質問は、ソース管理の一部ですか？私のオフィスでは、「ソース管理からのチェックアウトにはコードをコンパイルするために必要なすべてが含まれます」というルールに従っており、これはいくつかの深刻な議論につながっています。 これに対する主な議論は、ソース管理DBの肥大化、バイナリファイルの差分の欠如です（この件に関する以前の質問を参照）。これは、前の開発者が意図した正確な環境があることを確認し、ビルドし、適切なファイルを探し出すことなく（特定のバージョンも同様に！）

30 version-control  workflows 

最近、私と私のチームがGitをどのように使用し、ワークフローがどのように機能するかを調べてきました。現在、機能ブランチワークフローを使用していますが、うまく機能しているようです。 また、私たちのチームの何人かの個人がgit stashに基づくワークフローを使用しているのを見ました。ワークフローは次のようになります。 メインブランチで作業する（などmaster） 進行中にコミットする 変更を取得するか、ブランチを切り替える必要がある場合は、コミットされていない変更をスタッシュにプッシュします 更新が完了したら、変更をスタッシュからポップします。 このワークフローは、機能ブランチワークフローの代わりに使用されることに言及する必要があります。ここでの開発者は、ブランチを取得して作業する代わりに、単一のブランチでのみ作業し、適切と思われるスタックからプッシュ/ポップします。 実際、これは素晴らしいワークフローではないと思うので、この方法でgit stashを使用するよりも分岐が適切です。git stashの価値は緊急操作として見ることができますが、毎日の通常のワークフローで使用することはできません。 git stashを定期的に使用することはアンチパターンと見なされますか？その場合、発生する可能性のある特定の問題は何ですか？そうでない場合、利点は何ですか？

25 git  teamwork  workflows 

現在、TDDについて学び、個人プロジェクトでTDDを実践しようとしています。また、これらのプロジェクトの多くでバージョン管理を広範囲に使用しました。私は、特にコミットを小さく保つという格言に関しては、典型的なワークフローにおけるこれら2つのツールの相互作用に興味があります。ここに思い浮かぶいくつかの例があります： 新しいプロジェクトを開始し、まだ存在しないクラスを作成する簡単なテストを作成します。テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか？または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブアウトする必要がありますか？ バグを見つけ、テストを作成して再作成します。失敗したテストをコミットするか、バグ修正を実装してからコミットする必要がありますか？ これらは、すぐに思い浮かぶ2つの例です。回答に追加の例を提供してください。 編集： 両方の例で、テストを書いた直後にテストをパスするコードを書くと仮定しました。別の状況も発生する可能性があります。私は、コミットせずに数時間TDDを使用してプロジェクトに取り組んでいます。最終的にコミットするとき、作業を小さなチャンクに分割します。（Gitは、1つのファイルの一部の変更のみをコミットしたい場合でも、これを比較的簡単にします。） これは、私の質問は、いつコミットするかということと同じくらいコミットすることに関することを意味します。

25 version-control  tdd  workflows  personal-projects 

私の同僚が、私が面白いと思うアイデアを思いつきました。 TDDを行わないと想定してレビューを行う人が、コードレビュー中にテストを書くことは有益ではないでしょうか。 この質問では、これは純粋にアカデミックなプロジェクトであり、命にかかわることはないと想定しています。さらに、チームは4人です。誰もが言語を知っており、使用されるすべてのツール/ライブラリ/フレームワークに精通しており、テストを書くことができます。したがって、基本的には、上級のフルスタックではない人が忍者のエンジニアをリードしていますが、まともなコーダーです。 私が見つけた長所： レビュー中にコードのより深い理解を促し、意味のあるテストを作成します。 次に、テスト対象のコードの作成者が行ったテストのコードレビューを追加できます。 短所： コードの作成とテストの間のフィードバックループが拡大します。 編集：私はそれが「通常の」Webアプリケーションではうまく動作しないことを知っています。私が念頭に置いていたのは、細部に注意を払う必要のある複雑で科学的なアルゴリズムを実装するコーナーケースです。独自のグラフライブラリ、NLPなどの実装のようなものを想定しましょう。作成しているコードがデータベースから分離されているなど、理解するのが非常に難しいのは、ソースを理解する必要のある他の人ではありませんコードを作成し、意味のあるテストを行い、プロセス全体を、アプリケーションをクラッシュさせず、最終的に結果をゴミにするようなそれほど明白ではないバグを起こしにくくしますか？

24 programming-practices  unit-testing  testing  teamwork  workflows 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私はワークフロー開発に不慣れであり、「全体像」を実際に得ているとは思わない。あるいは、別の言い方をすれば、これらのツールは現在私の頭の中で「クリック」していません。 そのため、企業はプロセスを説明するビジネス図面を作成するのが好きで、ある時点で誰かがプログラムのようなステートマシンを使用して、図のような線やボックスからプロセスを実際に制御できると決めたようです。10年後、これらのツールは巨大で非常に複雑になりました（私の会社は現在WebSphereで遊んでいます。私はトレーニングに参加しました。巨大で複雑ですが、WebSphereである獣ほど複雑ではありません）。 この方法で行うことの大きな利点は何ですか？単純な線図とボックス図が有用であることはある程度理解できますが、これらのことは、私が知る限り、この時点では条件とループを備えた視覚的なプログラミング言語です。ここのプログラマーは、ラインとボックスのレイヤーでかなりの量の作業を行っているように見えますが、私にとっては、本当にくだらない、本当に基本的な視覚プログラミング言語のように見えます。 そこまで行くなら、なんらかのスクリプト言語を使用してみませんか？人々はこれでお風呂の水で赤ちゃんを投げ出しましたか？線と箱のことはばかげたレベルになっていますか、それとも私はこのすべての価値を理解していないのですか？ この技術を使って働いた人々がこれを擁護する議論を見て、なぜそれが役に立つのかを理解したいと思います。私はそれに価値を見ませんが、私もこれに慣れていないことを認識しており、まだ十分に理解できないかもしれません。

22 java  workflows  soa  bpm 

私はGitHubとVCS全般に不慣れです。私は何年もさまざまな言語でプログラミングを行ってきましたが、カスタムプロジェクトでは常に単独で作業していました（公開リリースはありません）。最近、作業中のプロジェクトでGitHubからダウンロードしたjQuery UIウィジェットの使用を開始しました。リポジトリは元の作成者によって維持されなくなりました。別のフォークには、元のプルリクエストの一部が組み込まれています。これは私がフォークしたものです。 いくつかのバグを発見し、それらの修正を考え出しました。私はこれらの修正に貢献したいと思いますが、私たち自身の使用のために、既存の機能のいくつかを破壊する他の多くの変更もしたいと思います。さらに、別のフォークのアイデアを取り入れたいと思います。 私はまだGITとGitHubを学んでおり、あらゆることを行うための最善の方法を見つけようとしています。さまざまな概念/タスク（ワークフロー、マージ、プルリクエスト、チェリーピッキング、リベース、ブランチ）について多くの読書（ここでは、SO、GitHubヘルプページ、Pro Git）を行いました。私の灰白質は泳いでいるので、読み始めたことを理解するために、始めなければなりません。 主な問題： 私は（どこかに）一度にブランチ上でプルリクエストを1つしか持つことができないと読んだと思います。つまり、バグごとに個別のブランチを作成し、それぞれに個別のプルリクエストを実行する必要があるということですか？ 空白の問題をクリーンアップしたいのですが、これを別のコミットで行うのが最善であると読んだことを覚えているようです。これをマスターまたは別のブランチで行う必要がありますか？些細なことに対してプルリクエストをしたくありませんが、ブランチする前に空白を変更すると、バグ修正のためのプルリクエストに影響しますか？一部のフォークは空白のクリーンアップを行い、事実上、diffをかなり役に立たなくしました。 私はすでにバグを修正しているにもかかわらず、バグを文書化する方法として、フォークに対して問題を作成することを考えていました。それは良い考えですか？問題、コミット、およびマスターへのマージをリンクするにはどうすればよいですか？アップストリームでプルリクエストを行うと、問題もアップストリームに表示されますか、それともドキュメントのリンクが失われますか？アップストリームリポジトリに対して問題を開くことができません（[問題]タブはありません）。 私が使用したい他のフォーク作成者のアイデアを他のフォーク作成者に与える最良の方法は何ですか？特に彼の変更はアップストリームの古いバージョンに対して適用され、他の変更とは互換性がないため、私は彼のコードを正確に使用することはできません。しかし、私はこのアイデアを使いたいですし、クレジットが支払われるべきところでクレジットを与えたいです。コミットメッセージで彼のレポ（またはプロファイルまたは特定のコミット）にリンクするだけですか？ メインファイルの上部にあるREADMEファイルとDocBlockの変更に関するエチケットは何ですか？変更を行い、名前を追加し、リポジトリとデモへのリンクを追加し、元のデモへのリンクを削除しても構いません（私のフォークは元のデモと互換性がないため）もちろん、元の著者名とライセンス情報は残しておきます。記録のために、それはMITライセンスの下でライセンスされています。 VCSを使用したことがないソロ開発者として、私はhistoryを書き換えることに慣れています。私は完璧主義者で、きちんと整理整頓することが好きです。歴史を記録するという考えは私を少し緊張させています。プレイ/学習するための新しいリポジトリを作成しましたが、jQuery UIウィジェットの修正を進めて、プロジェクトを進めることができるようになりたいと思っています。

21 open-source  github  workflows  etiquette 

私たちは約200人の開発者で構成される組織であり、特定の日にリリースされる予定の1つの製品（リビジョン管理Gitを使用）で継続的に作業しています。 開発者が非常に多いため、各チームに約10人の開発者がいる「クロスファンクショナル」チームを作成しようとしています。その結果、組織内に約20の開発チームができます。 メインリポジトリ内の製品の継続的な「高水準」（開発者がプルするとき、製品が少なくともコンパイル可能であることなど）を維持したいので、何らかの品質ゲートを使用したいと思います。 質問の言い方が少しわかりませんが、単一の製品に取り組んでいるこのような大規模な開発者グループの開発方法論に関するアドバイスを得ることができるかどうか疑問に思っています。 私たちの意見では、スペクトルの一端は各開発者がメインリポジトリに直接コミットできるようにすることですが、開発者/コミットの数が多いため、「メインリポジトリ」が常に壊れた段階にある可能性があることを恐れていますコミットごとに厳しい「品質ゲート」を持つことはできません。 スペクトルのもう一方の端は、（メインリポジトリ）に3つのプルソースのみがあり、これら3つに少数の信頼できるプルソースのみがあるツリーまたはピラミッド構造のようなものです（Linus Torvalds / Linuxが行うと思います）しかし、そのような構造では、変更が「メインリポジトリ」に入るために登るには長いチェーンがあると感じています。さらに、マージの競合が発生した場合、「元の開発者」以外の別の開発者に問題が発生します。 この背景情報と意見をすべて述べた上で、非常に多くの開発者に推奨される開発方法論をどのように学び、読むことができますか？大規模な組織（Microsoft、Facebook、Ubuntuなど）はどのように開発を構成していますか？

19 agile  workflows  software  development-methodologies  gitflow