3. Start a terminal session and navigate to your local directory where you want your repo to be located. Consider this location for a moment — you might want to make a new directory to keep things tidy.

Then run:

git clone https://github.com/your_repo_name/your_repo

ls to see your new directory

cd into your directory

ls to see your new directories and files

Now it’s time to jump into your Push to Master Workflow.

Push to Master Workflow

1. When you clone a repo, you start on your local repo’s master branch by default. It’s good practice to create and work in a temporary branch.

Make a new branch and switch to it with git checkout -b my_feature_branch .

You can name your branch whatever you like. However, as with most names in programming, it’s a good idea to be both brief and descriptive. 😄

2. Write some code in your code editor and save it. I’m a fan of Atom. It’s free, open source, popular, and works well.

3. Check the status of your local file changes with git status . You should see a list of files in red that are new. These are untracked files. Git is aware of these files, so they have been indexed by Git. These files do not match files in your .gitignore, so they won’t be ignored by Git.

For example, here’s my untracked file.

4. To stage all changes, enter git add -A .

You might see that a file that you don’t want to add to your GitHub repo is listed. In that case, you can add the files you do want staged individually with git add my_filename .

Also, you should alter your .gitignore file to exclude file types and folders you don’t want to add to your repo. Save your .gitignore file and it should show up in red as a file with unstaged changes.

git status again to make sure that the files you want to commit are staged. File changes must be staged to be committed.

To use a baseball or softball analogy, I think of staged changes like a batter in the on deck circle. They are preparing for what’s up next: the real thing.

Batter in on deck circle.Credit: Tdorante10 [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)]

Files to be committed will show in green.

5. Commit changes with git commit -m "my commit message" . Use the present tense, e.g. “update links to references”.

6. Switch to the local master branch with git checkout master .

You can see all of your branches with git branch -v .

7. Merge your local feature branch into your local master branch with git merge my_feature_branch .

8. Push the updated master branch to GitHub with git push origin master .

9. Delete your old, local, non-master branch with git branch -d my_feature_branch .

REPEAT 🔁

That’s it if you’re working alone. Now your work is backed up, changes can be rolled back, and other people can use and see your code. 😄

Next we’ll look at a slightly more involved workflow with pull requests.

Scenario 2: Solo Pull Request Workflow

I’ll demonstrate this workflow by pushing a change to my GitHub repo used to make an example for an article about how to use argparse.

Everything is the same as Scenario 1’s setup and workflow until you get to Step 6. Don’t switch to your local master branch, instead stay on your local feature branch. Here’s the new Step 6:

6. Push your feature branch to your remote repository with git push origin my_feature_branch .

7. Navigate to your GitHub repo in your browser and you should see an alert that you can Compare & pull request.