Configure Git Source Control Provider For Development Team - visual-studio-2010

I'm totaly newbie to Source Control idea, so please be kind.
My situation is that we are a development team which contains 2 developers and 1 designer.
We use Visual Studio 2010 and we need to use a Git as a Source Control.
I've installed Git Source Control Provider and GitExtensions using Extensions Manager on all machines.
But there is only one thing I don't get it, how can I configure every Git on every machine to find a central repositry where we can Push and Update all work in one place?
Does that mean everyone will take a copy of a solution into his own machine (Locally) and configure Git to a repositry OR are we going to run on the same solution?
Honestly, I have not found articles regarding this issue and how teams on same project on Visual Studio 2010?

Git is distributed version control system means that whenever you clone a repository you can work on your copy and commit too. Once you done you can push the commits to remote repository.

Related

Clone code from TFS to Github

Hello I have project which I manage with visual Studio Online and tfs basic online.
But I need to share the code with coworkers who don't want to create MS accounts so they don't have access to the vs online code repository.
Can you tell me if there is any easy way to clone code from one repository to the other?
I'll be gratefull if anyone suggest me tools I should download to clone my code.
You can use GitExtensions, for example, to do this.
Clone Repository from TFS Server (the url is in the Code-Explorer of the TFS Website)
Set the Origin Remote (Remotes/Manage Remote Repositories, there you can set the path of the github Remote (is written somewhere on the website))
Push (for example via GitExstensions)

Git with TFS and exclusive checkouts

I would like some advice on how to use Git locally on my computer along with Visual Studio and a TFS server. Unfortunately the technical leader of my company has set TFS with the exclusive check-out policy and so every time someone checks out a file, it can't be edited by someone else.
What is the right way to make the two systems live together? I would try to use Git-TF but I'm not convinced with the checkin phase. The workflow should be as the following:
clone the project
switch to offline mode for Visual Studio
work offline with Git
fetch from the TFS server and rebase
check-in?
The problem is: how do I check-in my files if someone else has already checked out the files I need to change? How does Git-TF really work when checking-in files?
Another workflow that came to my mind, without Git-TF, could be the following:
open the TFS project
switch to offline mode
create a new branch with Git
work on the branch
return to the master branch, update it
exclusively checkout the files which have been changed on my Git branch
merge the branch on master
check in with TFS (after switch to online mode?)
What do you recommend?

Setting up BitBucket and Mercurial for Use In a Group Environment

My company is currently implementing a versioning system using Mercurial and BitBucket. We currently have respositories set up on bitbucket and are able to use them, but our work processes for doing so are a bit clunky. We use Visual Studio for web programming in .Net. Currently, we have set up a cloned repository locally and work from there. We can do this using Visual Studio with VisualHg.
In order to edit files we open them in Visual Studio from the local repository and make our edits. We then commit our changes to Hg, which updates the repository as it should. Then we need to FTP the files from our local system to the DEV server for testing and then FTP again to the Production server once QA is completed and approved.
It would help streamline things if we could have the BitBucket repository synced with our DEV server so that all that was required is to commit changes for testing in DEV, bypassing the otherwise necessary step of locating and FTP'ing all relevant files.
Does anyone know if this is possible? If so, can you point me to any documentation that would show me how to set this up? Our developers would be eternally grateful. Thanks for your time.
In my opinion, using Mercurial is not the correct solution for this problem.
The main reason for it not being the correct solution is that the files that are in Mercurial are not the files that you want on the production server and so aren't the files that you want to use on your development server (because you want the QA environment to be as close to the production environment as possible). There are no assembly files stored in Mercurial (or there shouldn't be) and those are the files that the server should be using to run the application.
There are deployment tools built into Visual Studio that you can use for this task. They can be configured to upload all the necessary files with one button click.
Scott Hanselman has a post on his blog about this.
Troy Hunt takes it one step further by introducing a build server with this excellent set of posts. It uses Subversion as the repository but it can be done using Mercurial too.
I prefer the build server method as, once you have it set up correctly, it makes it 100% reliable. It will do the same thing every time you ask it to do the deployment. If you use Visual Studio to do it the developer doing the publish could choose different options and get it wrong.

Uploading project to GitHub from Visual Studio 2010

I have a GitHub account.
I have a Visual Studio 2010 with Git Extensions and Git Source Control provider installed.
I have created a clean project. How do I upload it to GitHub?
P.S. A tutorial on this particular topic would be fine.
In order to upload a Visual Studio Project to GitHub one needs to perform a push operation in GitExtension commit dialog.
Basically syncing the project with GitHub server is called "push"ing in Git terminology.
In order to be able to push, one needs to do the following:
Create a local repository. This is covered in detail by both GitHub and GitExtensions manual.
Create a repository online from GitHub account. This is covered in detail by GitHub help.
Map a local repository to an online one. This requires going to Manage Remotes dialog of GitExtensions (accessed via Git->Manage Remotes menu item in Visual Studio main menu) and saving a new instance of a remote repo.
Then, at commit, choose to "Commit & push", and point push to a remote repo created in step 3.
Create a new repository in your github account. It will give you the step by step instructions for you.

Which version control suits best this list of requirements

Our dev team is small (3 developers) and windows based.
I'm looking for a source control that can do the following:
Check out files for editing and warn others that file is used
Check in files and merge if they have changed
Split baselines for release versions and merge baselines if needed
Visual Studio integration
Can work over WAN
Thanks.
SW
Team Foundation Server fits all of those.
SVN would be great, as long as you use locking (normally the server has no idea what clients are doing by default)
Perforce might be a nice one to look at which does this more by default.
Both have VS integration, SVN especially.
SVN, provided that you explicitly lock the files. This is not by default, but you can easily lock the file via SVN commands or via TortoiseSVN.
VisualSVN provides the Visual Studio integration.
If you want good Visual Studio Integration, then check out Microsoft Team System. You didn't specify if you wanted free or commercial or how critical Visual Studio intergration was.
git will do almost all of it. Not sure about integrating it with Visual Studio though. there might be a plugin for that.
Reasons:
No central server needed. If you want one, you can have one, but it's not necessary
You can push/pull changes to the others at will.
Each of you can have your own local branches, and push only the ones you need to
each other. Branching/merging is easy enough to do branch-per-task. Then push just that task to a co-worker if needed.
Unlike SVN, only one directory is needed for git, in the top level of the directory structure.
git stash rocks for when you have changes in your current branch, and need to switch to another for a while. This is one of those things you don't miss until you don't have.
Merges are awesome.

Resources