7
KAS89
69d

Used TFS for last 7 years and now have to use GIT. OMG Can't get my head wrapped around it. Everything is so confusing. Online articles don't help a beginner. Send help please. Started using Bitbucket with Sourcetree. Still learning. I hate to say this But I feel TFS is more intuitive. Maybe because I'm new to GIT.

Comments
  • 2
    I really liked using TFS. Git is different and their is a mental adjustment involved in using it. It won't take too terribly long to get used to it. However, it's both easier to screw things up and easier to recover from those screw ups. Just don't panic because there is probably a way fix things when they go south. I've found the biggest problems in using Git revolve around mandates, and Jira hooks, and byzantine process requirements by what passes today for management types (so not git's fault).
  • 1
    I was in the same boat. Now that I've been using git (GitHub) for about 5 years, I prefer it but it was quite the learning curve. Stay with it.
  • 2
    Once you get used to it you'll never want to touch tfs again (unless you use git with tfs since microsoft has seen the light and now supports and recommend that you use git instead of the old tfvc (git is the default source control system for new tfs projects)
  • 1
    Gitimersion
  • 1
    Do you mean tfvc? Since TFS supports (or supported?) both tfvc and git
  • 2
    Source tree is garbage and will confuse you. Use command line.
  • 1
    Ive always used git and have to use tfvc now. What an abomination is that, how does one actually perform code reviews before going to master (why the fuck is there just one branch and stashes (shelvesets)).

    I learned git by using the terminal, GUIs make things more complicated
  • 1
    Since your learning Git and not accustomed to things, stick to the CLi just for the first few days at least, just to get use to what the commands are rather then “oh this button does magic stuff and it shows up here”.

    Plus a lot of the documentation is based on knowing or at least working with the command line so this will help getting familiar with different things.
  • 1
    Breathe. It gets easier. It was super scary when I first started.

    Stick to the basics and you’ll be fine to begin with.

    Just go through the material slowly, try it out in a test repo and then you’ll get betterđź‘Ť
  • 1
    "git from bottom up" is a nice article that explains what actually happens quite nicely, even though it's a bit technical. Maybe it helps.
  • 1
    Thanks guys. I will look more into the command line. I was told to use Sourcetree because it helps new comers like me. Even the name Pull Request confuses me. When you say a pull request, all I think is pulling down. But its actually pulling up right. So things like that. It is hard.
  • 1
    Git is not easy to grasp at first, but it opens up a lot of possibilities you don't even know existed when used properly.

    This is especially important for long-running projects spanning multiple years, when you are going to dig around to why someone made that particular hack 3 years ago (trivial to find in a properly structured git history).

    First step is to understand the terminology and how git works. There are lots of tutorials around here, but the thing to understand is that git is about "commits", which are sets of changes to specific files. Git history is a succession of commits in a particular order. A branch is just a pointer to one of those commit. Merging means telling git to ensure all commits from a branch are one the target branch, by applying any missing commit (and let your resolve conflicts).
  • 2
    By the way, Pull Requests are not part of git. It's a feature of Github (and other platforms using git), to ask to merge a branch to another one, and view/discuss the changes on a website.
  • 3
    @KAS89 this should clear up some of that confusion.

    At a basic level (without getting to complex)
    You have 2 copies of the code base.

    Local (code you edit)
    Remote / origin (code you saved or deployed)

    You always pull from remote to local (downstream)
    You always push from local to remote (upstream)

    A pull request (github) side of things works in a similar fashion where you are “pulling” or merging code you have changed into another repository of the same code base.

    Here’s an image that should help understand how it fits together
  • 2
    @Fradow thats why I prefer gitlab, there a "pull request" is called "merge request" which makes more sense in my eyes.
  • 0
    VELKUM TO ZE VURLD
  • 1
    @C0D4 thanks for the explanation. I watched a Pluralsight course as well. But still kinda intimidated by the whole thing. I'll get there. Or Maybe I'm just that stupid I can't understand git.
Your Job Suck?
Get a Better Job
Add Comment