git-flow: production build on develop branch, merge it to master, but do not want non-meaningful annoying index.html change on dev branch?

Hi, experts,
I use git-flow in my development job.
I use gulp for automating production build(css,js concat, minify).
Normally when I finish a release develop, i do production build on that develop branch, the index.html will be injected with a production.css and production.js(minified version) in replace of all the js/css files linked in it.
Then I do a merge in master with develop to involve the production version for deployment.
But what I want to optimize is: I am annoyed when finishing above job, the develop branch will have a non-meaningful commit of production.js,production.css injected into the index.html. Normally i just use the develop version of the index.html(which will have all single js,css files injected into the index.html) for develop, i do not want that change here everytime I do a deployment.
How to work around that?
Thanks a lot for any proposal.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

evilrixSenior Software Engineer (Avast)Commented:
Just add the files to the gitignore in the local repository.
matiascxAuthor Commented:
Hi, evilrix,
Sorry, what i mean the annoying part is: index.html only has one version file which must be there in git tracking. So it is not possible to put the index.html into gitignore file.
For example, when finishing develop a feature , i will do a production build and produce out the minified css/js file, and update index.html with the production js/css file referrence in it,  and then merged into master branch. So in master branch, the index.html has:
<link rel="stylesheet" href="production.min.css')}}">
<script src="/production.min.js"></script>

When check out develop branch, the first thing i need do is to: do a develop build, and so the index.html will have following:
<link rel="stylesheet" href="css1.css')}}">
<link rel="stylesheet" href="css2.css')}}">
<script src="js1.js"></script>
<script src="js2.js"></script>

Above scenario will result in un-necessary commit of "production" version of index.html and production.js/css file in develop branch.

Is there any good strategy to handle above "issue" : the production.min.js/css,production version index.html  will only live in master branch(but they must be tested on develop branch)?

What i know maybe, the ours merge strategy will fit that requirement a bit.
Is there any other clear idea for that?

Thanks a lot~!
Steve BinkCommented:
On the face of it, you're asking git to violate its historical integrity.  You're asking for git to just "forget" that a file is changed, which should not happen.  

The only work-around I can think of is to maintain your development branch separate from the production branch..  which you're already doing, right?  Do all development, including your script/style injections, in the dev branch, then push only the single commit to production.  Although your dev branch will still show the "annoying" changes, your production branch will only show the final changes in its commit log (which, incidentally, will include the annoying changes).
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

evilrixSenior Software Engineer (Avast)Commented:
You can still ignore a tracked file. All this means is that you can't accidentally replace the existing version with a modified version, without using the "force"  flag. It's meant for exactly this situation, where a file must be tracked but may be charged during the build but those changes should not be accidentally committed.

Another option is to use the assume unchanged flag on the update index command.

There are very few work flows you can't support with git, but sometimes it does mean experimenting a little to find the right combination of commands and flags.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
matiascxAuthor Commented:
Hi, evilrix,
It seems that you have the right solution via ignorefile. Can you give more detail description on how to do for me step by step? I just can not easily understand what should I do to follow your proposal
matiascxAuthor Commented:
@Steve Bink, Yes, I am developing in the develop branch, after do the official build in the develop branch, after testing on this branch, i MUST commit this change(including index.html for production version and production.min.js/css) into git and do merge in the master branch to include this change.
What i do not want is to memorize this production build activity in history of develop branch by git.  
Is there any workaround solution for it?
It seems that the ours merge strategy fit my requirement to some degree, but i am not quite sure.

evilrixSenior Software Engineer (Avast)Commented:
If you don't already have one just create a file called .gitignore in a repo folder that is the same or a direct parent of the one containing the index.html file (normally, but doesn't have to be top level folder)  and then add the relative path to it in the ignore file, but with a leading slash. Once done,  changes to this file are ignored unless you force commit them.

Eg. say you have /foo/bar/src/index.html

Create .gitignore in foo folder and add the following to it


You need the leading slash to tell git to only ignore this path relative to the folder the .gitignore file resides otherwise any paths in child directories that match the same pattern would be ignored.

Read git help for gitignore, it's pretty straightforward.
evilrixSenior Software Engineer (Avast)Commented:
I do tend to agree with Steve; however, that you are probably trying to implement a workflow here that doesn't work well with git. The branching ethos of git is that you branch, make a change, test it and merge it. You don't normally run two different branches side by side. This would probably work okay in SVN but then in SVN each branch is a tree. This is not true of git, which uses a directed acyclic graph (DAG) model.

Maybe consider having a staging repo and a production repo to seperate things.
matiascxAuthor Commented:
Hi, evilrix,
Reply to your ID: 40969446 comments. I have already let git to track my index.html file.
When i add the index.html into the .ignorefile, and do a change to that index.html file, git status will always show that change.
Is there anyway to ignore already tracked file?

What you say give staging repo and production repo seperate maybe a good idea.
Can you give a deeper explaination on your seperating repo proposal?

Thanks a lot~!
evilrixSenior Software Engineer (Avast)Commented:
Matiascx, it shows the change but it won't let you accidentally commit it. This is by design, just in case you did mean to change it and you do need to commit it.

You can use the info I posted in http:#40968599 to ignore it.

>> Can you give a deeper explaination on your seperating repo proposal?
At the moment you push changes to one repo and then use branches to switch between testing and production. I am suggesting you have one repo for testing and one for production. You push all the untested code into the testing repo. Once it's passed testing you push those changes into the production repo. You only every release from the production repo.

The workflow would be something like this...

[make changes] --- push ---> (test repo) >> [test changes] --- push ---> (prod repo) >> [deploy]

This is just a suggestion and it would probably need a bit of thinking through before you decide it would be the way to go. I'm not saying it is your best solution; rather, I offer it as something to consider if using the single repo with branches approach doesn't meet your workflow needs.
matiascxAuthor Commented:
Hi, evilrix,
Thanks very much for your valuable information.
I will do some test and find the "right" solution for my deployment strategy and give feedback soon.
For the so called production repo, is there any mechanism for me to exclude some directories(which will not be pushed to production repo)when i push to production repo?
For example, the un-minified assets files should not be pushed to production repo.

Thanks again!
evilrixSenior Software Engineer (Avast)Commented:
Only gitignore.
matiascxAuthor Commented:
Hi, evilrix,
I describe what i caught from you till now:
1.I clone from test repo locally->2.change and test in develop branch->3.push to remote test repo ->4.push to production repo->5.Deployment server clone and upgrade from production repo-> as depolyment.

Are they all ok according to your proposal?
In above the 4th step, i just add the folder/files which should not be available in production repo via adding them into the .gitignore and use -force option instead when pushing to dev repo?
Please confirm that. The above scenario seems great, i will have test soon.
evilrixSenior Software Engineer (Avast)Commented:
Yes, that sounds about right. You'll have to test to see if it provides better isolation than your current workflow. Like I alluded before, this was an off-the-top of my head suggestion rather than a recommendation.
matiascxAuthor Commented:
Hi, evilrix,
I tested the most suitable solution for my requirement is: git update-index --assume-no-changed.
Thanks for your guidance!
matiascxAuthor Commented:
Professional response from expert. Thanks~
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.