Skip to main content

Better Git Started: An Introduction to the Command Line, GitHub, and Git

Ian Curtis

Section 4.3 Sending Changes Back To GitHub: The Three-Step Process

Ok, great! We have some edits, but how do we let other people see them? Remember that we have been editing locally so nothing new has shown up on GitHub. The goal here is to share the work with the world, so we need a way to send the changes back to GitHub. Luckily, by cloning our repo, we set up a connection between our local repo and our GitHub repo.
This is a very important section. Each step must be completed in the proper order to avoid Git errors, headaches, and file loss.
With Git, there are three main steps to sending edits back to GitHub. That may seem like too many but in fact each step serves a different purpose and gives you a little bit of freedom with how you edit on a branch. The three steps are
  1. Staging your files for sending
  2. Commiting your changes
  3. Pushing your changes to GitHub
Step 2 may seem familiar. Yep, the commit that happens here is the same as a commit we did earlier!

Subsection 4.3.1 Wait, Which Files Did I Change Again?

This happenes often in large projects (and even in smaller projects). You have a branch, you’ve been working all day editing and creating files, making sure things work. But now it’s time to stage the files and you don’t remember what files you’ve edited! You aren’t even positive what the file names are. True, VS Code color codes your edited files but you might have folders and subfolders throught your repository and don’t really feel like searching through everything to record what files you changed and which of them you want to send to GitHub.
Luckily, Git has the command for you! With one line in the terminal, you can easily see a list of files you changed, deleted, and added. Let’s explore that with our small case.
The command you will need is simple: git status. The git is necessary to tell the computer that we will be using git and the status gives the the current status of all of the files in our repository. We might say that it shows all of the files that Git knows about (tracked) and the files that are new since the latest commit (untracked). Open the terminal, verify that you are in the correct directory and on the correct branch and try the command. Did it spit out what you expected?
Solution.
You might see a console output such as the one below.
> git status
On branch country
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
We get a lot more information than needed right now, but we will break this output down shortly. For now, notice that we get a statement of the branch we are on and a file name that represents a file we have modified. It is not recreated here, but the modified file name is red in the output (any new, untracked files will be green).

A Small Note On VS Code.

It is worth noting that if you are using VS Code, you do not need to navigate back and forth from a terminal window and the text editor. VS Code has a built-in interface to use your terminal. To access this, navigate to the “Terminal” heading in the navigation bar at the top of your screen and click on “New Terminal”. You may also use the keyboard shortcut Ctrl + Shift + ` (On a Mac, you would still use Ctrl not command.)

Subsection 4.3.2 Step 1: Staging Files

The first step in sending files back to GitHub is to stage your files. Basically, this step is like you saying “I have edited some files and these are the ones I would like to send to GitHub”. With our small example, this step is a little silly. We only edited one file, of course it’s the one we want to send back.
The magic of staging files, however, lets you choose which files you want to push back. Maybe I’m working on three files at once, but only two are ready to go back to GitHub. Maybe I’m writing a book and I want my editor to be able to see chapters 1-4 but not chapter 5 (which I’m currently working on). At any given time, you can decide which files you want to stage.
All this is great but how do I stage my files? How do I tell Git which files I want to send back?
(b)
The staging command is done with git add and the command is followed by all the files you want to add. There are three cases with this command:
You want to add specific files
Type in each file name and extension individually with a space between each file.
You want to add an entire folder of files
Type in the name of the folder followed by a / (e.g., images/).
You want to add all changed / created / deleted files
Type in a single period (.) instead of file names.
You can run as many or as little git add commands as you wish. For instance, you could do git add images/ my_file.txt or you could do git add images/ and then do git add my_file.txt separately. It’s up to you and how comfortable you feel with Git.
Try now to stage your README file using one of the three cases above.
Hint.
Case 1 or Case 3 will work in this instance.
Answer.
git add README.md OR git add .. Neither will produce any output.
(c)
Use git status to verify that your staging worked and that you didn’t add any extra files on accident (see Git Procedure C.1 if you did).
Answer.
> git status
On branch country
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md
The text color has changed to green which indicates the process worked.

Subsection 4.3.3 Step 2: Committing Files

“Commit” is a great name for this step in the process. At this point, you are indeed ready to commit to what you have changed and to send your selected files to GitHub.
Remember committing from Section 3.3? This commit is the same concept as it was before: telling Git/GitHub that your changes are done, you are sure they are done, and that you would like them to be a part of your main, active branch. This is easy on GitHub; all we had to do was hit the “Commit changes” button. With Git and the command line, there are no buttons or fancy things to interact with. We instead have to tell Git exactly what we want to do.
Let’s learn how to commit our files using Git. Note that you must have staged at least one file before moving on to this step. See Git Procedure 4.5 if you have not done this.
The basic command to commit files is (conveniently) git commit; git for initiating Git and commit to tell Git we are going to be committing files. However, the command also requires a commit message (which we also did in Section 3.3). This is done with the -m switch.
(a)
Take a minute to think about the edits you have just made. In a few words, how would you explain to future you and others what you changed? If you could summarize your changes in a sentence or less, how would you? Whatever you decide on will be your commit message.
Do keep in mind the guidelines expressed in A Note On Commit Messages. They apply here, too! (And any other time you are committing.)
(b)
Type git commit -m "<your-commit-message>" into the command line. For our working example, I might type git commit -m "add birth country".
> git commit -m "add birth country"
[country 137b0bc] add birth country
 1 file changed, 4 insertions(+)
Note that the message is surrounded by quotation marks. This is required so that Git doesn’t think that each word in your message is a separate command. They can be either single or double quotes as long as the two match.
Also take a look at the output. This tells you the name of your branch, a unique identifier for your commit (so yours will be different than mine), your commit message, how many files were changed, and how many lines were inserted or deleted. This can be useful to verify that the commit worked as you expected.
(c)
Just for good measure, try git status as an extra verification step (Git Procedure 4.4).
Answer.
> git status
On branch country
nothing to commit, working tree clean
This output is what is to be expected! Don’t fret that it says nothing to commit. This is completely true since we just finished committing everything that we had staged. This output means that everything worked correctly.
It is worth mentioning a few notes about commits since they can be forgotten or confused.
  1. A commit is similar to saving a Word document and closing Word completely. Sure, you can go back and reverse your changes or keep editing, but it would take some time to start Word back up and open the file. Same with commits. It is possible to reverse a commit, but it can be annoying to have to do so. Git gives you multiple stages in the finalizing process to help you catch any edits you forgot to make.
  2. If for whatever reason you find that you made a commit too early or did so accidentally, you can reset your current branch back to what it was before the commit, according to Git’s knowledge. Details can be found in Git Procedure C.2 in Appendix C.
  3. It is possible to have multiple commits in one push. See Subsection 4.3.4 for more details.

Subsection 4.3.4 Step 3: Pushing Files

Take a minute and go back to your GitHub repo for your aboutme files. Do the files there reflect your changes of an added country?
Nope, nothing should have changed. Git has, in its three-step process, built in saving graces to help us in case we make a mistake. If git commit sent our files right to GitHub, it would be much more difficult to reverse things or correct our mistakes.
Enter the third step in the process: the git push. This step is new; we haven’t seen it before. When we worked on GitHub, a commit did did send our changes to GitHub. But now that we are working locally, an extra step is needed to tell Git that we are truly finished editing and that we want our changes to show up on GitHub for the world to see.
In order to understand the syntax of the git push command, we need to talk about remotes. A remote is a connection between a local repo and a GitHub repo. Remotes are also dependent on the branch you are on. By default, when you clone a repo, Git creates a remote from your local main branch to the main branch of the repo on GitHub. It’s a connection; when you tell Git to push changes to GitHub, it knows where to send the changes because of the remote.
There are two types of remotes: origin and upstream. Upstream remotes are not typically necessary when you are working with yourself and on your own repo. We will come back to them in Subsection 5.4.2. To Git, “origin” is the repo that you have cloned. Throughout this section, we have been working with a repo titled aboutme that is located on GitHub. This GitHub version of the repo is “origin”. When we cloned, we made a copy of “origin” onto our computer and Git established a remote connection from the local computer to GitHub.
This is necessary to understand git push. The command has four parts:
  1. git, telling our computer to use Git
  2. push, telling Git that we are going to be pushing our committed files somewhere
  3. The remote you want to push to. Here, we will use origin.
  4. The branch you want to push to.
With this information, try Git Procedure 4.7 which will guide you through the process and some common errors should you forget one of the four parts.
This procedure will start with telling you to do the wrong things so you gain an understanding of what to expect if you type the push command incorrectly. The second part will show you the recommended way to push your files back to GitHub.
(a)
Let’s start with some errors that Git can throw at us.
(i)
What might happen if you forgot to specify the remote and branch? Let’s find out: type git push into the command line.
Solution.
> git push
fatal: The current branch country has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin country
Well that looks a little scary. Fatal! That just means that git wansn’t able to complete your request and stopped trying. The reason this failed is because the branch country is only on your computer, it hasn’t yet made it to GitHub (which is what we are trying to do). It is possible to create a remote connection between branches but I often don’t especially if I am only working on one branch at a time and if I plan on deleting a branch when I’m done with it. Should you want to create a remote, use the command Git provided.
(ii)
What if you just forgot to specify the branch? Try git push origin.
Solution.
> git push origin
fatal: The current branch country has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin country
Well, look at that, the same error. This should make sense. You are telling Git to push changes to the origin repo but country, the current branch, doesn’t have an origin since we created the branch locally.
(iii)
What if you remembered the branch, but not the remote? Try git push country
Solution.
> git push country
fatal: 'country' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Remember the four parts to git push? Well since we forgot Step 3, the remote name, Git assumes that the word “country” is the name of the repo we want to push to. Since there is no repo named “country” on your computer nor on GitHub, it doens’t know where to push and errors out.
(b)
Now let’s see how to properly push files back to GitHub. This part assumes you have already staged and committed all of the files you intend to push.
(i)
Take a minute to think about where you are pushing to. Origin? Upstream (if applicable)? What is your current branch name?
Answer.
Here, to follow with the example, we will use origin and the branch name country.
(ii)
Once you have decided, fill in the correct pieces of the git push formula.
Solution.
> git push origin country
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 330 bytes | 82.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: 
remote: Create a pull request for 'country' on GitHub by visiting:
remote:      <url-to-pull-request>
remote: 
To <url-to-origin-repo>
 * [new branch]      country -> country
We get a lot of output for a successful push. Most of it is just information that can be useful in certain cases and might be worth a glance to make sure things worked as expected.
At this point, you are ready to head back to GitHub and submit a pull request!
As mentioned earlier, it is possible to have multiple commits per push. An example of such a situation might be typo correction. Suppose I just finished a long novel and now I’m going back to correct all of my typos. So I create a branch called typos and start editing my files to remove my typos. Instead of fixing all of my typos, then staging all of my files, then doing one commit and one push, I could break things up. I could fix all the typos in Chapter 1, then add the files and commit (with a message such as “correct typos ch1”). Then fix typos in Chapter 2 and add and commit. When I’m done, I do one push and Git will push all of the commits to GitHub at one time. Breaking things up like this allows for better version control. More commits leads to more stamps on the version timeline. It also can give you peace of mind. If something horrible happens and I lost all of my book’s files, then I only lose the changes for the chapter I’m currenlty working on whereas if I had been editing all at once, I would have lost all of my changes for all of my chapters.
This section deserves a final summary.
When you are finished editing your files and are ready to send things back to GitHub, follow the Three-Step Process. Don’t forget to use git status throughout this process!
  1. Stage your files: git add <files> (Git Procedure 4.5)
  2. Commit your staged files: git commit -m "<commit-message>" (Git Procedure 4.6)
  3. Push your committed files: git push <remote> <branch> (Git Procedure 4.7)
When we push to GitHub, your files are pushed to the branch you specified. If the branch had not existed before the push, then Git will create the branch for GitHub, but will not merge it with the main branch. To do so, we need to go back to GitHub and create a pull request. The next section revists the process of creating a pull request and builds on the ideas gained in Subsection 3.3.4.
PrevTopNext