Dev Stuff

GIT Basics

1.  Tell Git your name so your commits will be properly labeled. Type everything after the $ here:

git config --global user.name "YOUR NAME"

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".  

git config --global user.email "YOUR EMAIL ADDRESS"

3.  Tell Git to use a specific browser; change "nano" to which ever is your choice.  

git config --global core.editor "nano"

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.  

1. Create new flutter project in Android Studio

2. Go to gitlab.com & create new repository with same name as project/folder.  I suggest not initializing it with anything.

3. Go into new project folder:

   1. git init

   2. git remote add origin <your new gitlab repo address>

   3. git add --all

   4. git commit

   5. git push --set-upstream origin master

4. 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!  :-)  

GIT Troubleshooting

1. 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. 

   • git reset --hard

2. placeholder

GIT Upstream

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.

1. git remote add upstream <url to upstream repo>

2. git fetch upstream

3. git pull upstream master

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.