GitHub Community
Looking for git workflow idea for short, infrequent sprints #21874
-
|
Hi! We just got a legacy project (asp.net mvc app of, say - questionable - quality), are four developers plus one product owner (we do scrum) and we are supposed to work on it for one or two days every month, possibly even less, i.e. a couple of days every few months. The current flow is that we branch features off develop and have no other branches. The workflow is that
The problem I have is that, due to the short duration of the sprint, we can’t really merge stuff back to develop for other feature branches to be updated with finished features. So, bugs introduced by merging are discovered late, if at all. Also, we have three kinds of tasks:
Now, is the flow we have ok for these tasks? Should we use different ways of working with the different task categories? Would the full git flow be an advantage? Or does anyone have an even better idea? Any help would be greatly appreciated. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
This isn’t really a Git question, but more of a general software development philosophy question 😀 It sounds to me like the lion’s share of the testing occurs in step 2 of your flow and step 4 is more of a “sanity check”. If you’re not catching enough bugs pre-merge, then your process should focus its testing effort on testing post-merge. Your three classes of changes are pretty much standard. Every software project has some of each of those changes. I’m not sure what you mean by “the full git-flow”. It sounds like you’re doing that already. Here’s the process that we recommend for use on GitHub. We recommend this process for changes of all sizes. If some changes are particularly large or long-running, then we tend to merge from the default branch ( Do you have automated tests helping with the testing workload? |
Beta Was this translation helpful? Give feedback.
-
|
I think that has cleared it up for me beautifully, including that link to the flow you use. Thanks a lot! (Yes, we do have automated tests, which could use some improvement, but that need is clear and the flow is not intended to replace automated tests.) |
Beta Was this translation helpful? Give feedback.
This isn’t really a Git question, but more of a general software development philosophy question 😀
It sounds to me like the lion’s share of the testing occurs in step 2 of your flow and step 4 is more of a “sanity check”. If you’re not catching enough bugs pre-merge, then your process should focus its testing effort on testing post-merge.
Your three classes of changes are pretty much standard. Every software project has some of each of those changes.
I’m not sure what you mean by “the full git-flow”. It sounds like you’re doing that already. Here’s the process that we recommend for use on GitHub. We recommend this process for changes of all sizes. If some changes are particularly large or…