1. Tell Git your name so your commits will be properly labeled. Type everything after the $ here:
2. Tell Git the email address that will be associated with your Git commits. The email you specify should be the same one found in your email settings. To keep your email address hidden, see "Keeping your email address private".
3. Tell Git to use a specific browser; change "nano" to which ever is your choice.
GIT New Project
Starting a new project and having an online repo is somewhat of a "chicken and egg" problem. The easiest is to have it online first, for example create an empty project on gitlab.com. Then clone that locally and get at it.
Often though, especially with "fancy" IDEs, a project is created locally first. Then it gets put online. I suggest doing this even if you are working through a tutorial (which so many assume you've already done). In the least, it is basic best practices to use online repos as backups. The steps show you how to get a local project in a new empty project on gitlab.com. The idea can be used for many other situations too!
Since I've been using flutter a lot, I'll use that as an example.
Create new flutter project in Android Studio
Go to gitlab.com & create new repository with same name as project/folder. I suggest not initializing it with anything.
Go into new project folder:
Go to gitlab.com and double check everything is added.
For those new to programming, remember commits are for significant "save points". For tutorials, I often commit when they tell me to compile & run things. Then another commit when I actually get things to compile & run! :-)
Tell Git to ignore all files modified locally & reset to last fully committed version. This could be useful for getting a local branch to state where one can pull everything from a remote repository. If there are files that are needed to be re-added, they are identified when doing the pull that failed.
So you've forked another project and started hacking. Awesome! But now the original project has changes you want to get into your branch. What do you do now?!?!?!?
There are a lot of fancy things out there. Google around and you will see. I prefer to keep it simple when I can. For this set of steps, I'm assuming that upstream is "gospel" (you have no reason to assume any of it is bad) and that it hasn't changed any files that I've worked on. If there are conflicts, git will tell you. Resolving them is out of scope for this little tidbit.
This assumes that "master" is the branch you are working on. It also has not committed upstream's changes to master, nor pushed it to your online repo.