EvanMcFly
EvanMcFly

Reputation: 19

Question about multiple branches/developers in Gitlab

I'm still in the process of learning Git best practices, and I'm trying to figure out where I'm going wrong here...

We have a "master" branch that's hooked up to our "staging" environment. Any commits to that branch trigger a pipeline that updates that environment.

We have a "production" branch, which is our protected branch that mirrors what's actually in production.

All other work happens in individual feature branches that we clone from production.

So here is the workflow:

Developer A creates a branch (cloned from production) called "NewFeature1".

Developer B creates a branch (cloned from production) called "BugFix1".

Developer B pushes code to "master" to test it.

Developer A tries to push code to "master", but gets conflicts. Developer A resolves the conflicts, but this results in the "NewFeature1" branch getting a ton of commit history from "master", which isn't ideal?

When Developer A is satisfied with the changes in "NewFeature1", a merge request is opened for the "production" branch. But instead of just seeing the 1 or 2 commits related to NewFeature1, they see a huge commit history from master being merged in as well. The only files that are actually changed are the relevant files, but the commits from master are still in there, which scares me.

We're all pretty new to Git in general, so I may be missing a core concept here.

Upvotes: 0

Views: 466

Answers (1)

Jonathon S.
Jonathon S.

Reputation: 1980

There are many approaches that may be used for merging and managing branches using Git. This represents one possible approach that may help to reduce difficulties with merging as noted in the question.

A figure is provided at the end for reference purposes.

  1. Minor and non-critical bugfix branches and new feature branches are created from the master branch. This will make it easier to develop and integrate new code with other code developed in parallel.
  2. Prior to merging these types of branches back into the master branch, bring the branch up to date with the master branch. An example of this is merging commit 5 into commit 8 as shown in the figure. The resulting merge commit may be used to retest the program with any features developed in parallel.
  3. Critical bugfix branches are created from and merged to the production branch. These should be used to fix bugs that have a major impact on product functionality and change should be as minimal as possible to avoid affecting the stability of the production branch and to contain the amount of regression testing required.
  4. Any updates to the production branch are merged to the master branch to keep it up to date. An example of this is merging commit 10 into commit 11 as shown in the figure. These should be less frequent but may be complicated depending on the extent of changes made to the master branch since the last release.
  5. A release branch is created from the master branch prior to pulling changes from the master branch to the production branch. This branch can be used for testing the production release and may be updated as needed to resolve any bugs.
  6. Once production testing is finished, the release branch is merged to the production branch. This may be a fast-forward merge.
  7. Any change made in production testing should also be merged into the master branch. An example of this is merging commit 12 into commit 13 as shown in the figure.

The following figure is provided as an example. Arrows point from parent commit to child commit. Regular commits are blue and merge commits are red. Commit numbers are provided for readability and would be represented as SHA-1 hashes

enter image description here

Upvotes: 1

Related Questions