After you commit feature C, you run the following command: git rev-parse development Second, you should get the commit SHA id of feature C.
And with that call, we have introduced git cherry-pick to our development processes.įor an easy start, suppose we have developed a feature, C, currently available in the development branch with other developments, A, B, and D. This was our call to work on our processes and rules. We’d realized and rolled back to the previous release within an hour, but since it was the middle of the workday we had got several bugs reported by our users. And we were in a rush to make deployment to fix a production bug.Īt that point, we forget about that dependency and merge everything to the production branch. The other team completed their development only in their development environment but didn’t push that change to their production environment for some reason(they were depending on another client or something, I don’t remember the exact reason). One feature in the development environment was depending on a third-party API of another team. We were directly merging development to staging and staging to production. We had three branches and environments development, staging, and production. Back then, we were a new team, and always in a rush to prove our worth to the organization, we have had a development mindset but rules such as the definition of done, deployment checklist, etc.
In fact, my team had suffered from a similar situation in the past. It is extremely important for teams to have the mindset and rules to prevent these kinds of situations. You might end up sending not completed work to the production environment and cause bugs. Managing development and branches in large teams and projects can be exhausting.
0 kommentar(er)
