Git / Github tips for beginners?
As a beginner, it took me a significant amount of time to appreciate version control systems. Since it is branded mostly as a collaboration tool, as a solo dev I thought I won't need that. I know things can be overwhelming the first time you see Github ( what are commits? PRs? Branches? ), but even you understand the major theory behind git there are also some conventions ( good commit messages, usage of branches ) that serves as barrier to entry for beginners to collaborate in repos.
Fellow IH, could you share some tips/conventions that you use to help those new in Git.
Personally, what sold me is the ability to run CI checks before merging a branch to the master. It's so cool the first time I learned that.
Here are some things I learned over time:
Whether working on a solo project or with a team, I commit often. I can't really explain how often because that depends on the project. But there are some guidelines I follow. After completing a feature, I commit. One bug fix per commit. If the feature is big, you are probably breaking it into smaller manageable pieces, so each piece is a separate commit.
My commit messages start with a verb in the present tense. "Fix issue in X", "Refactor Y component". They're also imperative, which means it's written as though it's a command. (borrowed from here: https://chris.beams.io/posts/git-commit/. TLDR: git itself uses the same convention)
Any type of derived file go into
.gitignore. These include binaries, node_modules, builds. Also don't commit the.envfile. It usually has API keys.First of all, check out this medium article it's a great one to read. Also, don't give up 😄👍! It's tough to learn all the terminal git commands at the beginning, but will be worth it because you will be using version control for as far as the eye can see.
Also, get some practice with contributing by checking out this awesome repository of TONS of other repositories to contribute to.
Wish you luck! 😃
Stay organised. Prune branches both on your local and remote repo's as work is merged in. (Sounds simple but you would be surprised how many people don't) One day you will wake up and see so many branches that you will not know which work lies where. bugfix/ feature/.
https://gitbetter.substack.com
Thank you @petecodes for mentioning GitBetter
GitHub features are useless if you're solo, just use it as a backup service.
Here is one tip: avoid commiting large files like pictures and binary files. These are stored in the history forever, unless you rewrite it. Use .gitignore to exclude binaries.
I disagree with the first point.
You can use GitHub Actions to deploy your system to production as commits are made to the
masterbranch. This is useful because you can then work on incomplete things in a separate branch, and then create a Pull Request towards themasterbranch when you are ready to deploy.Additionally, you can use GitHub Projects as a task management system for yourself. I find this super useful.
You can also use secrets for hiding away things like deploy-keys and passwords, secure in the repository settings, which are then accessible only from your actions during deployment, and therefore not part of your code.
And then there's a ton of apps for all kinds of things. For instance, there's one of my products (Pull Dog), which will (for free) create a test environment automatically for each of your pull requests, so you can test how things work. Not just on your machine, but on a real server in the cloud.
If you need a guided tour on how I use GitHub over a call and screen sharing, let me know!
Let's write a book on git/GitHub. It would make a great growth engine for https://dogger.io
That's a great idea - I'll be sure to make a blog post on it soon!
Not game for ebook on github?
Task management aside, why don't you just deploy from your computer?
Fair point, and that's where my second product comes in to play (the Dogger CLI):
https://medium.com/@mathiaslykkegaardlorenzen/hosting-a-docker-app-without-pushing-an-image-d4503de37b89
That being said, I just feel like things like secrets and so on should not be located on your machine. I like the idea of hiding those away. It's a matter of time before they end up in your GIT history by accident.
I also feel like describing your deployment process in GitHub Actions is a good idea for "documentation purposes". Configuration as code is super useful for exactly that.
Human deployment manually might fail. Automated deployment makes it less likely to fail, while also describing the process more clearly in the deployment code itself.
Hi @justfizzbuzz. My team just launched Lepsta, github/git alternative that will make you version control life easy. Let me know if you want to be early testers.
@justfizzbuzz I have started a newsletter Git Better. It covers tricks and advanced topics of Git you can start using right away in your workflow.
eyy that's cool. I'm in
Use git aliases to shorten the commands and most common misspells, super useful. Example: https://twitter.com/VamsiRao7/status/1233256701379276807
This comment was deleted 3 years ago