|
I've used TFS. While the Web UI mildly annoying, I know it and it works.
Git however is a whole different animal. To me it seems very confusing and difficult to work with.
What are you guys using? What's the standard these days?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Git
Despite its higher learning curve I finally took the plunge recently myself. I can live without distributed blah blah blah blah whatever, and I don't care about hype one bit. But, what sold me was it's so much easier to branch and merge in git. Especially compared to SVN. TFS is pretty good about it, but still git shines there.
Jeremy Falcon
|
|
|
|
|
I really only care about Source Control. Do you have any "getting started" resources?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Well, my intro resource was being a n00b to it and asking coworkers a ton of questions. So, I can't really recommend a good online resource. That being said, keep it simple to start with and work on a project with it.
This link will get you going: git - the simple guide[^].
Also, if you're a PowerShell buff, installing A PowerShell environment for Git[^] will give you some fancy visual cues when you're in a project.
Jeremy Falcon
modified 13-Nov-17 14:08pm.
|
|
|
|
|
Are there any Agile tools that work (well) with Git?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I'm still new-ish to git myself, but there's always Jira[^] which will do that. It's like $10 if you host it yourself.
As long the concepts are down I'd imagine you could find a way to adopt most tools to the workflow though.
Anyway, here is the basic concept of agile within git: How Git fits into an agile workflow[^]. Since git makes branching much easier, you'll see people use them a lot more.
Jeremy Falcon
|
|
|
|
|
Jira can connect to your git and link checkins with tickets. I'd advise you to try a GUI app like Git Extensions to do the basics with git rather than struggling with the command line. Once you get the gist you can maybe start to try some things with the command line. Like all non-MS products git is pretty badly documented and non-intuitive and doing anything normally requires decoding SO threads and running commands where you don't understand what they're doing.
|
|
|
|
|
I've used git for about 10 years.
Typically, I'd automate most of it with scripts, and then forget about it existing until something goes wrong and doesn't merge. Then it's of to SO looking for ways to make it to work again.
I've used TFS for about 3 years now and it's way easier. I can just point and click (never used a TFS command afaik) and it's so easy to figure out that you don't need documentation. If you want something that just works, go with TFS. If you need fine-grained control or want to actively maintain everything, go with git.
|
|
|
|
|
VSTS
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Kevin Marois wrote: "getting started" resources?
I think there is a lot of tutorials on youtube, actually. I find those to be the best versus just reading text about something.
|
|
|
|
|
If source control is the only thing you care about, TFS should be more than adequate.
|
|
|
|
|
So if you're really new to git, like myself, I found this a nice thing to work through in around 15 min. Some hands on stuff and you leave with a little less feeling like you don't know what all this is about 
Git Tutorial - Try Git[^]
|
|
|
|
|
|
TFS at work. For personal projects, I have my own. 
|
|
|
|
|
TFS and Git are not mutually exclusive? 
Do you mean TFVC, the Microsoft Team Foundation Version Control that not even Microsoft is using anymore?
TFS supports both TFVC and Git, but I'd recommend Git.
In fact, TFVC shouldn't even be an options anymore because, as said, not even its creator Microsoft uses it anymore.
Branching and merging is a lot better and easier in Git.
Besides, Git has become the industry standard making it easier to find help and documentation.
I've also heard good things about Mercurial by the way.
And I guess SVN is still an options too, although I never hear about it anymore.
I'm not sure if those are supported in TFS though 
|
|
|
|
|
Since I've been using both Git and TFS I can only recommend Mercurial.
|
|
|
|
|
If you use VSO (Visual Studio online) it offers TFS and Git. At work we use Git through VSO.
|
|
|
|
|
TFS works well for me. However, the cool kids at work are clamoring for Git. I think they may know a thing or two more than me about Git, so I'm on a mission to educate myself on the subject before chiming in with my 2¢ worth.
/ravi
|
|
|
|
|
Link I found interesting on git.
GitFlow considered harmful | End of Line Blog[^]
Don't think that explicitly mentions the following...
A git repository only allows versioning for the repository. When you apply a version number or extract a version it applies do all files in the repository. This is fine for single projects.
However consider what happens in an enterprise with an example setup.
- Libraries (sub projects) A, B, C
- Application X uses A and B
- Application Y uses B and C
In the above Git only allows for the following
Scenario 1
- Repository: A
- Repository: B
- Repository: C
- Repository: X
- Repository: Y
Scenario 2
- Repository: A, B, C, X, Y
If you choose one then you must manage each of those. So a release of X means that three repositories must be 'manually' labeled. And each must be built.
If you choose two then B has the same labels as A, and when you pull you get B even if you just want A.
Mitigation strategies can be created but those still exist outside of Git itself. For example creating yet another repository to handle build tools (to insure labeling, dependencies, etc.)
|
|
|
|
|
I believe the standard is more or less GIT.
We switch from Subversion to GIT (hosted on ButBucket) a year ago, and we use TortoiseGit as a front end.
The transition was hard; learning curve is very steep.
The thing with GIT is that it has a lot of advanced features that you need to keep clear of that most people do not use.
Doing simple Code Versionning is easy. (clone, checkout, pull, push commit ...)
Branching is fun and more or less seamless (we do branches for each issue) once you "get it".
This is one tutorial that I used.
Git Tutorials and Training | Atlassian Git Tutorial
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: The transition was hard; learning curve is very steep.
I didn't find that to be true.
I will mention that I have had decades of experience and have used multiple different source control systems so perhaps that changes my view.
|
|
|
|
|
I am just so glad I work alone….
|
|
|
|
|
A_Griffin wrote: I am just so glad I work alone….
Hah! That makes two of us! I still have a coworker that does mostly non-coding stuff. I've made it almost 20 years without source control...code fearlessly! 
"Go forth into the source" - Neal Morse
|
|
|
|
|
I'm using versioncontrol also for private stuff.
|
|
|
|
|
Well, I do too - but as a single developer I can use my own (very) simplified methods, which double as a backup system.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
