0

Following is the scenario and I would like to understand and possibly write steps for team members - "how to" Scenario: As in any real world scenario we have Master. Story branches are created and worked upon and pushed to Master. This is for continuous integration. Then we have releases As I understand the way how they are now setup is to use tags for release.

Question that I have :

Due to the way application is, we need to have our own project branch say "A1" now and That has been created from Master. An automated job will pull master into "A1" periodically ( conflicts will be alerted and we take care of it in "A1"

I will ask my team members to create feature story branches from A1

Say 2 developers have now created C2 and B4 branches from A1 and after they are done, they will remain as C2 and B4 branches, but also need to merge to A1, so next feature story branch E7 can pick up things done in C2/B4 during the phase of A1 project.

Please help with steps to achieve this.

How do I do feature-story merges into A1 ( and is that correct todo so), before finally merging it into master?

I also do not completely get if ( & how) are features rebased with A1 and is that needed at all?

Appreciate all your help. Thanks.

Nav D
  • 1
  • 1
  • Welcome to SO! See the man page of `git merge`. Seriously, what exactly is the problem? Are you asking about the correct way to work with branches in an agile development environment, or are you asking about the technicalities of how to merge branches with git? To me the question is "unclear what you are asking". Why is this tagged with gitlab? If this is about work methods, it is (arguably) somewhat irrelevant which VCS is in use, certainly it is irrelevant where it is hosted. – cfi Oct 22 '15 at 22:05
  • Yes, basically, I want to know all that you thought I am asking :) How to merge feature branch to develop branch Overall, how to work with branches in agile env. Thanks. – Nav D Oct 22 '15 at 22:09
  • Please see the help page on how to ask good questions. If you want answers to all of this, people could write books about it. This is too broad to cover in one question or answer. Think about your problem, divide it up into open issues, then check the usual sources, and only then ask specifically about the remaining problems. – cfi Oct 22 '15 at 23:06

0 Answers0