Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
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).
-
duckWit56696yI 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.
-
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)
-
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 -
C0D4681466ySince 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. -
Brolls31556yBreathe. 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👍 -
swiss-dev346y"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.
-
KAS893706yThanks 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.
-
Fradow9166yGit 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). -
Fradow9166yBy 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.
-
C0D4681466y@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 -
@Fradow thats why I prefer gitlab, there a "pull request" is called "merge request" which makes more sense in my eyes.
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.
rant