-
Notifications
You must be signed in to change notification settings - Fork 2
3. Tutorials
This is not meant to be a cheat sheet, but more of an introduction to the most useful utilities and commands. So, it is not comprehensive, but it will be enough to get you started.
Git is a version control system that tracks versions of files. You start with a git repository with a single branch called "master" (which you want to rename to "main"). You then "stage" your changes into a "commit", which is a snapshot of your codebase on the branch you're on. Only staged changes will be present on your commit. You can have multiple branches in parallel, and branches branch from other branches. Once branches complete their purpose, whatever that purpose may be, they are merged into other branches, a process that mixes the codebase of the merging branch and the parent branch, into one codebase. Here is a video explaining git more graphically. GitHub hosts git repos and provides various other quality-of-life improvements, such as built-in wiki, GitHub Actions, insights, etc. More importantly, GitHub allows Pull requests, which are the preferred way of merging one branch into another, as it encourages peer reviews and discussions before pushing possibly broken code into an important branch (such as the "main" branch).
You need not do this for the drone repo, but if you want to have personal repos, this is how
Make a directory that will hold all your files and folders, cd into it and run git init. This will initialize the directory as a git repo. You then run git branch -M main to change the master branch to be called main (Not necessary but preferred).
Make a new GitHub repo, copy the repo's link, and run, from the git repo, git remote add origin <new_repo's_link> && git push -u origin main.
You navigate to the repo on a web browser and copy its URL. Then, from your terminal, run git clone <repo's_url> where you want your repo to reside.
Changes, such as deleting, adding, or modifying a file, need to be staged. You can see all the changes since the last commit by running git status. You then need to run git add <file_in_git_status> to stage those changes. Once staged, you can commit changes by running git commit -m "<Commit_message>", where commit_message is a description of the commit's changes, please give a good but concise description to your commits. The first time you try to commit, you will get an error asking you to configure an email and username, that's because those are needed for your commit's author. I recommend using your GitHub email address and username. You can also see the commits history by running git log, and entering "q" to exit the logs. You will notice, if you have a commit history, that each commit has an identifying string of alphanumeric characters, an author, a date, and a small description (the commit's commit_message). You use the identifying string to check out past commits, refer to Checkout commits and branches below.
Listing all current branches can be done with git branch for local branches and git branch -a for all branches. The current branch you're on is shown with the star ("*"). You can make a new branch that branches from your branch by running git branch <new_name>
You run git checkout <Branch_name_OR_commit_identifier> to either checkout a branch through its name or a specific commit through its identifier.
Once you have made at least a commit, you can push your commits to the GitHub repo. Simply running git push would have been enough at some point in the past but GitHub has transitioned away from password-based authentication for shell users, you need to create a classic personal access token which you will use as your "password" when you are prompted for your credentials. You can also retrieve the latest commits from a GitHub repo by running git pull. Pulling may be mandatory before pushing your commits if commits have been made in the same branch in the remote repo and those commits are not present in the local repo.
Sometimes, git throws errors. Please read the error messages carefully and try to understand them. I also recommend looking them up. If that doesn't work, ask one of the software leads.