Outline#
This page includes material from “Monash SCI1022 Git Introduction” by Alberto F. Martin and Santiago Badia, licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Now we have learned the commonly used commands to manage our repository with Git. If you are working alone on your project, you can keep your work only on your local machine because you don’t need to collaborate with others. That said, it’s recommended to create a remote repository which your local project is linked to and stick to the commit+push cycle. In short, you do some local work and commit that work, and then push that your work to origin, i.e., your remote repository. This page will discuss the best practices related to this topic.
The ‘Commit+Push’ Cycle#
Assume we are now working on a local branch. We have pushed contribution.md, but README.md remains empty. Usually, the README file illustrates some general information of your project, such as what it does, how to set things up and how it runs. To illustrate the commit+push cycle, let us perform a simple iteration.
First, we need to go into our project using cd:
cd [path_to_your_project]
If you follow the instructions strictly, there should be two files sitting inside. Let us use ls command to check it:
$ ls
contribution.md README.md
Great! Let us modify the README file now. Unlike other operating systems such as MacOS and Windows, Linux doesn’t have a graphical user interface (GUI) when it first comes out. Many Linux releases have included a GUI nowadays, so you can take advantage of a text editor with GUI and write something in it, especially if you are not familiar with command-line text editor. For example, you may use VS Code to do it:
code README.md
This command will use VS Code to open the README file for you. On the other hand, you can also use nano or vim to do the same thing. A brief handbook is available in page 3.
This new writing in README.md should also be reflected in Git status because Git keeps track of all changes. Remember how to check Git status?
$ git status
On branch main
Your branch is up to date with 'origin/main'.
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")
As we see, the new README.md is modified now. It needs to be “staged for commit”. Let us quickly recall the basic commands we learned in previous chapters. First, we add this file to the staging area:
git add README.md
We can confirm it has been added:
$ git status
On branch main
Your branch is up to date with 'origin/main'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
We then need to commit it to our local repository. Remember to think out a meaningful commit message:
$ git commit -m "updated README.md"
[main ad4fe0b] updated README.md
1 file changed, 5 insertions(+), 1 deletion(-)
Awesome! Without errors, the new README file in main branch is now committed and ready to push to GitLab repository. Let’s do it:
$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 343 bytes | 343.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To gitlab.cecs.anu.edu.au:uxxxxxxx/yyy.git
d72bf72..ad4fe0b main -> main
git push origin main means we explicitly tell Git to push the local main branch to the origin remote repository. However, origin is the default repository we interact with if no remote repository is specified. Thus, we can actually make it shorter, such as git push origin and git push.
If you see something similar to the above log, you have successfully pushed it to GitLab. You can check it out after logging in to your GitLab account. This is a full iteration of commit+push cycle. In the future, you just need to redo iterations whenever you make changes. Well done!
Note: Once you understand a full iteration, you don’t need to follow it strictly. For example, you can commit multiple times before pushing. However, we believe it’s best practice to frequently push up your changes to the remote repository to make sure everything has a backup. You can even cut the last pushing step and do git add and git commit to only keep a local backup.
Moving On#
That’s it! The commit-push cycle is a simple yet powerful tool to effortlessly manage your repository. By following the basic commands in the correct order, we can easily preserve previous commits for future use.
Next, let’s delve deeper into intermediate skills to elevate our mastery to the next level. Take your time and progress when you feel prepared.