The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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.”
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.
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.
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
2. After installing, you open a Git Bash console window.
3. Navigate to your main project directory and type
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.
c:\MainProject>git add .
(git add dot) This will add all of the correct files (including the .gitignore) to your repo for tracking.
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
that will show you the files that have been changed.
9. Then do
Will show you changes in the file
Git bash is like linux bash running in windows so ls -al etc works.
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.
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..)
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.
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
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.
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.