I have a question regarding git-tfs integration and how it deals with labels.
While working with git-tfs, how do you deal with labels? Are they imported into git?
Are "tags" also "exported" when pushing changes back to tfs?
Thanks
No, changesets are not tagged or labelled when pushing changes back up to TFS.
When pulling from TFS, git-tfs tags commits with "tfs/default/Cnnnn" tags to make it easy to track the TFS changesets you have pulled, but no other labels from TFS are used.
If you need this I'd suggest you request it as a feature on the github project site.
The development I made to support tfs labels has been merge https://github.com/git-tfs/git-tfs/pull/256
That's now in the stable version for quite some time...
But there is no way with git-tfs to push a tag to Tfs :( because in tfs, a label is not just a tag like in git but a real changeset on its own and it is not easy to make it. I have not needed it, that's why I never developed this feature!
Use the "Source control Explorer" if you want to create a label...
Related
Downvote if you want... but I need a set of simple basic steps that we can follow. We have VS Enterprise, no GitHub add-ons installed. We have a an empty repo created on GitHub. What do each of the developers do after that? There's a local repo, right? Should there be another project on the local machine that commits to the local repo or do we open the project in the repo? If yes, how do we create that other project? What about the .sln file that VS lovingly puts in a separate folder? We have been at this for hours and believe me we have tried every combination of commit/push/sync/goat sacrifice except the right ones. We cannot reproduce consistent results such that two developers can work against the same remote repo. Sometimes one developer can push and he doesn't see the files pushed by the other developer. Sometimes the Commit Message text box lights up but the Commit button is disabled. I thought I was reasonably intelligent until I started working with GitHub.
I'll give you the broad steps you need to do. You may need to fill in a bit of the detail. THis is how I would work it. I am sure you could get many other opinions.
Create the repo on GitHub (which You already have done.)
Each developer should then go to the GitHub repo and fork the repo under their own GitHub account.
Each developer then needs to clone their repo to their local machine. (That's the beauty of Git. Every developer has the entire repo locally.) You can do this in VS2015 by choosing: File -> New -> Repository -> Clone.
Go to your on-line repo and get the URL of the repo that you will be cloning. Enter it into the New Repo dialog box in VS.
When working on the project, each developer should create a temporary feature branch, which they push to their own GitHub repo. They can then push their work as often as they want without it conflicting with other developers.
When a developer thinks that their work should be merged into master, they should go to GitHub and issue a "Pull Request" for their feature branch.
Their PR can then be discussed among the team before it is accepted.
Once it is accepted and merged into master, the developer can delete their feature branch locally and on GitHub, if he likes.
Since "master" on the team repo has now been updated, each developer will need to pull down master from the team repo to update their own local and remote repos.
It sounds more like an how-to-use git issue. You probably first need to see how two collaborators work on same project with git. I donot think either VS or GitHub has anything to do here, as both only provides you git gui tool regarding this issue.
I am the sole developer on a project for my client.
Clients wants me to checkin (process/formality) the source to his repository in Bitbucket.com. However, I use the TFS VisualStudioOnline.com
Bitbucket: His motivation was to look and have an internal deposit of my regular code for weekly draws.
VisualstudioOnline.com: For me, I use TFS extensively and need to maintain my checkins here, with my code and builds.
Questions: How can I maintain/add two source controls on one project? (where one project is mostly a readonly/view only checkin)
That's very easy: just add an additional remote to the Git repository, something like
git remote add customer http://bibucket.com/whatver
If you want to "filter" what you push to customer, say have one commit instead of three, then things starts to complicate a bit.
I am using TFS2012 express. I have a project which has two branches.These two branches have similar file and code. Actually one is release code(one which i gave to customers) and another is testing code. I always change code in testing code branch. So sometime i need to checkin this changes to both the branch. Also some changes i don't want to check-in to both and only to testing code branch. So how i can do it in tfs? Problem is how to checkin only certain changes to both branch and some changes to only one branch?
You can always check in the changes to testing branch. If you need certain changes in the release branch as well, you can use Merge command to do that.
When you do Merge, you can choose "Selected change sets" instead of All changes. When resolving conflicts in mergetool, you can choose/make the changes you like in the result panel at the bottom which is editable.
I just setup AnkhSVN after having used TFS till now
What in AnkhSVN is the equivalent of shelves that I would create/use in TFS?
The closest equivalent to shelving in Subversion is to create a branch and switch to it, commit your "work in progress", then switch back to the trunk. Later on you can merge from that "shelf branch" to get back to where you were. When evaluating TFS and Subversion before using either of them in anger I expected shelving to be really handy and an ability I'd miss in Subversion - but I've found that branching and switching is so simple in Subversion, it's actually quicker than using shelves anyway.
Subversion does not currently have a feature equivalent to shelving changes in TFS.
Your best bet would be to create multiple concurrent branches for different features and merge the branches back into your trunk when the associated feature/changes are complete.
The following blog post has a lot of information on how to do this: http://markphip.blogspot.com/2007/01/shelves-in-subversion.html
For personal projects I use Git for SCM, but at work we use TFS. One thing that I like about Git is that it allows a person to easily squash all the changes made in a branch when pulling the changes back into the master branch.
The benefit of this is that if their is anything wrong with the changes they can easily be removed be reverting back to the version before the merge even if no tag was created.
Is this. or the equivalent possible in TFS? Is this where shelving changes fits into the equation?
Thanks.
Performing a merge in TFS results in a single commit; all of the changes from the source branch get rolled up into one changeset pended against the target branch. So as far as I understand your question, the answer is "yes".