|
Not sure if there's a forum for this. If so, I'll move it.
I'm working on a C# WPF app, and I need to get it under source control. The solution has projects specific to the app, as well as references to projects in my framework in other locations. So not all the projects are in the same solution folder. The other projets also need to be under source control.
I need to set up a repo, and get the code checked in. I first tried using SVN on my server, but when I would try to commit at the solution level I got a message saying "Cannot perform commit because the targets are in different repositories". I can commit individual projects, but not the solution.
I've never used Git before, and I'd like to give it a try.
- Where do I get/create a repo?
- Is there a Getting Started tutorial?
Right now, I'm not interested in any other features other than source control. And, I need this pretty quick. So if this is going to take a week to set up, I'll have to find another option.
BTW, Is TFS still up & running. Is that an option?
Can someone point me in the right direction?
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 28-Apr-20 13:08pm.
|
|
|
|
|
I use Git at home and make use of Git Extensions which is a UI for Git, a bit like TortoiseSvn for SVN(which I use at work).
There will be plenty of tutorials out there on Git but you should be able to get up and running with Git Extensions without a tutorial as I think it's fairly easy to understand and use UI.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: Git at home
How is that set up?
Where is the code hosted at?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I use Git in my own personal projects.
I host the repositories locally as well as using github to share some projects online.
So every once in a while I will push my local repository to the Github repository.
Git Extensions interfaces very easily with Github allowing you to push changes directly up to your Github repos.
I am guessing from your original post that version control is something that's fairly new to you.
Is that correct?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: I use Git in my own personal projects.
I host the repositories locally as well as using github to share some projects online.
So every once in a while I will push my local repository to the Github repository.
This sound like you're saying that you 'occasionally' push changes to the server? If so, the code never leaves your PC? Isn't that a bit dangerous?
GuyThiebaut wrote: I am guessing from your original post that version control is something that's fairly new to you.
Is that correct?
Not at all
Git & Github are new to me
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: This sound like you're saying that you 'occasionally' push changes to the server? If so, the code never leaves your PC? Isn't that a bit dangerous?
All my documents and projects are in a Dropbox folder which is automatically synched online.
I have 2TB of online Dropbox storage together with being able to restore to any point in time from the online backups.
If you are familiar with source control I imagine that there are plenty of good intros to Git on youtube as Git is very popular.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Popular or ubiquitous?
I would still prefer a file locking source control system, but then I'm old.
|
|
|
|
|
Hardest concept for me to grasp when starting with git is, Git takes a "snapshot" of the entire repository with each commit and applies only the changes. The hard part about that for me was if you have a file that exists in one branch and not another, switching between the branches will cause that file to disappear and reappear as you move between the branches.
I would suggest using an one of the git GUIs available, my favorite is GitKraken[^]
I like it enough that I actually paid for it. Their tutorials help a lot too.
|
|
|
|
|
> Where is the code hosted at?
The main thing to understand about git is that it separates the concerns of *version control* and *centralized storage*. Initially you can have version control stored locally, and then optionally synchronized to a server. The nice thing is that you can commit local changes, revert, switch branches, etc. without access to the centralized server. The reason this is possible is that you have a copy of the entire repository on your local, including all commits, and that allows you to work offline, for example. The hardest part is synchronizing your local copy with a copy elsewhere, called a "remote". It's not usually bad, but it can get pretty complicated. See https://medium.com/@ottovw/forget-git-just-use-subversion-or-perforce-8412dc1b1644[^]
One way to understand why git is the way it is, is to understand the design rationale behind it. Linus wanted the ability to work while offline, so he could work while traveling: this means that check-out (aka locking) is abolished, merging is the standard approach to check-in (aka commit), tooling keeps track of changed files and also handles branch switching, and viewing history/blame/commit graphs is fast and optimal. It's meant as a DVCS, with a robust security model and scalability to handle projects like Linux (and enables monorepos, for example).
I used to hate git, because it makes things twice as complicated as, say, SubVersion. Honestly, most of the reasons for using git are not applicable to most enterprise development, unless you have massive codebases and teams. Probably the main reasons companies embrace it is 1) everyone else is doing it and 2) it's free. These days, especially after having to deal with even "modern" TFS and its lack of performance, mainly due to its coddling of the developer (omigosh, everything--especially merges--has to go through the server in case a workstation suddenly blows up), I find I'm liking git more and more. There are alternatives like Perforce or PlasticSCM that do DVCS well, if that's a requirement, but they also cost money. If you're just doing a small project, a local git repository occasionally synced with a remote is trivial to set up and easy to use. One may argue that its learning curve makes its cost non-zero.
|
|
|
|
|
|
 That looks interesting, I should check that out.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Since MS took over GitHub, the integration with VS has become pretty good - to the point where I don't go outside it - and the repositories are free as well.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Same as Paul - VS / git can still get quirky if I've checked out/ cloned the same repo on more than one machine on my LAN and haven't committed the changes on all of them - it kicks off a merge and then you get resolve conflicts errors etc - but overall pretty good
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
|
Here's the skinny.
Git Local Repo On Windows
1. Get Git Bash at : https://git-scm.com/downloads
[^]
Yes, this is official git.
2. After installing, you open a Git Bash console window.
3. Navigate to your main project directory and type
c:\MainProject>git init
EDIT -- navigating there in git bash a bit different... it'll be like <code>cd /c/MainProject/ a bit different if you're accustomed to DOS/Windows. It's case sensitive.
4. That creates a repo.
5. copy the following .gitignore for Visual Studio (and WPF)[^] and create a text file in c:\MainProject> directory named .gitignore and save that text. This will create an ignore file so that git will ignore the stuff that shouldn't be in the repo.
6. Run
c:\MainProject>git add . (git add dot) This will add all of the correct files (including the .gitignore) to your repo for tracking.
7.
c:\MainProject> git commit -a -m "This is the initial commit for this project"
Commits the files the first time. Now your changes will be tracked.
8. Next time you change a source file, try
c:\MainProject\>git status
that will show you the files that have been changed.
9. Then do
c:\MainProject>git diff
Will show you changes in the file
Git bash is like linux bash running in windows so ls -al etc works.
Git Remote
Sign up for GitHub account at GitHub.com and then there are some commands you can use to push your changes up. A little more details than can be added here, but very cool. You can keep everything in alignment no matter what machine you are working on.
|
|
|
|
|
Back when I used SVN it VS also didn't like projects from different repos. Only once would show the icons. I think VS Code might support multiple repos.
We use VSTS / Azure devops to host our repos. There are free ones like Github and Gitlab. There's probably an easier way, but I create the repo on there (online), then use the command line to clone it locally and
then work with a ui from there. Check out Atlassian's tutorial on Gitflow, it's nice when the project gets bigger or multiple people work on it.
|
|
|
|
|
|
I'd go for either GitHub or Azure DevOps (the cloud version of TFS), depending on what you want to do with it in the future.
GitLab is a good platform too, but not as popular as GitHub.
All three have a free plan with (unlimited) private repositories.
GitHub is easy to set up, just create an account and they'll give you a five minute tutorial on how to clone, commit and push.
If you want to use CI/CD in the future, all three platforms are still good to go.
Azure DevOps is probably easiest with .NET integration because it's a 100% Microsoft platform.
It should be easy to use GitHub for source control and Azure DevOps for CI/CD, should you want that.
Migrating complete Git repositories later shouldn't be too difficult either.
One warning though, with Git you always checkout everything.
With SVN you could have one giant repository and only checkout specific folders, not so in Git.
So it's recommended to keep repositories small and not, like you seem to want, keep different solutions in a single repository.
Git is quite different than SVN, so keep that in mind.
|
|
|
|
|
The recent Git versions are developing the Sparse checkout capability.
This is being developed actively by the Microsoft team to cope with their "world's largest repository" The largest Git repo on the planet | Brian Harry's Blog[^] problem.
Certain aspects of Git can be daunting or surprising for a while because of its distributed capability. It doesn't 'control' rather it 'verifies' content, allowing devs to actually keep lots of rough drafts and interim versions without polluting the 'official' version (the devs polish their contribution that then is accepted...).
For normal code repos, the whole repo with all history is typically less that twice the size of the basic checkout (e.g. whole of Linux history..)
A nice blog with some good graphics 🌳🚀 CS Visualized: Useful Git Commands - DEV Community 👩💻👨💻[^]
|
|
|
|
|
PhilipOakley wrote: to cope with their "world's largest repository"
Yeah, as I said, avoid large repositories 
That was the feature I missed most when going from SVN to Git though.
By now, I'm used to it and my way of thinking about code has shifted.
I've written quite a lot about Git and I usually warn for how it looks like SVN, but works completely different.
When I went from SVN to Git things were not so good.
It was like SVN with extra steps that were more often confusing rather than not.
That was about five years ago and I know some of my former team ehhh... "mates" still struggle with Git.
By now I love it though, especially how easy it is to branch and merge code, especially with pull requests and code reviews.
|
|
|
|
|
Learn git - it will be worth the effort.
There's an interactive tutorial here:
https://learngitbranching.js.org/
You'll be able to use it locally for projects you just want history for, and you'll be able to easily upload to GitHub. Modern TFS instances are using git for version control because the old engine was so crap. Git won the vcs wars - might as well embrace it.
GitKraken is also quite a good gui client, though I tend to stick to the cli and only use a gui client for viewing history on files - and then it's most convenient to use the inbuilt client in webstorm and rider.
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
|
|
|
|
|
When I have to use GIT (which is becoming most of the time now), I use SourceTree - the GUI Front End that makes it a little easier. I usually break something, so I have to call in a GIT expert and they fix it all up (GIT experts love fixing GIT problems). So, yeah, if you use GIT, git yourself SourceTree. Then, git yourself a GIT expert.
|
|
|
|
|
|
Git is now my preferred way of doing source code control. But the learning curve is ridiculously steep. If you have to get it together in a week, I'd say use Tortoise SVN or something.
|
|
|
|
|
I know a great joke about the Corona Virus; however, you probably won't get it.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
