Git and Github are part of every developers daily life acting in unison to provide version control and cloud storage for your code. Together they enable a safe and communicative way of working. Rather than provide some type of getting started tutorial I’ll just make a few comments about some of the most valuable aspects.
If you have no command line muscle memory the Github desktop app is brilliant. It makes it super easy to initialize and clone or add existing repo’s. The diff’s are really well highlighted and it’s quick and easy to read through commit history or change branches. Check out https://desktop.github.com
From the command line
If you’re workflow is at the command line please ensure you use oh-my-zsh or something where you’re current branch is visible in your prompt. But it is a right of passage to make a bunch of changes on the wrong branch 🙂
Every team and every project has a different way of organising so I will make no suggestions other than to say be really careful how you synch. I’ve made the mistake of working away on a task for too long with out pushing changes and pulling from the main dev branch. This isn’t always a problem but I was working on code that another was and so there was a really big merge conflict to handle.
For example you would need to add npm modules and python environment details to ensure you’re not uploading gigabytes worth of files that are specific to your machine and require updates. It makes commits and pushes much much quicker as you are only versioning your work. But Flavio does provide an argument for doing so here: https://flaviocopes.com/should-commit-node-modules-git/
Simply type this command in your project directory to get a nice print out of your commit history. You can grab the unique commit identifier here such as:
I’m trying hard to change my work pattern of hopping between tasks as much. This command helps me when I’m not really done with a change or update that I don’t feel like committing. This quote sums it up well,
“Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch).”
The docs will do more than I can here – (https://code.visualstudio.com/docs/editor/versioncontrol) but VScode provides a nice integration – I find it more intuitive than IntelliJ if I’m doing more than a simple commit.
commit – m “write something useful”
This blog was very helpful for me in my early days of getting a project set up – I would love to say I follow the authors advice 100% but it’s not easy! Re-reading this today gives me the motivation to re-commit (lol) to better messages!