Tag Info

New answers tagged

-3

I too agree that this is not good practice to have a repository on a production server. So you are going to version the files on the development machine and version the files on the production server? If you have that much time on your hands to do double the work, they aren't giving you enough work my friend. This is what the development machine is used ...


1

It is more common to use source control branching in order to control what features are available within a particular version of the software. That said, applications that offer tiered functionality within the same version level will sometimes use the technique you describe. Usually, you'll see two main uses of the conditional definitions. The fist uses ...


0

For me, the main difference in using one or more than one repository are the answers to the following questions: Are the multiple parts developed by the same team, have the same release cycle, the same customer? Then there are less reasons to split the one repository. Are the multiple parts highly dependent on each other? So splitting model, controller and ...


1

The simplest approach is to use a single repository, so unless you like complexity for complexity's sake, then that should be the default choice in the absence of compelling arguments otherwise. Is the client and server development going to be carried out by different organisations? Will there be multiple implementations of the client (or server)? Is the ...


2

I only just saw this question, and there is actually a canned solution - from GE-IP of all places. Check out Proficy Change Management. This product does version control from a PLC control systems point of view, rather than a pure version control of files point of view - it works as a layer sitting on top of a VCS (the scary part is that originally this ...


1

Our team uses the Gerrit code review system, where reviews are based on commits, instead of branches. The learning curve of Gerrit is higher than pull requests, but it creates a much cleaner commit history and allows for fine-grained commenting on code. Our local repositories still contain branches, but 95% of our commits end up directly on the 'develop' ...


1

You mentioned that you are familiar with gitflow. I suggest to addopt it for your scenario. You will need to create branches from your development branch to support older versions. These older versions will also need to have their own release/master branches and hotfix branches. You will need to periodically merge your support branches into the newer support ...


1

Version control really is the wrong tool for this. (Of course, you should still be using version control for your code!) You don't have separate but inter-related lines of development for your code. Instead, what you have is two completely different pieces of code. However, those different pieces of code are related in such a way that one can be ...


6

When you use git as version control you can. use your full code as trunk. branch of your students version. continue dev on trunk. merge trunk into branch. do new adjustments for changed code in students branch. All changes in the students branch will persist, git will only take new changes from trunk and add those to the branch, You will probably ...


-2

Yes, use GitHub, it is the most popular and well-used. Have a public repo where you encourage people to commit on the beta branch. Don't have too many branches where it gets confusing or unmanageable. Instead, if you want to see new versions of the framework, encourage them to fork it. You could consider consolidating your alpha and beta branches. Good luck! ...


1

There are many different approaches, and it depends both on your application and on your team's personality. Here is a good summary of a few branching workflows in Git: http://sethrobertson.github.io/GitBestPractices/#workflow The link there labelled "Git-flow branching model" is a very popular approach. However, there are some who think that all the ...



Top 50 recent answers are included