Git is everywhere these days, and I can’t really remember how I used to cope without the power of local distributed source control and quick branching. But once in a while I find an old SVN repository I need to convert to git and then push to a git server like github. Here are the easy steps to switch a repositiry from SVN to git and keep the full history. Much is based on the excellent Pro Git book http://git-scm....
TL/DR If you want your pull requests to be taken seriously you probably need to learn some more advanced git features like interactive rebase and squash. Fist I wanted to share an article I found when helping folks that struggle with code review/pull request comments like “Can you rebase that” or “I don’t want to see all your workings – please squash your commits”. If that applies to you, I suggest you have a read of Git Interactive Rebase, Squash, Amend and Other Ways of Rewriting History....
After deploying a website don’t assume it succeeded - add automated tests to check everything works. Back in the old days you would open a browser and check your new version of the site works - make sure IIS is running, the app pools starts, your database login credentials are valid etc. A human sanity check is always good - i still do it often - but ideally I want to know during deployment if something simple like that has caused the deploy to break the system....
Code reviews, the process of showing your hard work to another developer and having them tear it to shreds, are often an unloved part of the modern development cycle. The project manager asks why you would change the working solution, the tester refuses to test something twice, and you have to make your colleague admit on closer inspection their masterpiece has an awful double chin. However it doesn’t have to be that way; code reviews can become part of the daily process and you and your colleagues might start looking forward to showing each other work and sharing knowledge....