Is there a preferred way to set up projects or branches on github, so there's always a stable branch available for people to download? How do you guys set up your projects?
Here's an example: right now I have a "stable" branch(master) and then an "edge" branch(for development only). When I am ready to release a new version to the public, I will merge my edge branch onto the stable one. Is that a recommended approach? Thanks!
Sounds like a fine (and normal) approach. What you can do is to have multiple development branches, for each feature or bug fix your are working on. This allows you to switch between the branches depending on what you want to work on today. But if you are a lone developer on your project, that may just be overkill.
Just a late update to my answer, I found this article and it looks like a very good approach to version control using git: http://nvie.com/posts/a-successful-git-branching-model/
And incidentally this is very close to the way we use version control at work.
However this is probably most relevant for projects with multiple people.
Related
I am researching development in VisualFiles.
How can I use version control on the files(scripts) I have changed?
My solution so far:
Setup:
Create a folder structure within the repository according to my applications.
Update process
I will modify a file in visual files
I will then manually have to update file in a repository
Commit the changes against a work item
Is there a better way of introducing version control for VisualFiles. Because to me this feels like not an ideal solution
Thats pretty much the only solution at the moment. The team I am in does something similar but only really for major versions, in minor changes we will feature-switch within the code and leave the old edits inline with dates and initials
The platform provider (LexisNexis) have determined changess to code editor functionality as "likely to implement". This may or may not include version control, that is not yet known, if it does it will be in released v4.1+. There are no other tools available to achieve your aim within the platform. Ask your account manager for access to the ideas portal and you can see when their dev team commit to enhancements such as this.
As source/version control is a long standing issue, any devs using the platform have always had to find workarounds as per your suggestion. The providers are highly unlikely to push any version control functionality with backwards compatability pre v4.
If I have to change the source code of an app(Email, Browser, etc) for some custom requirement, I wonder how I should maintain the changes so that I can upgrade to the newer version of the app later when it's available.
I can thinking of maintaining the diff patch and applying to the newer version later but I am wondering if there are any best practices. Is it good to just fork off a branch and keep merging the newer changes into it?
Thanks.
Sony several times described their process. Here is the links:
http://developer.sonymobile.com/2013/07/25/explaining-the-software-upgrade-process-and-its-improvements-for-android-4-3/
http://developer.sonymobile.com/2011/12/07/ice-cream-sandwich-from-source-code-release-to-software-upgrade/
You should follow the disciplines that:
Keep your modifications aside from the original code as much as possible - this will save your effort if you have to do merge code later
Record your modification work in an appropriate way, you need to know why you made these changes and how you did it.
Don't expert to do a simple merge since the changes might not be fast-forward. Rebase your repository first and pick your changes and apply carefully.
Based on my SO post I've been using Github as our VCS and with the help of the windows Github tool it's been great to handle those basic operations. Yet for merge like operations, I've to get back to Gitbash (SO Post) but thats ok.
So, the source code level VCS is in place. Now, we want to take a step
forward and use its simple issue-tracker to have "release control". For us,
this means being able to track each stable build (it can be a new
feature or bug fix, etc..) The idea is to create issues, tie them to a
milestone and use Github commit comments to close the issue and mark
it as a stable release/build. Where does tagging come in picture?
I've learned that we shud have a "development" branch for ongoing changes and periodically merged with the master (i.e. each stable build).
Is this the right way? We need to be able to go back to release / build 1.0 from 1.1 - sort of rollback just in case its required anytime in future (is this possible? how?) Is Github suffie or do we need to use some external tools as well?
Please share your experience and suggestions.
As I wait for other expert comments, I'd like to share a model that I've come across and seems great!
A successful Git branching model (SO Post)
To summarize, here is how I can address my basic needs (and scale it as and when required) -
Initially maintain two branches "master" and "development"
Master should always have a stable version and development has an ongoing source (might not be stable)
In the future, if we need to fix a bug after release, we can create a hotfix branch and when stable merge it with master/development
A good thing I found is that I can maintain stable releases in form of tags (i.e. new tag for each new version)
Eventually, master branch will be merged with development as we proceed with each stable version
There's a lot more that can be handled with the above model but I see my initial concerns addressed. Any better suggestions?
I recently started taking an interest in using a branching model similar to Vincent Driessens Git branching model. We have multiple developers working on the same project so using different branches for different features is a big plus for us. The model states that after a feature is developed, it is merged back into the Development branch, and on a certain time a release branch will be created from it.
Now my problem is that I don't know who added what to the dev branch since the last release, but I do want to present a list of changes that will be implemented for the next one. So the question is, how do I know what features have been added to the dev branch?
We're using TFS for version control. As far as I know I have the following options:
Better labeling and commenting of versions (currently there is no labeling and little commenting)
Linking TFS tasks to versions (not sure how to create a nice list of that yet though)
Maybe I should just follow my own options above but I was curious about how you guys deal with this.
First I would suggest you take a look at the TFS Branching and Merging Guide as it will likely answer most of your questions.
how do I know what features have been added to the dev branch?
I think the "develop" branch in Driessen's model is most closely equated to the "main" branch in the TFS guidance. I would suggest that you shouldn't merge changes into main unless they are already planned to go into the next release. Then when you are ready to release you simply branch from the latest version of main.
Keeping track of what features are intended for the next release is something that would be handled by the work item tracking system.
Separately, you may find the Track Work Item feature of Team Explorer to be helpful.
If you have a version 1.0 of a product, or say 1.1 or even a patch, do you create a tag/label or a branch?
Eric Sink wrote a great series of articles about the ins and outs of version control. I'd suggest using those as a starting point.
Depends on the version control system. I'd branch for incompatible (major version number) changes, and tag for compatible (minor version number) changes. That leads to a whole discussion about what's compatible and what isn't, though...
Or, just use Subversion, where you'd normally use "svn copy" for either.
I usually don't branch but only label the releases. This way, I can branch later when the need arises. Since branches are so expensive in CVS, try to avoid them until you really need them. For all other VCS tools, branching is so cheap that you can do it as you need it, so no need for premature actions, either.
It depends a bit on the tool (version control system) you use, if it has sane branching and tagging.
In Git I would use tags such as v1.0, v1.1 to point to exact version (tags do not change), so if somebody would tell you that there is a bug in version 1.0, you would know exactly what it contains. If there would be a need for long-term maintenance, I would use branches such as maint-1.0 and maint-1.1 to gather maintenance bugfixes for past version, and from time to time tag new minor release such as v1.0.1, or v1.1.5.
HTH