Are there any best practices for branch naming in TFS? Currently if I'm branching from my Main to my Development folder I name the branch after the feature.
I'm not sure if this is a good way to do this or not, so was just after opinions and examples.
Have you taken a look at the guidance by the ALM Rangers on codeplex?
https://aka.ms/vsarsolutions
Basically, you can organize branches into three categories: Main, Development and Release. Main branch is branch from a parent with the latest changes, and Development and Release branch from Main. You can define your branch name like: ProjectName_Main, ProjectName_Dev, ProjectName_Release.
Also have a check on this MSDN article for defining branching and merging strategy: https://msdn.microsoft.com/en-us/library/bb668955.aspx
Related
We recently switch from Bitbucket to Github. One feature we're missing is the ability to create PRs or Auto-merge commits made onto a "release" branch directly to our development branch. We had it set so if a bug was fixed in the "release" branch, which was branched off of development just prior to release, it would auto-create a PR and merge the PR if there were no conflicts.
How are teams using Github to accomplish this? I don't see it as a default configuration, but I'm assuming teams are doing something like this as it's pretty common.
I saw answers to a similar question on Can GitHub automatically merge branches? . I think it will solve your problem. It seems Github has introduced a new auto merge feature in 2020 december.
During the past few days I have struggled with how to handle versioning and our branching strategy while using Azure DevOps, so I decided to find some more information regarding how Microsoft does it..
However.. the versioning-part isnt really shared anywhere from what I have seen.. but I just watched how they handle branching over at this video:
Git patterns and anti-patterns for successful developers
However.. the part I dont quite get is.. its quite common to have your verison of your product configured as variables in your yaml. So for instance, during development you might have the following variables setup:
variables:
Major:1
Minor:1
Patch:0
Now lets say that we release version 1.1 and create our release-branch according to the above "relase flow" git stratgey.. we would once the release branch is created "bump" the version in our master-branch to for instance:
variables:
Major:1
Minor:2
Patch:0
Now.. all new code thats branched of master would end up with version 1.2.0.. however.. if we suddenly need to hotfix our production code, the release flow branching stratgey mentioned in the video would branch of master for our bugfix, this would give us a branch which has version 1.2.(1), but the minor and major we actually are trying to "patch" is 1.1... so as suggested by the video, if we now PR our bugfix into master and our release-branch, we would also not just patch our prodiction code with the bugfix, we would bring it up to a new minor-version.. which I would argue is not a prefered way of versioning the code, since the "logical" verison for our new bugfixed production-code would be 1.1.1
Any ideas of how this is solved?
The way I understand it in the release flow org site, if you cut a release branch to correspond with what is in production, your maintenance work (i.e. hotfixes/patches) happen on the release/1.1.0 branch. You then apply the same fix to mainline (e.g. master). See the following diagram:
Furthermore, if you want to avoid full branch merges to propagate fixes to mainline and other release branches, git cherry-pick is your friend. Just cherry-pick the commits into another hotfix off of mainline or another release branch and make any adjustments needed to get it working with that version of the code.
Cheers!
Azure DevOps and Release flow, hot to handle versioning when hotfixing?
If the minor and major we actually are trying to "patch" is 1.1 and you do not want to patch production code with the bugfix branch, we could try to merge the master branch to the hotfix after completing the development work, give the version 1.2.1.
After completing the above PR, we could merge the hotfix branch to the master, then we went back to our previous scene:
Now, we could forget the hotfix branch and continue to develop and release on the master branch.
I have been working on a project which is on git master branch.
As we are 3 developers work on this master branch and modify the same files, we get much conflicts.
To avoid these conflicts, do I need to create separate branches from the same master branch.
Please suggest me a good development procedure with git branching.
Many shops use the Git Flow model.
This page compares several Git Workflows.
Please refer Atlassian Git Workflow tutorial for centralized and decentralized model.
https://www.atlassian.com/git/tutorials/comparing-workflows/
I am new to version control. I often hear these words Merging and Branching. I also see different developers working in different branches.
Can someone explain the flow on this. What is the difference between Merging and Branching. When to go for Merging and Branching
Branching is about isolating a development effort in a specific history, parallel to the main one.
See "When should you branch?": you branch when you cannot commit on the current branch (because it would break the work of your colleagues)
Merging is about reconciling two different branches.
You merge when you want to take into account in your branch the changes of the other branch you need to merge.
The workflow depends on the tools.
SVN offers either merge-based development or trunk-based development.
Tools with easier branching capabilities (like Git for instance) offer a workflow based on the various development lifecycle steps:
In the concept of git,
Branch is just a pointer to a commit, and will be advanced to the new commit when you make new commit to that branch.
Git has 2 types of branches: local and remote.
git can merge any single commit, not only the head of a branch.
I take the most simple merging workflow as an example.
2 developers are working on a project.
They are working independently based on the same version.
They share the master (main) branch via a server when they complete.
The first developer commit changes and push to the remote branch first. The second developer then synchronizes the changes by pulling changes made by the first developer.
A merge commit will be automatically created.
I've got a project where we're rolling out v1, and beginning work on v2. I'm afraid that we're going to see bug fixes and minor feature changes to v1 over the next few months, some of which we're going to need to roll into v2, some of which we're going to need to keep separate. (We need to maintain v1's major feature set, but fix any bugs as they're found.)
We're using SVN at the moment. I've considered switching to Git, but I'm a little reluctant to change tools. Aside from that possibility, what are some general strategies and best practices to make managing this situation as easy as possible?
Update: everyone's suggesting I branch the code in Subversion. That was so obvious to me that I thought it was implied by the "we're using SVN" statement. Apparently not. :) I am going to look at Mercurial and Bazaar as well as Git, though. Anything else?
Using SVN, the best you can do is branch your repository:
In the trunk, keep the latest version - not necessarily a stable one.
Whenever you need to separate a new major version from there, branch to, say, 2.0 and you can keep both latest version and stable versions in the same repo.
If you find changes in branch 2.0 that need to be merged into the trunk, you can do it seamlessly.
we are using TFS, but for your specific problem, the solution will be quite similar: create a new branch.
[Depending the application environment you are using, apparently not Microsoft]
We have benefited from TFS because:
You can do merges between branches [baseless merges]
You can work with workitems, [for bugtracking]
With sharepoint support, you may have documents, test scripts can live together happily at one portal.
With powershell scripts, you can have nightly automerges
For different versions the best practice is to store the named versions in the "tags" subfolder. (SVN docs recommend you have a trunk, tags and branches folder for each project).
Whenever you release a version, copy the trunk to the tags folder and give it a name. That version can live on and bug fixes can be made to it separately and merged back and forth.
SVN docs on repository layout:
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html
You should use SVN to tag the v1 code. That way you can create a separate branch of the code to support fixes to that code base.
Have you considered branching your trunk and doing v2 development on the second branch once the v1 branch is frozen? If you fix bugs on the v2 branch that affect v1 and you'd like to release an update/patch for v1, just merge those specific changes back to the v1 branch from the v2 branch.
All of that is perfectly doable in SVN, but it is much easier to do branch management with a tool such as Mercurial or Git. I can't tell you if it's definitely worth switching or not since I don't know your company or codebase, but it's something to consider if you can forsee this situation arising repeatedly in the future as you release more versions.
Using git you can use the following approach:
Your git repository could have the following branches. Each hotfix branch contains a feature release that must be maintained.
master - version: 3.0.0 (latest release)
\
dev - version: 4.0.0 (next release)
|\
| hotfix-1.x - version: 1.0.1 (current hotfix 1.x)
\
| hotfix-2.x - version: 2.0.1 (current hotfix 2.x)
\
hotfix-3.x - version: 3.0.1 (current hotfix 3.x)
Fixes:
Bugfixes are made in hotfix-1.x and merged "up" into hotfix-2.x and from there to hotfix-3.x.
hotfix-1.x -> hotfix-2.x -> hotfix-3.x ...
Bugfixes can also be backported using git the cherry-pick command from hotfix-3.x to hotfix-1.x (if needed). With the cherry-pick command it is possible to pick one single commit and apply it in a different branch. Git will also detect moved and renamed files and still apply the change correctly.
You can also add release branches in parallel to your hotfix branches in order to prepare the releases in those branches (omitted for this example). This is useful when you don't want to block the hotfix branches for new commits. Please checkout gitflow if you want to know more about the details of hotfix and release branches.
Feature Releases:
New features are based upon the dev branch and merged back into the dev branch once completed. A new hotfix branch is created for each new feature release.
Steps:
Merge changes from current hotfix branch into dev
Merge feature branches back into dev
Create new hotfix branch from dev
Release from new hotfix branch
Merge back into master
Notes:
I think the master branch is no longer very important when you decide to keep your hotfix branches. I belive the common gitflow scheme works that way that you trash your hotfix branches and release branches once you are finished. Your releases should all be tagged and are therefore accessible.