A confused TFS user trying to understand GitHub!

I’ve been a long-time user of TFS and am currently giving GitHub a try, but there are a few concepts that I’m struggling to get my head around.

I’m using the Visual Studio GitHub extension, and after making changes in my project I see a button with the options: “Commit”, “Commit and Push” & “Commit and Sync”. What do these do? Similarly I’ve seen options for “Fetch” and “Pull”- what’s the difference?

With GitHub, correct me if I’m wrong but it seems that I first have to “commit” my changes to a local repo then I have to “push” those changes to github.com. What’s the point of having a local repo? It seems like an unnecessary extra step. (In the TFS world, after “checking out” a file and making changes to it on my PC, I would then “check in” those changes straight to the TFS server).

Last question - TFS allows two devs to work on the same file, and does a pretty good job of merging the changes when they both check-in. If it can’t automatically merge (e.g. both devs have changed the same line of code) then Visual Studio displays a “merge conflicts” UI to manually fix such issues. How does GitHub deal with these scenarios?

Disclaimer: I don’t know what “TFS” is.  It might be helpful for you to link to some documentation about it, but I’ll try to answer your questions anyway!

  • Commit"saves" your changes to the local repository
  • Commit and Push commits and then pushes that commit to the remote repository on GitHub as well (so that others can see and pull it)
  • Commit and Sync commits your changes then pushes and pulls (effectively, syncing your local repository with the remote repository).  “Sync” is a GitHub term for performing both pushes and pulls.
  • Fetch asks the remote repository for the list of changes since you last fetched but does not apply them.  Basically it lets you know “oh, I’m 5 commits behind, and those commits changed files x, y, and z”.
  • Pull does a fetch, but it additionally applies those changes to your local repository.

See this Stack Overflow answer for why it’s nice to have a local repository :slightly_smiling_face:.

From what I understand, Git deals with merge conflicts exactly the same way as TFS.

5 Likes

Thanks for the reply - it was very useful thanks. I’m also finding the concept of branching to be a bit different to how we do it in TFS…

With TFS (Microsoft Team Foundation Server) the usual workflow is to have a “main” branch that everyone works on day-to-day, i.e. new features. When we are ready to release a new version of the product we’ll create a new branch (e.g. “Release_1.0”) and create a build from this for release to customers. We’ll then continue to work on the “main” branch, adding new features for the next version of the product. The only time we would make changes on a “release” branch is for a bug fix. After fixing the bug we’ll create a new build from that branch (minor release/patch), and finally merge that release branch back into “main”.

With Github, the recommendation seems to be to create a branch for each new feature. Our small team might implement dozens of new features a week - that would be a lot of branches! I realise you can delete a branch after it has been merged back to “master” but it’s all additional overhead/management, and potential for confusion/mistakes. I realise we don’t *have* to work in this way, but I find it a curious approach (coming from TFS anyway). I’m guessing the main advantage is to support code reviews? (In TFS we do things differently - a dev will “shelve” their changes into a special area, rather than committing them; another dev can then pull down the shelved changes in order to review them).

I would be keen to hear from other TFS users who have moved to Github, if you could share your experiences…

@50wliu

“TFS” is Microsoft’s Team Foundation Server. It’s similar in concept to GitHub’s offering (it has an issue tracker) and was often hosted on an intranet server. It took things beyond their simple source control system, Visual SourceSafe. As with other Microsoft products, it features Active Directory integration for user authentication. If you were working in a software development firm using .NET, the latest version of Visual Studio Team Suite, Team Foundation Server, and SQL Server Developer edition were on every developer’s wish-list.

TFS is a beast to run - it requires Microsoft SQL Server, and is picky about the operating systems that it supports. This might change because Microsoft has been re-engineering its products to play nice with Linux, particulary .NET Core and SQL Server for Linux. It’s one of the reasons why some teams chose to stick to Visual Source Safe, despite missing out on a lot of the features.

GitHub doesn’t enforce a particular branch strategy - I’ve seen many open source projects develop on the head (main/trunk) branch and create tags for each release. This approach keeps things simple because when your project kicks off, branching isn’t the first thing on your platter - the first thing on the list is to build a minimum viable product (MVP).

Having said that, the recommended approach is to create feature branches and merge them into the head because the developers working on independent features do not have to wait for each other to make a release. All of the code sits in the repository and is only merged into the head when the feature is ready to make it to production. All code being committed should be compileable, and it is good practice to ensure that the head passes build tests (the feature branches may be broken during the development process).

1 Like

As @redknitin mentioned, you can use whatever branching strategy works for your team.  I work on Atom, for example, and we use both release branches and feature branches.  The main difference that I can see is that commits get merged to release branches, but release branches are never merged back to master.

In general though, I think that the main feature of branches is so that people can easily check in code that might not be ready for production yet, or to add an experimental feature that they want feedback on before merging.  Interested people can then check out the branch to review it, push their own changes to it, or play around with the feature locally, all without interfering with the master branch.

In my team we’re not using the Visual Studio extension for Git at all. The free Atlassian product called SourceTree appears much more powerful than that, and I really recommend trying out the program.

BTW, if you just want to know a few introductory things about Git and in what ways it is different from other version control systems, you might read this blog post.

I must confess that I have the same problem.  Coming from a background of Microsoft Team Foundation Service and Tortoise SVN, I find that the Git syntax creates a large number of mental speed-bumps.  The biggest problem that I have is the tremendous uncertainty on what the commands actually do.  Workflow is also a major question mark.  While following on-line tutorials, I still had to go through a process of completely re-creating repositories from scratch due to code loss.  Like Mr. Stevens, I have the same questions.  Additionally, the classic question of why do “Pull” and “Pull Requests” go in opposite directions?  The biggest problem with Git is that it requires a Git-to-English guide in front of you at all times.

1 Like