|
When using git, there is no reason not to branch. Besides, I commit every 15 minutes or so while working, so can't just stash (git equiv. to shelve) and work on something else. Just make a branch (takes about 10 seconds or less) and fix it there. Merging is generally not an issue in git (I have only had one merge conflict in the last month on a team of 7 devs and used to have many in TFS).
|
|
|
|
|
Merge conflicts usually only occur if the same file was worked on by more than one person, prior to check in/merge. We do our best not to let this happen, and "that" is what controls merge conflicts, not the software.
|
|
|
|
|
If you like to manually control merge conflicts, that's great, but I would rather let the software be better at merging and only get involved when there is truly a bad conflict. There are always certain files that are frequently modified (configuration files, common UI, etc.) and if your software can intelligently merge the code for you, then I welcome it. I have used almost every source control software out there in my 30+ years of development (some of them as a build automation engineer) and git gives a better development experience than most (ok, I prefer Mercurial, but the industry chose git and I use github for collaboration on my private projects).
|
|
|
|
|
I've actually had that situation and resolved it relatively easily with Git.
I think Git makes that very easy using the git checkout command.
I'm sure you know that already, but it is quite amazing how you can switch branches in Git so easy.
Much easier than Subversion where I would often start working on the change, only to remember later I needed to branch first.
|
|
|
|
|
"git checkout" just about sums up GIT in a nutshell.
It's a wonderfully easy way to do something but it has an utterly non-intuitive and inappropriate name.
Sometimes it almost feels like the only naming rule in GIT is "be as obtuse as possible."
98.4% of statistics are made up on the spot.
|
|
|
|
|
You're checking out the branch, I don't see the issue with the name? Not that it's an amazing name, many non-Microsoft names do leave a lot to be desired ("Blame" springs to mind), but it's not the worst name either.
|
|
|
|
|
PeejayAdams wrote: It's a wonderfully easy way to do something but it has an utterly non-intuitive and inappropriate name.
Yes, I totally agree with that.
The name of that command is completely non-intuitive to the level of stupidity.
edit
I guess that could be because I used subversion for so long where you :
branch
switch
which seems somewhat intuitive.
However, Git is so far superior to subversion I am willing to put up with bad naming. 
modified 18-Apr-18 9:41am.
|
|
|
|
|
Yes, I guess I'm also still a little bit stuck in a Subversion and Mercurial mind-set.
98.4% of statistics are made up on the spot.
|
|
|
|
|
raddevus wrote: Much easier than Subversion where I would often start working on the change, only to remember later I needed to branch first.
I have a "Clippy" VS add-in that when I start to work on the dev branch it pops up and says "It seems you're working directly on dev, do you need help creating a new branch first?"
I don't, that was a joke. I so wish it wasn't though.
|
|
|
|
|
F-ES Sitecore wrote: I don't, that was a joke. I so wish it wasn't though
Haha, while I was reading the first part, I was like..."Does this person really have something that runs and does that type of thing? Amazing." Good thing you told me you don't because I was really believing it.
Probably because I want that too. It's such a pain when you forget to branch first.
|
|
|
|
|
If it's git you are working with I can recommend SourceTree, it makes doing most git things way easier (for me at least) than the command line.
|
|
|
|
|
Jacquers wrote: If it's git you are working with I can recommend SourceTree,
TFS. And it's not the technology that is the issue, it's the workflow that people said I should use when I asked the question, how do you handle working on A when a bug request comes in for B? And the reason I asked was, sadly, I was afraid the answer was as described.
|
|
|
|
|
Yes...TFS seems to be the best. Not sure about relative front end cost, but the only reason I can see to justify using something else is if it is free, and even then it is probably a stupid move.
|
|
|
|
|
git is free.
Microsoft uses git for much of their development.
git has quite a bit of integration with Visual Studio.
|
|
|
|
|
I had a gent tell me he had 5 years of SVN experience.
I said, great... Then please start using branches and get off the main branch.
He replied... "I've never done branching"...
to which I said... "then you have about 30 minutes of SVN experience, repeatedly, over 5 years!"
He eventually said... "Wow, I wish I would have known about branches before..." ROTFLMAO!
|
|
|
|
|
You need to roll your own so it does what you want and you know how to use it.
|
|
|
|
|
I work contract, so I have worked with a bunch of different source control systems. By far the easiest has been TFS, and it has gotten better with the years.
Issues I have found with other systems:
1) Shelf Set does not exist, and this is so easy to fix bugs in your system, so partial check-ins, etc
2) It seems impossible to have two versions on your system at one time, so cannot easily work on two features at once, and cannot get somebody else's version and do whatever you need with it.
3) The only way to get (git) you code updated when somebody else has posted changes is to commit your changes.
I have not yet found a product that works better with Visual Studio than TFS, and find it amazing that all these companies continue to use crappy source control which they even pay for, which significantly impact developer productivity...typical penny wise pound foolish or maybe just plain foolish.
|
|
|
|
|
1. use git stash (but I rarely use it as I commit locally every 15 minutes or so).
2. that's what branches are for. if you need to work on someone else's branch, have them push it to the server and then pull the branch locally to work on it (do this as often as necessary while both of you work on it or pull directly from their local).
3. merge from [branch you want changes from] to your branch (you should be committing often anyway, so committing should not be an issue).
|
|
|
|
|
I just find it extremely awkward compared to TFS. TFS seems to be almost trivial to use, which is not true with the others. I am more interested in learning to be a better programmer than learning what I consider a badly designed tool when I really don't need to learn much to use TFS. Everything has always seemed pretty obvious.
|
|
|
|
|
One thing I appreciate about TFS is that it is visually and verbally descriptive, particularly when it comes to merges. Merge "from". Merge "to". Thank you. How hard is that for Git and several of the front ends I've tried to actually be clear about that?
|
|
|
|
|
TFS/VSTS also has workspaces. So, as an alternative to shelving the current project and doing a bug fix, you could also just switch to another workspace for the same branch and do the fix there. I've used up to 5 workspaces for our DEV branch when having to move from a feature development to do an urgent fix, which gets sidetracked by a critical fix, ....
I suppose the git equivalent would simply be creating another local repository (git clone)?
|
|
|
|
|
StarNamer_ wrote: I suppose the git equivalent would simply be creating another local repository (git clone)?
I think so. At the end of the day, I think it would be really helpful if there was some training and good documentation on the company's TFS practices.
Just to explain some of the nightmare, there's one division that creates a new branch for every candidate release (the branch is named by month and year) but nobody tells you when you have to check out the new release candidate branch and start working on it. In fact, I was there for a year before I even knew there was this every-3-month new branch. There are some people who have code from 2 or 3 of these branches that all need to be merged together.
Then, there's another team that simply has dev, qa, and prod branches. Note there is no "main" branch. Actually, qa is the main branch. So I merge my local stuff to dev, then cherry pick what gets merged to QA, then at some point those changes get cherry picked to merge "down" to prod. WTF?
|
|
|
|
|
I also find TFS very useful for source control. One can create multiple "TFS workspaces" to simulate cloning a repository (i.e. cloning in Git).
Shelvesets are an easy way to share coffee snippets with others as well.
I will say that Git has a bunch of visual editors now that made using it much simpler these days. Some people I know will forever stick to the command line interface though.
|
|
|
|
|
I am a single programmer. I work alone, not in a team. I always used SourceSafe, still do for my VB6 work.
I tried TFS and SVN for my .Net stuff and find them both confusing and cumbersome, in my circumstances.
Is there a manual, book, or some kind of documentation or tutorial for one of the three? Better yet, is there some other source control system, that integrates into VS2015/VS2017 designed for programmers/developers that do not work in a team? 
Suggestions would be appreciated.
It's a random chance Universe and we are all out there surfing waves of probability...
|
|
|
|
|
Okay, maybe I am insane, but I have never gotten why people have problems with branching/merging whether it is with TFS or GIT or whatever source control. Early in my career, I think 10 or more years ago, I read a white paper from Microsoft on the best practices for handling version control branching in TFS. This may well have been before GIT even existed. The paper was clear and concise, left multiple choices on branching/merging strategies and how to handle conflicts and other problems in source control. As far as I know, that white paper is still out there and available and even though it is old now, it is still very relevant. I read it once, reviewed it a couple of years later and I haven't had a problem with source control since. Everything made sense and it has always been easy for me. Like I said, maybe I am insane, but I encounter many developers that can't handle branching/merging and conflicts and I truly don't get the problem. Maybe you guys can clue me in.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
