Reputation: 19
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
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.
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
Upvotes: 1