How to use source control
-
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).
-
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 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.
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?
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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.
-
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.
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.
-
NOT. 1. Check out the dev branch. 2. Start working on a new feature 3. You're asked to fix a bug on the same project not related to the feature you're adding. 4. Manually copy the code to somewhere else that you've been working on for the new feature. 5. Revert your local branch back to the master version 6. Fix the bug. 7. Check in the change. 8. Manually copy back the code that you were working on for the new feature. 9. Manually add back in the bug fix. 10. Keep working on the feature. Yes, this is actually what I was told as "how to do it" because branching can get too complicated. :laugh: :rolleyes: :sigh:
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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?:confused: X| Suggestions would be appreciated.
It's a random chance Universe and we are all out there surfing waves of probability...
-
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?
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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)?
-
NOT. 1. Check out the dev branch. 2. Start working on a new feature 3. You're asked to fix a bug on the same project not related to the feature you're adding. 4. Manually copy the code to somewhere else that you've been working on for the new feature. 5. Revert your local branch back to the master version 6. Fix the bug. 7. Check in the change. 8. Manually copy back the code that you were working on for the new feature. 9. Manually add back in the bug fix. 10. Keep working on the feature. Yes, this is actually what I was told as "how to do it" because branching can get too complicated. :laugh: :rolleyes: :sigh:
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
-
NOT. 1. Check out the dev branch. 2. Start working on a new feature 3. You're asked to fix a bug on the same project not related to the feature you're adding. 4. Manually copy the code to somewhere else that you've been working on for the new feature. 5. Revert your local branch back to the master version 6. Fix the bug. 7. Check in the change. 8. Manually copy back the code that you were working on for the new feature. 9. Manually add back in the bug fix. 10. Keep working on the feature. Yes, this is actually what I was told as "how to do it" because branching can get too complicated. :laugh: :rolleyes: :sigh:
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Check out the dev branch. Create a new local branch for that feature. Start working on a new feature You're asked to fix a bug on the same project not related to the feature you're adding. Commit your work for the new feature to the local feature branch. Checkout the local dev branch. Pull to get anything from origin that has been done since you started working on that new feature. Create a new local branch for that bug. Fix said bug. Commit your work to the local bug branch & push that bug local branch to origin and start a pull request. While a peer or lead checks over you code in that origin/bug/branch, you checkout your local feature branch. Continue working on feature. Reviewer tells you that you should change something. You grab a stress ball in one hand while reading their review all the while thinking, "Who is s/he to suggest that it could be better...," until you see the glaringly obvious bug. Commit your work for the new feature. Checkout the local bug branch. Implement the suggested code fix. Commit and push (to the origin/bug branch.) Re-request pull. Pull goes thru and is merged to dev on the server. Checkout local dev branch. Pull from origin. Checkout local feature branch. Merge from dev. Delete local bug branch. Continue working on feature until finished or you get another, "If you could fix this bug (and by bug they mean that they want a font size change), that would great..." Then restart the cycle started in step 5. If feature branch is done, commit & push that branch to origin, ask for a pull request for that branch. Do anything to implement any feedback from pull request until is right. And then see what they want you to work on next. No one needs to know how many local branches you're working with. We are talking about Git, right?
-
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?:confused: X| Suggestions would be appreciated.
It's a random chance Universe and we are all out there surfing waves of probability...
I started using Git about five years ago and have never looked back. It's great for teams and individuals. It's great for working offline or online. It's great for any language, and it works great on various OSs. Microsoft has embraced it both by offering integration with VSTS, Visual Studio and all code samples being on GitHub. (i.e. I can use Git integrated in VS w/ any Git repo like GitHub, BitBucket, VSTS, etc.) Git is great for individuals because it doesn't require a server. And when you do want to move to another computer, you can just copy the folder that represents your repository to the other computer. But why wouldn't you use one of the many free servers like VSTS so that you can keep your code backed up in the cloud? You can pull any repo to any computer and then just checkout whatever branch in the repo that you were working on. (ie. you should never work in the dev or master branch!) My advice is to do a few tutorials. Learn the CLI first, and then download a GUI, or just use Team Explorer in VS. But don't freak at how much there is to learn. It's very intimidating, but you'll find that you rarely have to do much other than add, stage, commit fetch push and pull. And when you do get stuck, you just google it. Every once in a while someone who wants to get into programming asks what language they should learn, and I say whichever one you want as long as learn Git first. It’s the gateway to keeping code safe, collaborating, and keeping your development from going down the rabbit hole.
-
Check out the dev branch. Create a new local branch for that feature. Start working on a new feature You're asked to fix a bug on the same project not related to the feature you're adding. Commit your work for the new feature to the local feature branch. Checkout the local dev branch. Pull to get anything from origin that has been done since you started working on that new feature. Create a new local branch for that bug. Fix said bug. Commit your work to the local bug branch & push that bug local branch to origin and start a pull request. While a peer or lead checks over you code in that origin/bug/branch, you checkout your local feature branch. Continue working on feature. Reviewer tells you that you should change something. You grab a stress ball in one hand while reading their review all the while thinking, "Who is s/he to suggest that it could be better...," until you see the glaringly obvious bug. Commit your work for the new feature. Checkout the local bug branch. Implement the suggested code fix. Commit and push (to the origin/bug branch.) Re-request pull. Pull goes thru and is merged to dev on the server. Checkout local dev branch. Pull from origin. Checkout local feature branch. Merge from dev. Delete local bug branch. Continue working on feature until finished or you get another, "If you could fix this bug (and by bug they mean that they want a font size change), that would great..." Then restart the cycle started in step 5. If feature branch is done, commit & push that branch to origin, ask for a pull request for that branch. Do anything to implement any feedback from pull request until is right. And then see what they want you to work on next. No one needs to know how many local branches you're working with. We are talking about Git, right?
Daniel R. Przybylski wrote:
We are talking about Git, right?
No. TFS. And when I asked "do we create local branches" the answer was "no, managing all those local branches is too complicated." :rolleyes:
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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.
nightsoul94 wrote:
Maybe you guys can clue me in.
The problem is more with the arcane syntax of the CL in Git or the obtuse wording. For example, in TFS, there are the terms "source branch" and "target branch" and I truly have no idea what "source" and "target" are referring to. While it sort of makes sense that "target" is the branch I'm merging to it never seems to do the right thing when merging conflicts. Or in SmartGit "select the branch or commit to merge" - but I'm merging from one branch to another, so saying that doesn't give me any indication of whether I'm selecting the "from" or to the "to" branch. And then the two options as buttons "Create Merge-Commit" and "Merge to Working Tree" - I have no idea what a Merge-Commit is, and even less what a "Working Tree" is, why there are these options, what they do, and what the implication is. Basically, to figure this all out, I would have to set up a play project, create some branches, change some things, try out the variations, and figure out what it actually did. Maybe my brain just isn't wired for all this. I have a visual concept of "the server" that has stuff, my "local" machine that has stuff, and all I want to do is say "get my local stuff onto the server stuff". Maybe I have branches locally, maybe the server has branches, at which point my head starts implode.
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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?
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Daniel R. Przybylski wrote:
We are talking about Git, right?
No. TFS. And when I asked "do we create local branches" the answer was "no, managing all those local branches is too complicated." :rolleyes:
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I'm sorry. Not for my reply, but that you have to use TFS source control :(( I always found branching a nightmare in TFS SC.
