August 28, 2020 at 12:00 am
Comments posted to this topic are about the item What is a Pull Request?
August 28, 2020 at 9:51 am
still prefer TFS, though...
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
August 28, 2020 at 2:46 pm
Noooooooooooooooooooooooooooooooooooooooooooo
August 28, 2020 at 3:17 pm
clearly a difference of opinion between TFS and Git users. I'd love for someone more experienced with Git and TFS than myself to provide some kind of chart that maps similarities and differences between the 2 systems, and why those differences might make one system better than the other as an overall winner.
Or some links that break the operations down in simple words for folk like me, who barely scrape by in TFS as it is.
Thanks
Luther
August 28, 2020 at 3:58 pm
First, they both work great. There's nothing wrong with TFVC or Git. I would say that Git has really won the battle of which one to choose. Most new projects work with Git, even MS defaults new Azure DevOps projects to Git rather than TFVC.
TFS is the server product that does a lot. The version control protocol and system is TFVC. My complaints with it are that the tooling is clunky and cumbersome. The way it groups things together feels unintuitive to me. I find git makes more sense for simple flows and is easier to set up. It's also supported widely, and easily, on Windows, Linux, MacOS, and in lots of clients.
That being said, if you primarily work with MS stack tech, TFVC is fairly well integrated.
Note, I'm not a git expert. I still struggle with some concepts and myself into trouble at times, but I find it easier to get out of problem spaces than I do with TFVC, where I am even less of an expert.
In my career, I've used professionally, these:
I've demo'd and played with mercurial as well.
For the most part, these all do the same thing. The way they do it, in terms of human interaction, is what mostly varies. The idea of how we version files doesn't change much.
August 28, 2020 at 5:13 pm
Good to know, and a nice summary explanation. Thank you. Looks like I still have much more to try out and learn, which is a good thing.
September 1, 2020 at 7:13 am
The summary offered is not strictly true, in that a pull request does not necessarily involve two different branches, merely the incorporation of work after code review into a single branch.
September 1, 2020 at 2:39 pm
Common practice. We don't have pull requests at my current employers (though we use a mixture of git and TFS) but at my last place we did use pull requests but we were not permitted to use feature branches (apart from DEV and MASTER). All work was done on the DEV branch and only when all code reviews etc. had been completed was DEV merged to MASTER.
September 1, 2020 at 3:24 pm
Interesting. I can't find any doc on it, even the git-scm docs for pull-request use branches.
I'm not sure it's a common practice. If you're merging from dev->origin/dev, I'd argue those are two branches.
September 1, 2020 at 3:27 pm
I realise that my data is anecdote, and I take your point about merging from dev -> origin/dev being two branches.
September 1, 2020 at 3:52 pm
I'm glad you posted. I had never thought of a pull request as being on the same branch, albeit a copy that is ahead of a remote. It made me think and look. Thanks for that.
September 1, 2020 at 3:58 pm
My pleasure. I've had endless fun with QotD, never mind all the useful resources, forum etc. (I have a question that I've just posted!) so it's nice to be able to contribute for once.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply