I will try to brief but thorough in explaining my problem but it’s an ongoing problem with Git and the way it sees changes in a single file.
The adopted workflow I have been using is rather simple:
- Create a feature branch based off master
- Make changes add/commit
- Merge the feature branch into Dev
- Merge the feature branch into Test
- Merge the feature branch into Prod
The reason for basing the feature branch off master is to eventually merge back to prod without anybody elses changes being carried in my feature branch.
The initial master, release/Dev and release/Test branches were created and updated from the servers by the following process:
- Created initial repo
- Cloned the empty repo to my local system
- Copied the server directories to be tracked to my local tracked directory
- Committed and pushed the production tracked files to the repo
- Created the 2 Dev and Test release branches based off the inital production files in master
- Updated my local copy of the repo with the new release branches
- Created a feature branch based off master
- Copied the Test server’s files to be tracked to the feature branch locally
- Pushed and merged into Dev
- Then pushed and merged into Test (I wanted the history in Test to go through Dev to hopefully avoid unkown changes). Since this is the normal promotion steps anyway, it makes sense to run all initial files on the Test server through Dev first and then promote to Test
- Then, created a feature branch for Dev initial update
- Copied the files from the Dev server to the local feature branch
- Pushed and merged the files into the Dev release branch
The particular team I’m working with has situations where they will make changes to Dev and Test and the file could be months getting into prod or never make it to prod.
Everytime we base the feature branch off master, we check out the file from Dev to get the most up to date copy of the file they are making changes to.
It almost always causes a conflict when either trying to merge back into Dev or Test.
There is only 1 developer that changes these files. I tried to make sure all the change history for all 3 servers was in place and that updates from each server were known to all release branches.
I have 1 file that refuses to not have a conflict. I check it out from Dev and if I do the following steps, it merges into Dev fine:
- Create feature branch off master
- Checkout file from Dev
- git checkout release/Dev – <file>
- Merge into Dev
- Make file changes
- Merge into Dev
In order for the new changes to not conflict with Dev, I have to checkout out the file, make no changes, add/commit/push after the checkout, then, make the new changes and add/commit/push. This is ridiculous and should not be required when checking out.
I cannot understand with all the history in place, why I have to checkout the file and before making any changes, add/commit/push.
The changes being made in this instance is inserting some lines and changing some lines. It should not matter that they are existing lines as I thought this is what version tracking was all about. It would allow changes to existing lines to be made as long as the history was in place for those lines and would simply add to the history and allow those changes without conflicting???
Any advice on a better workflow to avoid conflicts on a single file with only 1 developer would be most appreciated!