I work for a small company that currently has only two developers. I'm not an expert with GitHub and I know that our current workflows aren't necessarily standard. I'm not looking to re-design our whole workflow, just a reasonable solution to this specific challenge:
We have two main branches: Development and Master. We use the Master branch for client installs, so it is always behind Development, until we merge the two before a major release.
Due to the nature of our software and target market, it is important for us to be able to periodically apply custom code for specific clients to the Master branch between releases so that it is ready for their use when we install. We also need to apply these changes to the Development branch so that they are included in the next release. This custom code is included in all future client installs/updates, but only accessible to the specific client based on configuration settings.
My current solution is to create the "Custom Feature" branch based on the Master branch. When the custom work is done, we will create a pull request for both the Master branch and the Development branch. Since the Master branch always has the same code as development, just in an earlier state - this seems to me like it should work. But like I said, I'm not an expert with GitHub and I'm sure this could be dangerous for any number of reasons.
I know it's risky to apply these types of periodic changes to a live release branch. However due to the nature of our software, most of our clients expect at least a small level of customization when we install for them.
Edit
I'm aware this is very similar to this question:
Avoid merging master into development branch
But I'm proposing branching from the release branch rather than the development branch, so I think it's a different case (I'll admit some of the concepts from that question go over my head though). I apologize if this is deemed to be a duplicate.
I recommend getting familiar with GitFlow as it might be a solution to your problem. https://datasift.github.io/gitflow/IntroducingGitFlow.html
Basically, you are right, the correct way to do this is to branch off from master, create the change in the branch and then merge to master and develop. Follow the "hotfix" section in the attached link.
In my previous jobs, programmers were encouraged to check-in code often with comments. At my new job now, the rule is that no one checks in anything until his or her code is QA'ed. But because QA lags so much behind, we could rarely check-in. We can probably check in once every 2 weeks or so. And when we are asked to check in, it is really a pain in the neck to sort out what's changed for which ticket that needs to be checked in. Do you guys understand the pain? And the consequence is that very often, we programmers forget to check in some important files for some ticket. Another consequence is that this: I have modified file1.html for both ticket 1 and ticket 2. Now we are asked to check in changes for ticket 1 only, and then I have to save a copy of file1.html outside of my solution and then determine what changes are for ticket 1 and remove those changes for ticket 2 before I check in. Pain!
What's your suggestion? What should I say to convince the team here to stop this check-in policy and allow us to check in as often as we want before it is QA'ed? Thanks!
I'd say you seem to understand the problem fairly well, you just need to lay out the pros/cons of the two approaches.
Error-prone to cherry-pick files to check-in at a later date
The version/files you check-in may not match what QA tested. Ideally QA should be testing the same code that will be release, and your version control system is used to enforce that.
Having QA test code that included other changes that may or may not be in the same release can lead to test passes/failures that are dependent on code that will not be in the release. This can invalidate the QA process.
What you are doing is different than what most other teams are doing (honestly this usually resonates with managers more than the other points - in my experience as a consultant at least)
It sounds like what your team is trying to achieve is have a set of code that has all undergone QA and is "releasable" at any time. This is a good goal, but it is usually achieved by using an appropriate branching strategy.
One approach is to do branch by feature (that's essentially what you're trying to do now, only without the support of a version control system). This means you have a branch for each independent change/feature that you make. QA happens against your feature branch. Once QA passes that feature branch is merged into MAIN (aka trunk).
This way developers have their own feature branch that they can check-in to often (best practice is at least one check-in per day). And you still have the copy of the code that is restricted to only code that has passed QA (MAIN), and is always release-ready.
If you fail to convince them you can also use a local Git repository to keep your personal changes organized, then use the Git-tfs tool to send them over to TFS when it's time to check-in.
We are using TFS for our code: trunk + branches for coding activities. There are 6 devs in my team.
Problem: sometimes developers don't want to create a new branch (or use an old one) to fix/develop something. They just do it in trunk. OK, in some cases it's acceptable. But most of the time it creates a lot of troubles.
How can I enforce protection of trunk and force devs to create new or reuse old branches?
UPD: I don't want to give read-only access to the devs on trunk (they have to be able to create branches and merge them back by themselves). I want some compromise - can create branches/do merging but can't develop in the trunk.
Working on the trunk directly is almost always incorrect. Yes it can be the most efficient way sometimes, but breaking process is breaking process and that will bite you eventually.
I think this problem is best solved with education, but limiting trunk write access to senior devs might help too - if they aren't "infected" too :)
Wortyh bearing in mind though that any good source-repository (read: not VSS) will save you from terminal problems in this area, it's just a matter of effort and watchfulness. You never want to rely on rollbacks, just saying "don't panic".
You can set permissions at the folder level.
Creating a branch is a powerfull permission. You will probably have to have one person who creates the branches and then sets the permissions.
For information on setting permissions see: http://msdn.microsoft.com/en-us/library/ms252587.aspx
I'll second what #annakata said. Additionally, I highly recommend that whomever is responsible for managing SCM in your organization to set up a check-in alert that lets you know when someone checks code into the trunk. That way, you can follow up (with the previously-mentioned cricket bat, if necessary) with the developer responsible.
Some other techniques to consider:
Only allow senior developers to check in. Developers shelve their changes, and the senior devs review then check-in. They can help be your gatekeeper.
Use the gated-check-in feature of TFS2010 to help you. Turn on gated check-ins for the trunk.
Education in a form that developers can understand. Make them know exactly why building off the trunk is a bad thing. SCM process education can go a long way to getting people to comply. If they think it's just an arbitrary rule, they don't feel bad about violating it.
Add consequences (to whatever degree your organization allows). Things like a beer/pizza fund that they need to contribute to when they screw up, or a funny hat that needs to be worn, or even a loud announcement to the entire development organization when someone checks in to trunk. It gets the point across quickly.
Does TFS has support for running hook scripts like subversion has?
If it has you can run pre-commit and post-commit checks to see if commits follows process guidelines, reject patches with an email explaining why etc.
If thats too much work my best advice is talking to people and use good old reward for adhering to rules and punishment for breaking them.
What kind of "fixes" are they making to the TRUNK? Typically you should never check-in to TRUNK but only merge...
If they have enhancements or bug fixes that can wait and that are not emergencies they should do their development in the DEV branch.
If it is an emergency then branch off of TRUNK and make a HOTFIX branch. This will be a copy of what is in production.
Example of when you would want to use HOTFIX:
Let's say you have a change you want to make to production or QA but you don't want the future work done in DEV to go out just yet as it has breaking changes for the QA environment or maybe you just want to be as safe as possible and make sure only the code you know you wanted to change went out with your deployment. If you do not have a HOTFIX branch then click on TRUNK and select "Branch" and name it HOTFIX or something meaningful to you. Then make your changes in HOTFIX, check them in, and deploy from the HOTFIX branch. The HOTFIX will only contain two things then A. What is in TRUNK and B. Your one-off changes. It will not include all of the extra work that you haven't validated or tested from the DEV branch, which is a good thing.
You can create user group within TFS to give readonly or no acess at all. If you right mouse click over the team project and click group membership, then add those groups to the folder structure in the source control Explorer.
Should multiple developers work within the same branch, and update - modify - commit ? Or should each developer have his/her own each branch exclusively? And how would sharing branches impact an environment where you are doing routine maintenance as opposed to unmaintained code streams? Also, how would this work if you deploy each developers work as soon as it is done and passes testing (rapidly, as opposed to putting all of their work into a single release).
In general, I have found that having developers (who are working on the same project) use the same branch is better for finding integration problems sooner. If developers are each using an individual branch, then you're just delaying possible integration problems until later, when you merge the branches.
Of course, having developers work on the same branch means you need to have actual communication between those developers, but that's a social problem and not a technical one.
Developers would work on separate branches when there is a good reason for that branch to exist in the first place (such as a patch release of a previous version of the software, or a special build for a specific customer).
Note that tools such as Git and Mercurial allow developers to easily create their own private branches to organise their own work. This is a different situation from more than one developer sharing a branch, and (usually short-lived) private branches should be encouraged.
Branches are meant as a way to version control any feature or experimental piece of code that may break the mainline/trunk.
While it is common for developers to have their own personal branches for deep experimentation, often branches center around a new feature being added. These new features often require more than one person to be committing.
For example, on a web project, two developers and a designer may be doing a facelift to their company website. They still need to keep their mainline/trunk code clean in case they need to make a quick change to it before the facelift is complete. So they create a "facelift" branch and work on that instead. While the developers are committing javascript, the designer can be committing CSS and images. Once the facelift feature is complete, they can merge it into the mainline and send it live.
The only reason any of them would need personal branches would be for experimenting. Perhaps the designer is trying to implement "sliding door" tabs and can't get the padding right in IE6, for example. If he solves the problem, he can merge it into the facelift branch, if he can't, he simply ignores it and continues with the rest of the design back in the facelift branch.
To some extent, the version control software you are using will nudge you into a particular approach. GIT is geared toward open-source contributors and resembles the "one developer" model (branching isn't even a concept in GIT. GIT is more about managing changes). Clearcase is more corporate, so you do have multiple developers on a branch, but each developer gets to play in his or her own view.
I agree with Greg's answer, this is more a social planning issue. Lots of devs on one branch will step on each other's toes. I've been on a project where there were more developers than individual source files :)
I think that merging of branches can be problematic (dropped or inconsistent functionality), regardless of how good the source control tools are. I would more readily opt for multiple developers working on a single main branch. There could be other branches for things like production bug fixes or proof-of-concepts (POCs), where merging could/should happen very soon after change (bug fixes) or good chance that merging may not need to happen (POCs).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Suppose you're developing a software product that has periodic releases. What are the best practices with regard to branching and merging? Slicing off periodic release branches to the public (or whomever your customer is) and then continuing development on the trunk, or considering the trunk the stable version, tagging it as a release periodically, and doing your experimental work in branches. What do folks think is the trunk considered "gold" or considered a "sand box"?
I have tried both methods with a large commercial application.
The answer to which method is better is highly dependent on your exact situation, but I will write what my overall experience has shown so far.
The better method overall (in my experience): The trunk should be always stable.
Here are some guidelines and benefits of this method:
Code each task (or related set of tasks) in its own branch, then you will have the flexibility of when you would like to merge these tasks and perform a release.
QA should be done on each branch before it is merged to the trunk.
By doing QA on each individual branch, you will know exactly what caused the bug easier.
This solution scales to any number of developers.
This method works since branching is an almost instant operation in SVN.
Tag each release that you perform.
You can develop features that you don't plan to release for a while and decide exactly when to merge them.
For all work you do, you can have the benefit of committing your code. If you work out of the trunk only, you will probably keep your code uncommitted a lot, and hence unprotected and without automatic history.
If you try to do the opposite and do all your development in the trunk you'll have the following issues:
Constant build problems for daily builds
Productivity loss when a a developer commits a problem for all other people on the project
Longer release cycles, because you need to finally get a stable version
Less stable releases
You simply will not have the flexibility that you need if you try to keep a branch stable and the trunk as the development sandbox. The reason is that you can't pick and chose from the trunk what you want to put in that stable release. It would already be all mixed in together in the trunk.
The one case in particular that I would say to do all development in the trunk, is when you are starting a new project. There may be other cases too depending on your situation.
By the way distributed version control systems provide much more flexibility and I highly recommend switching to either hg or git.
I've worked with both techniques and I would say that developing on the trunk and branching off stable points as releases is the best way to go.
Those people above who object saying that you'll have:
Constant build problems for daily builds
Productivity loss when a a developer commits a problem for all
other people on the project
have probably not used continuous integration techniques.
It's true that if you don't perform several test builds during the day, say once every hour or so, will leave themselves open to these problems which will quickly strangle the pace of development.
Doing several test builds during the day quickly folds in updates to the main code base so that other's can use it and also alerts you during the day if someone has broken the build so that they can fix it before going home.
As pointed out, only finding out about a broken build when the nightly build for running the regression tests fails is sheer folly and will quickly slow things down.
Have a read of Martin Fowler's paper on Continuous Integration. We rolled our own such system for a major project (3,000kSLOC) in about 2,000 lines of Posix sh.
I tend to take the "release branch" approach. The trunk is volatile. Once release time approaches, I'd make a release branch, which I would treat more cautiously. When that's finally done, I'd label/tag the state of the repository so I'd know the "official" released version.
I understand there are other ways to do it - this is just the way I've done it in the past.
Both.
The trunk is used for the majority of development. But it's expected that best efforts will be made to ensure that any check-in to the trunk won't break it. (partially verified by an automated build and test system)
Releases are maintained in their own directory, with only bug fixes being made on them (and then merged into trunk).
Any new feature that is going to leave the trunk in an unstable or non-working state is done in it's own separate branch and then merged into the trunk up on completion.
I like and use the approach described by Henrik Kniberg in Version Control for Multiple Agile Teams. Henrik did a great job at explaining how to handle version control in an agile environment with multiple teams (works for single team in traditional environments too) and there is no point at paraphrasing him so I'll just post the "cheat sheet" (which is self explaining) below:
I like it because:
It is simple: you can get it from the picture.
It works (and scales) well without too much merge and conflict troubles.
You can release "working software" at any time (in the spirit of agile).
And just in case it wasn't explicit enough: development is done in "work branch(es)", the trunk is used for DONE (releasable) code. Check Version Control for Multiple Agile Teams for all the details.
A good reference on a development process that keeps trunk stable and does all work in branches is Divmod's Ultimate Quality Development System. A quick summary:
All work done must have a ticket associated with it
A new branch is created for each ticket where the work for that ticket is done
Changes from that branch are not merged back into the mainline trunk without being reviewed by another project member
They use SVN for this, but this could easily be done with any of the distributed version control systems.
I think your second approach (e.g., tagging releases and doing experimental stuff in branches, considering the trunk stable) is the best approach.
It should be clear that branches inherit all the bugs of a system at the point in time where it is branched: if fixes are applied to a trunk, you will have to go one by one to all branches if you maintain branches as a sort of release cycle terminator. If you have already had 20 releases and you discovered a bug that goes as far back as the first one, you'll have to reapply your fix 20 times.
Branches are supposed to be the real sand boxes, although the trunk will have to play this role as well: tags will indicate whether the code is "gold" at that point in time, suitable for release.
We develop on the trunk unless the changes are too major, destabilizing, or we are nearing a major release of one of our products, in which case we create a temporary branch. We also create a permanent branch for every individual product release. I found Microsoft's document on Branching Guidance quite helpful. Eric Sink's tutorial on branching is also interesting, and points out that what works for Microsoft may be too heavy for some of the rest of us. It was in our case, we actually use the approach Eric says his team does.
It depends on your situations. We use Perforce and have typically have several lines of development. The trunk is considered "gold" and all development happens on branches that get merged back to the mainline when they are stable enough to integrate. This allows rejection of features that don't make the cut and can provide solid incremental capability over time that independent projects/features can pick up.
There is integration cost to the merging and catching up to new features rolled into the trunk, but you're going to suffer this pain anyway. Having everyone develop on the trunk together can lead to a wild west situation, while branching allows you to scale and choose the points at which you'd like to take the bitter integration pills. We're currently scaled to over a hundred developers on a dozen projects, each with multiple releases using the same core components, and it works pretty well.
The beauty of this is that you can do this recursively: a big feature branch can be its own trunk with other branches coming off if it. Also, final releases get a new branch to give you a place to do stable maintenance.
Attempting to manage maintenance of current production code in line with new development is problematic at best. In order to mitigate those problems code should branch into a maintenance line once testing efforts have completed and the code is ready for delivery. Additionally, the mainline should branch to assist in release stabilization, to contain experimental development efforts, or to house any development efforts whose lifecycle extends across multiple releases.
A non-maintenance branch should be created only when there is the likelihood (or certainty) of collisions among the code that would be difficult to manage any other way. If the branch does not solve a logistical problem, it will create one.
Normal release development occurs in the mainline. Developers check into and out of the mainline for normal release work. Development work for patches to current Production code should be in the branch for that release and then merged with the mainline once the patch has passed testing and is deployed. Work in non-maintenance branches should be coordinated on a case-by-case basis.
It depends on the size of your development effort. Multiple teams working in parallel won't be able to work effectively all on the same code (trunk). If you have just a small group of people working and your main concern is cutting a branch so you can continue to work while going back to the branch for making bug-fixes to the current production code that would work. This is a trivial use of branching and not too burdensome.
If you have a lots of parallel development you'll want to have branches for each of the efforts but that'll also require more discipline: Making sure your branches are tested and ready to merge back. Scheduling merges so two groups aren't trying to merge at the same time etc.
Some branches are under development for so long that you have to permit merges from the trunk to the branch in order to reduce the number of surprises when finally merging back to the trunk.
You will have to experiment if you have a large group of developers and get a feel for what works in your situation. Here is a page from Microsoft that may be somewhat useful: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx
We are using the trunk for main development and branch for releases maintenance work. It works nice. But then branches should only be used for bug fixes, no major changes, especially on database side, we have a rule that only a schema change can happen on the main trunk and never in the branch.
If you are gonna be working through a release cycle, big feature, you get marooned to a branch. Otherwise we work in trunk, and branch for every production release at the moment we build.
Previous production builds are moved at that time to old_production_ and current prod release is always just production. All our build server knows about production is how to deploy the production branch, and we kick that build off with a force trigger.
We follow the trunk=current development stream, branch=release(s) approach. On release to the customer we branch the trunk and just keep the trunk rolling forward. You'll need to make a decision on how many releases you're prepared to support. The more you support the more merging you'll be doing on bug fixes. We try and keep our customers on no more than 2 releases behind the trunk. (Eg. Dev = 1.3, supported releases 1.2 and 1.1).
The trunk is generally the main development line.
Releases are branched off and often times experimental or major work is done on branches then merged back to the trunk when it's ready to be integrated with the main development line.
The trunk should generally be your main development source. Otherwise you will spend a lot of time merging in new features. I've seen it done the other way and it usually leads to a lot of last minute integration headaches.
We label our releases so we can quickly respond to production emergencies without distribing active development.
For me, it depends on the software I'm using.
Under CVS, I would just work in "trunk" and never tag/branch, because it was really painful to do otherwise.
In SVN, I would do my "bleeding edge" stuff in trunk, but when it was time to do a server push get tagged appropriately.
I recently switching to git. Now I find that I never work in trunk. Instead I use a named "new-featurename" sandbox branch and then merge into a fixed "current-production" branch. Now that I think about it, I really should be making "release-VERSIONNUMBER" branches before merging back into "current-production" so I can go back to older stable versions...
It really depends on how well your organization/team manages versions and which SCM you use.
If what's next(in the next release) can be easily planned, you are better off with developing in the trunk. Managing branches takes more time and resources. But if next can't be planned easily(happens all the time in bigger organizations), you would probably end up cherry picking commits(hundreds/thousands) rather than branches(severals or tens).
With Git or Mercurial, managing branches is much easier than cvs and subversion. I would go for the stable trunk/topic branches methodlogy. This is what the git.git team using. read:http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
With Subversion, I first applied the develop-in-the-trunk methodlogy. There was quite some work when it came to release date because everytime I had to cherry pick commits(my company is no good at planning). Now I am sort of expert in Subversion and know quite well about manaing branches in Subversion, so I am moving towards the stable trunk/topic branches methodlogy. It works much better than before. Now I am trying the way how git.git team works, although we will probably stick with Subversion.
Here is the SVN design that I prefer:
root
development
branches
feature1
feature2
...
trunk
beta
tags
trunk
release
tags
trunk
All work is done from development/trunk, except for major features that require its own branch. After work is tested against development/trunk, we merge tested issues into beta/trunk. If necessary, code is tested against the beta server. When we are ready to roll some changes out, we just merge appropriate revisions into release/trunk and deploy.
Tags can be made in the beta branch or the release branch so we can keep track of specific release for both beta and release.
This design allows for a lot of flexibility. It also makes it easy for us to leave revisions in beta/trunk while merging others to release/trunk if some revisions did not pass tests in beta.
There's no one-size-fits-all answer for the subversion convention question IMHO.
It really depends on the dynamics of the project and company using it. In a very fast-paced environment, when a release might happen as often as every few days, if you try to religiously tag and branch, you'll end up with an unmanageable repository. In such an environment, the branch-when-needed approach would create a much more maintainable environment.
Also - in my experience it is extremely easy, from a pure administrative standpoint, to switch between svn methodologies when you choose to.
The two approaches I've known to work best are the branch-when-needed, and the branch-each-task. These are, of course, sort of the exact opposite of one another. Like I said - it's all about the project dynamics.