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

私は、最適な答えに達することなく、これについて本当に長い間考えてきました。 まず第一に、私はプログラミングを愛する医師ですが、家庭学習と何年もの間自由な時間にコードをいじる以外は、実際に勉強したことはありません。 現在、私は自分のクリニックを管理するための小さなプロジェクトを構築しようとしています。それを行うために、私ができるようにしたいオプションのリストを作成することから始めました。 例： アクティブな患者記録。 さまざまな役割による認証（例：patient、nurse、dr） 予定表（予定表に予定の予防接種/手術などを含む） 医師が独自のプラグインを作成できるようにします。 医師が統計を表示するためのダッシュボード それから、codeigniter / mysql / php / jqueryでコーディングを開始しました。 開発中の私のステップ：- 最初のデータベース。 まず、必要なすべてのテーブルを作成しました。 これらのテーブルを処理するためにすべてのモデルを作成しました（テーブルの関係も考慮しながら、基本的な読み取り/書き込み/更新/検証を処理する1つのマスターモデル その後、ビューとコントローラーのコーディングを開始します。最初にビューHTMLを作成してから、このビューを処理するコントローラーを作成し、ビューの相互作用を機能させるためのコーディング関数を開始しました。 予約ビューをコーディングする場合の例（controller booking.php）： ユーザーがクリックすると、このレイアウトが作成され、テーブルtdがクリック可能になります：jquery get（booking / add_patient_form）and pop up ユーザーが保存するとき：予約/保存に投稿-予定を保存してからindex（）関数を再読み込みします など。そして、ビュー全体とプロジェクト全体を達成するために、このビューに必要なすべてのロジックを含むビューとそのコントローラーを作成する同じステップを続けました。 最後にすべてのターゲット機能が正常に機能しましたが、最初から計画がなく、プロジェクト全体がこれまでに何の計画もなくブレインストーミングとデバッグのパンチであったため、このプロジェクトに行った後、保守性と柔軟性にこだわっています！そしてそれらを一緒にリンクすることはできません。 私は、ウェブサイトのすべてのページが他のページから完全に分離されていると感じています。各ページがどのように読み込まれ、どの機能が内部にあるのかを覗き見ることさえ思い出せません！ とにかくこれを回復してデザインを出すことができますか？

18 php  mysql  design-patterns  workflows 

私はいくつかのプロジェクトをgit flowワークフローに移行しましたが、それが大好きです。ただし、一度に複数のメジャーバージョンが維持されているプロジェクトで作業する場合、物事をスムーズに進めるベストプラクティスは見つかりませんでした。 具体的には、「無料版」や「有料版」などのパラレルモデルを維持していません。バージョン1がリリースされ、マイナーバージョン（1.1、1.2などでサポートされているプロジェクト）について話しているのです。 。）バージョン3がリリースされるまで、その時点で2と3が維持され、4がリリースされるまで... gitflowワークフローでプロジェクトの2つ以上のサポートされているバージョンを一度にどのように維持しますか？

18 git  workflows  gitflow 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 何らかのコードの作業を中断する場合（他の作業をする必要があるか、休暇をとる必要があるか、単に1日の終わりであるため）、そのVisual Studioプロジェクトを閉じた後、覚えておくべき望ましい方法は何ですかそのコードで再び作業を開始したときに次に何をしたいのか。 Visual Studioのブックマークを設定しますか、// TODO: continue here next timeそれとも何か書き留めますか？たぶん、あなたは次のような特別なタグを持ってい// NEXT:ますか？モニターに付箋を置きますか？知っておくべきクールなツールまたはVisual Studioプラグインを使用していますか？ コードで最後に作業したときに中断した場所をコードで見つけるのに役立つ個人的なトリックはありますか？

18 tools  workflows  visual-studio-2010 

私たちのチームは、FogBugz＆Kiln / MercurialからJira＆Stash / Gitに切り替えました。ブランチにはGit Flowモデルを使用し、機能ブランチからサブタスクブランチを追加しています（Jira機能のJiraサブタスクに関連）。プルリクエストを作成して親ブランチにマージするときにStashを使用してレビュアーを割り当てます（通常は開発しますが、サブタスクは機能ブランチに戻ります）。 私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで相互に依存しているコードで作業している場合、機能ケースの最適な計画と内訳でもです。別のブランチでは、1人の開発者が他の開発者をブロックします。 開発中に、お互いのブランチ間をプルしようとしました。また、各開発者が複数のブランチからプルして、開発時に統合をテストできるローカル統合ブランチを作成しようとしました。最後に、これはこれまでのところ私たちにとっておそらく最もうまく機能しているようですが、もう少しオーバーヘッドがありますが、機能ブランチからすぐに統合ブランチを作成しようとしました。サブタスクブランチ（機能ブランチ外）がプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。その後、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルできます。これにより、コードレビューに合格するために依存しているブランチを誰も待つことができなくなります。 これは必ずしもGitの問題ではないことを知っています。これは、独自の作業プロセスと文化が混在する、複数のブランチで相互依存するコードを操作することに関係しています。開発（厳密な統合ブランチ）のための厳格なコードレビューポリシーがない場合、開発者1は、開発者2が引き出せるように開発にマージできます。もう1つの複雑な点は、QAに機能を渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。バックエンド開発者2が終了し、プルリクエストがコードレビューに1週間座っている場合、フロントエンド開発者2はコードレビューアができないため、技術的にプルリクエスト/コードレビューを作成できませんバックエンド開発者2 'のためのテスト 結論として、これらのインスタンスでは、どのルートに行くかに応じて、パラレルではなくはるかにシリアルなアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。 最後に言及することは、コードのレビューとファイナライズが完了していないブランチ間でコードを共有することで実現していますが、本質的には他のベータコードを使用しています。ある程度まではそれを避けることはできないと思いますし、ある程度それを受け入れるつもりです。

17 git  workflows  branching  jira  gitflow 

前提条件 チームはDVCSを使用します IDEはコメントの解析をサポートしています（TODOなど） CodeCollaboratorのようなツールは予算的に高価です gerritのようなツールはインストールするには複雑すぎるか、使用できません ワークフロー 著者は中央リポジトリ機能ブランチのどこかに公開しています レビュー担当者が取得してレビューを開始します 質問/問題レビューアの場合、「REV」などの特別なラベルを付けてコメントを作成します。そのようなラベルは、製品コードに含めることはできません-レビュー段階でのみ： $somevar = 123; // REV Why do echo this here? echo $somevar; レビュアーがコメントの投稿を完了すると、愚かなメッセージ「comments」でコミットし、プッシュバックします 作成者は機能ブランチをプルバックし、同様の方法でコメントに回答するか、コードを改善してプッシュバックします 「REV」コメントがなくなると、そのレビューは正常に終了したと考えることができます。 作成者は機能ブランチをインタラクティブにリベースし、それを押しつぶしてそれらの「コメント」コミットを削除します。これで機能をマージして、通常は内部レビューが正常に完了した後のアクションを開発または実行する準備ができました IDEサポート 私は、カスタムのコメントタグがEclipseとNetBeansで可能であることを知っています。確かにそれはblablaStormファミリーにもあるはずです。 ご質問 この方法論は実行可能であると思いますか？ 同様のことを知っていますか？ それで何を改善できますか？

16 teamwork  code-reviews  workflows  dvcs 

私は、スクラム方式を使用したソフトウェア開発会社において、継続的インテグレーションワークフローがどのように適合するかをよりよく理解するためのアプローチを研究しています。 私はこのようなことを考えています： それは素晴らしいワークフローでしょうか？

16 testing  development-process  scrum  continuous-integration  workflows 

現在、gitワークフローを使用しているチームとプロジェクトに取り組んでいます。マスターはデプロイ可能な状態であり、機能とホットフィックスを作成するためにブランチが使用される必要があります。機能またはバグ修正が完了してテストされたら、できるだけ早くマスターに移行します。アイデアは、ブランチをできるだけ小さくして、それらをマスターにマージしやすくすることです。masterブランチにプッシュされたコードはデプロイ可能な状態にして、テストに合格するというポリシーがあります。 開発者の1人が1つのブランチで多くの作業（数か月分）を行っており、このブランチがまだマスターにマージされていない状況があります。現在、このブランチにはいくつかの別個の機能と多数のコミットがあります。本質的に、このブランチは実際には数回ですでにマージされているはずですが、今のところそうではありません。ほとんどのコードは、マスターに戻すことができる単体テストで良好な状態にありますが、最新の変更は、完了しておらずテストされていないため、確かにそうではありません。 あるブランチが他のブランチから本当に遠く離れているような状況に対処する最良の方法は何ですか？将来、ブランチがマスターから非常に多くのコミットを取得するのを避ける方法はありますか？

15 git  workflows 

これは少し奇妙に聞こえるかもしれませんが、何らかの方法でネットワーク接続された複数のマシンからGitで作業する良い方法について疑問に思っています。私には2つの選択肢があるように見えますが、両方の利点があります： 共有にはgit自体を使用します。各マシンには独自のリポジトリがあり、それらの間でフェッチする必要があります。 他のマシンがオフラインであっても、どちらのマシンでも作業できます。これ自体はかなり大きいと思います。 マシン間のネットワークで共有される1つのリポジトリを使用します。 コードは常に最新であるため、マシンを切り替えるたびにgit pullを実行する必要はありません。 このマシンでファイル共有を使用して作業を行っていたため、他の非ホスティングマシンからコードをプッシュするのを忘れたことを心配しないでください。 私の直感では、一般的に誰もが最初のオプションを選択します。しかし、私が見る欠点は、常に他のマシンからコードにアクセスできるとは限らないことであり、毎日の終わりにすべてのWIPブランチをgithubにプッシュしたくないことは確かです。また、コンピュータから直接取得できるように、常にコンピュータの電源を入れたままにする必要はありません。最後に、複数のブランチを最新の状態に保つためのすべてのgitコマンドが退屈になる可能性があるという小さな点があります。 この状況に3番目の対処法はありますか？このプロセスを簡単にするサードパーティのツールが利用できる場合がありますか？この状況に定期的に対処する場合、何を提案しますか？

15 git  workflows  dvcs 

私は現在プロジェクトに取り組んでおり、Githubのプライベートリポジトリにソースコードがあり、私たちはそれぞれ共同作業者です。 不明な点は、各作業を分離する方法です。 私たちがする必要があると思うことは： リポジトリをフォークする必要があります コードをプッシュする準備ができたら、プルリクエストをプロジェクトリーダーのレポジトリに送信します。レポジトリは、これを同時にコードレビューを行う機会として使用できます プライベートリポジトリに関しては、これはフォークを使用することになっているのでしょうか、それとも状況を複雑にしすぎていますか？

14 project-management  git  workflows  forking 

奇妙なタイトル、はい、しかし、私は私が思うにカバーするために少し地面を持っています。 プライベートリポジトリを持つgithubに組織アカウントがあります。githubのネイティブな問題/プルリクエスト機能を使用したいと思います（プルリクエストは、基本的にコードレビューと機能の議論に関する限り正確です）。私たちは、ツール見つかったハブをすることによってディファンクトプル要求に既存の問題を変換し、自動的にそれをあなたの現在のブランチを関連付けることができるというクールなのはほとんどの機能があります。 組織内の各開発者が組織のリポジトリをフォークして、機能の作業/バグ修正などを行うのがベストプラクティスかどうか疑問に思っています。これは非常に堅実なワークフローのように見えます（基本的にはgithubのすべてのオープンソースプロジェクトが行うことです）が、問題を追跡し、組織のリポジトリである1つのソースから要求をプルできることを確認したいと思います。 そこで、いくつか質問があります。 この場合、開発者ごとのフォークのアプローチは適切ですか？それは少しやり過ぎのようです。直接プッシュアクセスを持たず、すべてのコードをレビューする必要がある開発者を紹介しない限り、すべての開発者にフォークが必要かどうかはわかりません。その場合、それらの開発者だけにそのようなポリシーを制定したいと思います。それで、どちらが良いですか？すべての開発者が単一のリポジトリにあるのか、それともみんなの分岐点なのか ハブツール、特にプルリクエスト機能の経験はありますか？開発者ごとにフォークを行う（または特権の低い開発者向け）場合、ハブのプルリクエスト機能は、上流のマスターリポジトリ（組織のリポジトリ？）からのプルリクエストを処理しますか、それとも異なる動作をしますか？ 編集 私は問題、フォーク、プルリクエストでいくつかのテストを行い、それを見つけました。組織のリポジトリに問題を作成した場合、組織からリポジトリを自分のgithubアカウントにフォークし、いくつかの変更を行って、フォークのマスターブランチにマージします。実行しようとするhub -i <issue #>と、エラーが発生しますUser is not authorized to modify the issue。したがって、明らかにそのワークフローは機能しません。

14 version-control  git  teamwork  github  workflows 

私は、計算幾何学やグラフィックス、およびこれらの種類のトピックに触れる多くの（主にc ++およびjavascript）コードを書くので、視覚図は問題を解決するプロセスの不可欠な部分であることがわかりました。 「ああ、手書きの図をなんらかの方法でコメントとしてコードの一部に添付できたら素晴らしいのではないか」と判断しました。これにより、私が取り組んだものに戻ることができます。数日、数週間、数か月前、そしてはるかに迅速にアルゴリズムを再作成します。 視覚的な学習者として、単純な図はあらゆるタイプの非自明なデータ構造に関する理解と推論に役立つため、これはほとんどすべてのタイプのプログラミングで生産性を向上させる可能性があると感じています。たとえばグラフ。大学でのグラフ理論の授業中、私は実際に図式表現を描くことができるグラフ関係を本当に理解することができただけでした。 そう... 私の知る限り、IDEを使用して写真をコードへのコメントとして保存することはできません。 私や他の誰かが、イメージをbase64バイナリ文字列に変換してコードに挿入できる、かなり使いやすいツールを考え出すことができると考えました。 変換/挿入プロセスを十分に合理化できれば、ダイアグラムと実際のコードの接続がはるかに良くなるため、ノートブックを時系列に検索する必要がなくなります。さらに素晴らしい：IDEのプラグインが自動的に画像を解析して表示します。理論的な観点から、これについて絶対に難しいことはありません。 私の推測では、お気に入りのIDEを拡張し、これらのプラグインを維持する方法を実際に把握するには、余分な時間がかかるので、同じ解析を行う一種のコードポストプロセッサに完全に満足し、画像をレンダリングして、コードをブラウザや何かの中に並べて表示します。私は貿易でjavascriptプログラマーだからです。 人々はどう思いますか？誰もこれにお金を払うでしょうか？私は...するだろう。しかし、私は、私またはかなりの数の同僚がそのようなものにお金を払うかどうかに関係なく、そのようなものが成功する可能性が高い唯一の方法は、オープンソースのリリースを通じてであることを指摘するでしょう。

14 productivity  code-reviews  comments  workflows  image-manipulation 

通常、プログラムを作成するときは、明確なタスクが先にありますが、迷惑なものを見つけて、進行中にクリーンアップしたいと思います。 ここには3つのオプションがあります。 後で実行します（チケットを追加するのを忘れたり、時間を費やす必要がある場合があります） 今すぐ実行し、現在の作業と一緒にコミットします（不明） 今すぐ実行し、個別にコミットします（それを見つける必要があり、間違いを犯し、意図せずにオプション2に進む可能性があります） これはおそらくかなり基本的なことですが、svn / git / otherを使用してこれを回避する方法は何ですか？

12 version-control  git  svn  workflows 

私はオープンソースの世界は初めてです。私が取り組んでいるプロジェクトはGithubにあります。（参照用）私が取り組んでいるプロジェクトは、Plex Media Serverのプラグインです。プラグインをPlexに送信して、それらが「アプリストア」に含まれるようにする予定です。今私の質問に。 私が最初に始めたとき、私は私が望むもののいくつかをしたがあまり良くない古い半放棄されたプラグインを見つけました。私はそのレポに貢献することから始めました。現在の所有者は忙しすぎてそれを台無しにできないと言ったので、私はすぐにレポに対する完全な権利を持つ共同作業者になりました。しかし、コードをさらに掘り下げ始めたとき、それが無駄であることに気付きました。既存のコードベースはひどいものであり、それを修正する効率的な方法はありませんでした。ゼロから始めただけです。新しいプラグインで使用したコードは、最初にコミットしたコードのみでした。 これで、プロジェクトをリリースする準備ができました。しかし、私はこれをどのように行えばよいのかわかりません。次のようにオプションが表示されます。 新しいレポを作成し、既存のものを忘れてください。以前のレポやその貢献者についても言及すべきかどうかはわかりません。そのコード/リソースを使用せず、まったく新しいコードベースを作成しました。プラグインは古いプラグインと同じことをいくつか行いますが、まったく新しい方法でより効率的な方法で行います。 既存のレポをフォークし、既存のコードを削除して、新しいコードをコミットします。私はGitが初めてなので、これが可能かどうかはわかりません。 既存のレポジトリに変更をコミットし、現在の貢献者がどのように言っているかを確認します。 3つの選択肢のうち、最初の方に強く傾倒しています。だが！私はオープンソースが初めてなので、適切なエチケットに従って仕事をしていることを確認したいと思います。私の最初のプロジェクトが目の前で爆発し、災害になりたくありません。オプション2の音は悪くありませんが、それを行うべきかどうかはわかりません。履歴と差分がどのように機能するかわかりません。せいぜい500〜1000行程度のコードです。したがって、それは巨大なコードベースではありません。 あなたが提供できる入力をありがとう！

12 open-source  github  workflows  etiquette 

私は個人的なワークフローを考え出そうとしています。リリースの架空の寿命のフローチャートを作成しました。ある開発者が公開githubリポジトリにプッシュし、友人が何らかの機能を手伝ってバグを修正しました。 これはバージョン管理の合理的なアプローチですか？ 主なアイデアは、パブリックリポジトリを整理することです。 新しいリリースはそれぞれ、終了時にマスターブランチで最終的にタグ付けされるまで、独自のブランチになります。 すべての作業は、異常を防ぐために、実際のリリースブランチではなく、「機能」または「ホットフィックス」ブランチで行われます。 高レベルのブランチへのマージは、常にリベースまたはスカッシュされます（混乱を避けるため）。 やり過ぎだとしても、大事なプロジェクトに必要なスキルを習得することが全体的な目的なので、気にしません。唯一の問題は、私が間違っているか不必要なことを完全にやっていることです。 編集2：元のフローチャートの悪い考えを修正し、ナビゲートしやすくしました。

12 project-management  programming-practices  version-control  git  workflows 

git、maven、およびjenkinsを使用して次のことを行うための好ましい方法は何ですか： 「dev」ブランチと「release」ブランチを維持したいアプリケーションを開発しています。ジェンキンスに両方を構築してほしい。リリースアーティファクトのバージョンが1.5.2になり、開発ビルドが0.0.1-SNAPSHOTになるだけになる可能性があります。2つの異なるpom.xmlファイルを持つ必要はありません。 プロファイルを調べましたが、アーティファクトのバージョンを変更できないようです。私が見た1つの方法は、テストビルドに「修飾子」を追加することです。もちろん、ファイルの名前を変更することもできます。これは、アプリがスタンドアロンのものであるため、これに関する実際のアーティファクト情報は重要ではないからです。 これを行うための好ましい方法は何ですか？または、これをどのように行いますか？

12 git  workflows  versioning  jenkins  maven