Bitbucket or GitHub for source code storage, versioning and sharing?

[Jason]

@godefroi

Generally you’ll keep a local repository and push to a remote repository whenever you’d like. Even if you never plan to share your source code, you should still be working with a VCS, just in case.

So Git for local repo and VCS and then push to GitHub to share?

[ianlee74]

@ AWESOMEDEVSIGNER - Thanks.

@Jason

@godefroi

Generally you’ll keep a local repository and push to a remote repository whenever you’d like. Even if you never plan to share your source code, you should still be working with a VCS, just in case.

So Git for local repo and VCS and then push to GitHub to share?

This is the first concept you have to understand and one that makes it so different from VSS and older version control systems (VCS). Git repos are always local. When you are ready, you can merge your work into a GitHub/Bitbucket repo or even someone else’s repo on their machine. But, even after you merge/push your changes you are still working on a separate local repo. That’s why there is not concept of “checking out” (locking) a file in Git as there are in other systems. Anyone can modify any file at any time. You just might have to help with the merge later if the changes conflict with changes that someone else made. In fact, you can create Git repos locally without ever creating a GitHub or Bitbucket account. There is no dependency there.

If you haven’t already, I’d recommend you work through this fun little Git tutorial.

Set up Git - GitHub Docs

[Jason]

@ ianlee74 - I think I’m getting it, but as you say, I have some of the fundamentals to organise in my brain before I should be let loose with Git.

[AWSOMEDEVSIGNER]

@ Jason -

Check out the Git-Book here:

http://git-scm.com/book/en/v2

Should be quite enough for a first start.

[Jason]

@AWSOMEDEVSIGNER

@ Jason -

Check out the Git-Book here:

Git - Book

Should be quite enough for a first start.

That’s great. And to think I nearly spent $50 on that at amazon this morning too.

[Jason]

VS2013 with GitHub extension doesn’t look too awful, although I have no experience of anything else. The MSDN articles look like they cover a good bit of ground too.

http://msdn.microsoft.com/en-us/library/hh850437.aspx

[Reinhard_Ostermeier]

@Jason

VS2013 with GitHub extension doesn’t look too awful, although I have no experience of anything else. The MSDN articles look like they cover a good bit of ground too.

http://msdn.microsoft.com/en-us/library/hh850437.aspx

I used it with VS2012, and it was a bit irritating, when you are used to use the TFS integration.
As far as I know the GIT plugin was a bit optimized in 2013.
And if you are not used to something else, it even might make sense

I guess the biggest difference between TFS and GIT is, that in TFS you check out single files for editing (which does not lock them for others) and then check them in when your done (or merge first, if someone else modified it).
In GIT you pull a whole branch, modify it, and then you merge your changes back.
Even that you could work file wise with GIT too, it makes it more complicated.
In TFS I always see, who is working an a specific file. In GIT you have no idea who has pulled the repo, and you can not know on what files others are working.

[godefroi]

Older VCS systems (and TFS can work like this) use a lock-modify-unlock paradigm, where modern systems (and TFS can work like this too) use a copy-modify-merge paradigm. The disadvantages of the older system is that only one person can work on a specific file. That, and some systems (TFS included, at least in older versions) only allowed you to have one “working copy”, because the server kept track of where on disk the client was working.

Modern systems have solved the merging problem (Git especially, it tends to be very smart with merges), and so don’t need to lock (or indeed, notify the “server” at all) before they edit a file.

One nice thing about Git, vs (for example) Subversion, is that if you start working on a file, and someone else has worked on it, you don’t have to “rebase” before you can commit. You go ahead and commit, and then you either rebase or merge when you push. That way, your local changes are never in danger, and are never in limbo between when you made them and when they’re safely stored in the system.

If you like the TFS project system (work items, bug tracking, etc), then you can use Git repositories with it, and have the best of both worlds. Personally, I like GitLab better, but it’s a personal preference thing at that point. Either way, though, I recommend Git repositories.