Git is an awesome tool 😄
Lost files could be recovered from the server.
Because the code is not located only locally on the computer, but also on a server, it can be accessed from anywhere in the world.
Snapshots of a project are stored with an easy access.
Recorded snapshots make it easy to undo mistakes and go back to a working version.
A bug can be tracked back to its origin by finding out exactly when it started occurring. Git has a cool tool for binary search over commits (git bisect).
- Many developers can work on the same code.
- Several features could be worked on simultaneously, and switched between
- An idea can be easily discarded if it turns out to be a bad one
Let's start with the definition of some important terms that are used to create the Git world.
A repository ("repo") is a directory that stores the content of a project, and some additional metadata. The repo stores the files themselves, the versions of those files, commits, deletions, and more.
A fork is a copy of a repository at a certain point at time.
The conventional name for the primary version of a repository, in the remote server.
A branch is a version of the repository that diverges from the main working project.
A commit is a snapshot of the repo at a certain time.
A PR is a request for merging all commits from one branch to another, enabling multiple colaborators to discuss the proposed changes before integrating them into the official project.
An upstream branch is the branch tracked on the remote repository by the local branch
There are two ways to work with Github - HTTP and SSH. Working with HTTP was probably simpler until Github changed the privacy conditions and decided to add personal access tokens with an expiration date. An explanation about token creation could be found here. The recommended way is using SSH. It is easy to configure, and once you counfigure it you don't need to think about it anymore. To use SSH you need to generate a key, and add it to GitHub, as explained here.
Content...
Sometimes you may not want to track all your files with Git. This includes some local caches, IDE automatically generated files, some local configurations etc.
Configuring a .gitignore makes Git ignore these files and not showing them during staging. GitHub has a feature that generates a .gitignore when creating a repo.
A readme file is the place to write some information about the project using a free language. These include installation instructions, usage instructions, and any other useful information for someone that views the repo without any previous knowledge. GitHub knows to create a fun preview from this file. The file itself is written in Markdown.
When working on a project with Git, you want to follow a workflow that will help you to enjoy your work:
→ [OPT][ONCE] When working on an opensource project, fork it.
→ [ONCE] Clone the repo
→ Never commit to master - always checkout to another branch before you start writting code. It's recommended to choose meaningful names for branches, as the name of the PR will be the same as the branch name. The convention is <purpose>/<name>, for example feature/<name>.
→ [OPT] If you want to work on another feature based on the current one, before merging it to master, checkout to another branch from the current one.
→ After every significant change you make, commit your changes. Always use a meaningful commit message.
→ Push your changes to the branch you're working on in the origin
→ If you have tests, make sure to run them.
→ When you finish working on a feature, open a pull request to master. If you are working with someone else on the project, ask for a review and fix the code according to the comments before merging.
→ [OPT] If you have conflicts, pull the changes from the branch you want to merge to, and solve them. Then commit the changes.
→ Merge the PR, checkout to master, pull the changes, and so on (back to step 3 - checkout to a new branch for the next feature).
→ [TIP] If you switch a computer and want to fetch some new branches from the origin, use git pull. Then you may checkout to the branch you worked on before, and continue from the same place.
Some of the explanations are taken from here. You may find this guide useful.
git init- initialize an existing directory as a Git repositorygit clone <URL>- locally retrieve an entire repository from a remote locationgit branch- list all local branches. An asterisk represent the current branchgit checkout- switch to another branch and check it out into the working directorygit checkout -b <branch-name>- create a new branch at the current commitgit status- show modified files in working directory
