-5.9 C
New York
Monday, December 23, 2024

ios – Is my understanding of the GitFlow launch course of legitimate?


We at present use the GitFlow course of to handle our releases (or so I feel) for a local iOS app.

Listed here are the steps we carried out for context:

  1. We created a brand new repo with the principle department
  2. We then branched off a develop department from major
  3. We then department off a number of characteristic branches so engineers can work on options independently after which we merge them again into develop
  4. After we are able to do a launch we create a launch department from develop, let’s imagine release-1.0.0
  5. This launch department builds a model of the app which is then despatched to our QA engineers who take a look at the app and share any minor fixes wanted that are carried out on the discharge department
  6. As soon as every part seems good, we create a PR to merge launch into major. As soon as the PR is permitted, we merge launch into major and tag it with v1.0.0
  7. We then open one other PR to merge launch into develop after which delete the discharge department.

This all appeared to work effectively after we had the primary model as major had no code on it, nonetheless, now for the following app replace, I’m going through some points in my understanding with gitflow.

Every little thing begins out the identical with us making a launch department off develop referred to as release-1.1.0

Now my first query is that I discover the standing of my major department in relation to develop – it says This department is 1 commit forward of, 24 commits behind develop.

The 24 behind is smart as there have been 24 new commits to develop of characteristic branches, nonetheless, the 1 forward will not be so clear to me.

It may very well be as a result of there have been 2 seperate commits when merging release-1.0.0 into major after which a distinct one to merge launch into develop – is that this a traditional state to be in when utilizing GitFlow.

And now due to the principle department being on this state, after we need to merge launch 1.1.0 into major, we’re unable to as a result of they don’t seem to be in sync.

If we attempt to rebase 1.1.0 on to major, that will not work as it can overwrite the discharge branches with the outdated code on major.

We will not rebase major as this department is protected and wishes PR approvals to be merged into.

So please can somebody assist with answering:

1 – Is the state of the principle department attainable in gitflow as I defined above ?
2 – How can we merge launch into major when they don’t seem to be in sync within the gitflow approach ?

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles