Recommended
More Related Content
What's hot
What's hot (20)
Similar to Git - A better source control
Similar to Git - A better source control (20)
Recently uploaded
Recently uploaded (20)
Git - A better source control
- 1. LECTURE GOALS • Learn about existing new advances in Source Control • Don’t expect TFS to change anytime soon. • Not just a theory – Use it right now.
- 2. SOURCE CONTROL Help it to help you By Vitaly Belman
- 3. DRAMATIC NEWS What: New source control type support – Git (DVCS) Client support: Visual Studio 2012 (Beta) Server support: TFS 2012+
- 4. VER SION HISTORY OF SOURCE CONTROL STONE AGE Single user No repository
- 5. VER SION HISTORY OF SOURCE CONTROL BRONZ E AGE (1980) Local repository Single user
- 6. VER SION HISTORY OF SOURCE CONTROL SILVE R AGE ( 1990) Remote repository Multi-user
- 7. GOOD ENOUGH
- 10. SCENARIOS C# v1 C# v2 C# Unit tests v3 C# v4 C# v5 safe C# v4 C# v5 safeC# v5 fast
- 11. CHECK-IN Check-in? Get latest C # v1 C # v C # Unit tests v3 C# v5
- 13. OTHER REASONS TFS server backup Code history search TFS
- 14. WHY CAN’T WE DO ALL THAT TFS
- 15. * Distributed Version Control Systems * Git – A kind of DVCS source control. Originally developed for Linux. Production
- 19. * C# v1 C# v2 C# Unit tests v3 C# v4 C# v5 safe C# v4 C# v5 fast C# v6 safe
- 22. * *You can search, filter and investigate everything easily. *And if the central server dies? You got as many backups as you got developers. *…And more! TFS
- 24. * *This is the basics of DVCS and Git *Nice UI in Windows - Works well with Visual Studio *Already in use by myself *Completely transparent to TFS *If you have other, unmentioned issues in TFS, Git can probably help. *I will send further instructions by email *I’m available for questions
Editor's Notes
- 30/1/2013Beta in VS2012 as VSIX. Integral part of VS vNext.It is dramatic because even Microsoft admits that TFS Source Control is getting old.What is Git? What is DVCS?Why should we care? How does it make my life easier?
- Why we need source controlSingle user and no repositryCopy and paste
- Single-user and local repositry1982, RCS. Still comes preinstalled on Apple computers.So.. How do you work with other people?
- Multi-user and remoterepositryCVSSVNTFS
- Why should we continue developing source control?What’s wrong with a central server? Aren’t we happy already?[Animation]Even if you think you’re happy, I’ll show you why we aren’t happy.Then I’ll show you how we can improve that.Lets go over some problems in central servers, specifically, TFS.
- You went, during the weekend to a beautiful nature mountain.You open the laptop to work. Now what you can’t do: History, Merge, Compare, Check-in. Nothing that requires connection to central sever.You can check-out, in offline mode, if you’re REALLY brave.This is relevant if you use want to code on a bus, or form home.What can you do? Use VPN (which is a chore and slow) or go to the office.
- So now you at the office and you can start coding properly.Before you start editing however, you have to open the file in Visual Studio, because any other editor will tell you that the file is readonly.If you need to edit a word document, you’re going to have to take a trip to TFS, find the file and check it out.So Visual Studio open and you write some code. Then you find bugs in that code and fix it with more code.You don’t check-in yet, however, because you need to write some Unit Tests.Then you still need to do a code review after which you have to do several changes.Now you think you’re ready to check-in. Then you discover your that a cat sat on your backspace key.You just worked for the whole day without doing any kind of backup. And why not? Because you couldn’t commit uncomplete code, because you had bugs because you had to do a code review.The fact remains, you wrote a lot of complex logic, without backup.And even if there is no cat, and your actual files are intact, there could be a horrible new bug that appeared only in v4 version (or perhaps v3?) or just some unwanted behavior.Source control should be helping you exactly in cases like that.
- So you recovered you code, manually reverted whatever changes you needed.Before you proceed, however, you had another quick fix to put inside. You can do it in 2 ways however, one is faster, the other one is safer.So you start with the safe one. Now with that done, you also want to do the fast version. But your original version, v4 no longer exists.So lets assume you saved it beforehand.Now you have to store your “v5 safe” version on the disk and revert to “v4 version” and develop “v5 fast” version.Now we did all that mess and there are 3 versions of the file involved – v4, v5 safe and v5 fast. What there was more scenarios? Or, what if you wanted to develop the v5 versions further in both scenarios? How complex would it get? Will you remember all the changes? Will you be able to easily restore a specific version?Congrutations. Now you are acting AS source control instead of using one.
- So now you have the super final version you want to check-in.You want to check-in. What you should do before you check-in?Your code probably will not pass the Zahi & the gated check in.So what you really need to do? A get latest. That means of course that your code is getting merged.Know what else is getting merged into your pretty code? Bugs.However, now you no longer have your original code. It was merged by TFS and to find the bugs you have to debug it from scratch to see what happened.So your code now looks different and no longer works. You can’t easily reproduce the working version and you can’t easily debug it.That is going to take a while.
- In another day, you decide to work on a feature with a buddy.One way to do that would be to write half-feature on your desk and check-in. Then have your buddy do the same.Basically it means we’d putting incomplete code, that isn’t ready for production to source control just because we have no other means to collaborate.Another way is to go to Zahi, request a new branch, work on it and then merge. But… TFS branch and merge are complex and long processes that you would probably like to avoid.
- In case of a trouble with TFS, nobody can’t work. All our history is lost and we have to wait for it to restore to do any kind of work. Unless of course that restore is on fire as well.But lets ignore it, I mean, it isn’t REALLY our personal concern. It is hardware stuff.How about searching in history? For example, you’re looking for a certain code that you KNOW that existed sometime. You just can’t do that.For example, you see something in the log, but you’re not sure which file from which version. actually writes it into the log.
- We can’t do all that because we lost control over the source control.It used to be local. Now we gained the power to work on the same source with ALL the other users, but we lost all the control on the source control.Now lets see the source control can be developed further make these issues easier.
- Now we’re in the future. You know because it is cool blue color and the title of the slide is in the bottom. Also, it is the year 2000. 2000!DVCS stands for.. Distributed Version Control SystemsHere is how it works. In TFS, we have a central source control and this develop working and depending on it.In DVCS however, the developer is no longer working against a central source control, instead, he has his own source control on his computer.The source control he has on his computer is a real source control system, exactly like the one on the central server, with all the history and the data. While he works, he commits his changes to his local source control and only when he’s ready, he pushes all the changes to the central server.All the other developers also have their own Git installed on their computers.To share all this code, we have a source control server. However, this is just another source control server. It isn’t different in any way from the source control that the developers have.We use it just because we’d like to have a central server that everyone can work against.Lets see how it works when there is a new developer joining the company.
- So we have a new developer that just joined the company. He initiates his local git using the “clone” command.Then he create a new file, and when it is read, even if not complete or code reviewed, he commits its. Note, it is a real commit, with history and diff and everything.Now it is stored in his local source control. If, for whatever reason, he wants to go back to that version of the file he can do it easily.Now the programmer conitnued to code, he do several more commits.When he’s ready, he’ll push all the changes to the server. Now that the changes are on the server, they can be get by anyone.Here is how a commit works.First the develop commits his work. At this point, it is only stored locally.Once he feels ready to show his work to everyone, he pushes it to the central server.Now, whenever a second developer wants to get the latest changes, he pulls them from the central server.The change now probably doesn’t seem too drastic, but lets see how all the previous mentioned scenarios change with DVCS.
- All the operations we mentioned before require a version control. However, since the version control is already on our computer. We can do all of that.The only thing we can’t do, is “Check out” and that’s because
- First. We no longer require Visual Studio. We can edit our files in any client (e.g Word). And we can create files and Git will know it when we commit.You can use any editor, including Visual Studio. Just like SVN, Git will detect changes by scanning the local files.
- As before we’d like to create 2 versions of a file.However, now instead of just changing the v4 version, we write v5 and commit it to our local source control on a new local branch.Going back to v4 is as clicking. Now we create a new branch for the fast experiment. Again, it is just as easy as clicking.Now we have 2 branches and we can develop them induvidually. So if we want to develop v6 further, we can do just that.
- As before we have to get the latest before we can push our changes for everybody.However, unlike before, all our local changes are saved in our local DVCS. The changes we pull from the central server don’t just delete ours. Instead, they are lying right next to our changes.Our code is still working and we can gradually merge them, and in case anything goes wrong, we can always rollback to our original working version.
- We got 2 developers that want to collaborate on a code. So I wrote the v1A and the other developer wrote v1B.Each of us working with our own Git server. Now, since every Git server, can act as a server for other users, we can easily agree on having the other developer push his changes to my Git server.This acts just as a regular source control – We got history, merging, comparing, etc. But since our work doesn’t concern others, we don’t even have to push it to the central server.When both developers are ready, they can push the changes to the production source control.
- Additional scenarios:A change in file that only part of it should be checked in.A config file that you don’t want ever to check-in.A check-in comment that keeps getting deleted because the check-in fails and you have to re-enter it.
- Now we are at Jajah, and although I know that everyone is already rushing to change TFS to TFS+Git, but we have to remember. TFS+Git is in a very early stages, so we’ll have to wait with that a bit more.What we can do, however is using Git on a local developer workstation as a bridge, in fact, that’s what it is called: Git-Tfs bridge.Here is how it works. We have our TFS server, with the gated check-in and all all the rules.When we run “GitTfs clone” we are creating a Git server on our computer that functions just as a regular Git.We can commit changes to it, create branches and work as much as we want until we’re truly ready.Once we are ready, we can push the changes to TFS and we can do it using the regular TFS check-in window (Choose work item, reviewer, etc). TFS isn’t aware at all that all this time we’ve been working with Git.