CODEWITHSUNDEEP
gitversion-control
trrrrrrm
trrrrrrm

Reputation: 11812

Git: stylesheet and javascript conflicts

We use git as version control, the way that we use it is as following:

Our main branch is production for every new issue or upgrade the developer should create new branch from production branch, update the code and test it then commit his changes to the new branch. After that we merge the new branches to production branch.

What we like about this method is that we can select the changes that we want to push it to production on the current cycle we don't have to push everything, while if we commit directly to production branch then if we want to push one urgent update then we have to push everything at once.

I have two questions regarding this:

  1. Is this the best practice to work with git ? or there is a better approach ?
  2. We are facing a problem with js and css files since those files are likely to be updated in every new branch so sometimes we edit those files in two different tickets and when we merge it to production we will have to fix a long list of conflicts, and many times we endup deleting some code that we still need or it's apart of new changes. Is there anything we can do to overcome this problem ?

Thanks

Upvotes: 0

Views: 109

Answers (2)

mnagel
mnagel

Reputation: 6854

overall, it sounds reasonable. i dont say you should do it exactly as described there, but for some inspiration read: http://nvie.com/posts/a-successful-git-branching-model/

i do not see how well-written, manually coded js/css is doomed to cause conflicts (autogenerated code is another story). there will be some conflicts sometimes, but as long as you do not change "everything, all the time" it should be manageable. when the branches edit different parts of the file they should merge automatically alright.

Upvotes: 1

dahlbyk
dahlbyk

Reputation: 77540

It's a best practice to bless one branch (often master) as production-ready - the "what's pushed and what's not" game is a disaster waiting to happen. Naturally that branch cannot receive changes that aren't ready to be pushed, so leaving branches unmerged is completely acceptable. The longer these go between updates from master (via merge or rebase), the more likely you are to have conflicts.

There are ways to structure code/css to minimize conflicts (consistent formatting, logical file structure, etc), but the best way to avoid them is communication. Learning a good merge tool well (I like BeyondCompare) also helps.

Upvotes: 1

Related Questions