QUICK TIP - Git and Github – must know commands to make your first commit

0 321,363
enter image description here | A&H Business Technology
Related posts

You want to learn github and how to contribute to the open source? You don’t know how to use github with all its powers?

The Git environment is a vast and sometimes gets very complicated when you have to work on bigger projects. These days almost every software company use github as their first version controlling system.

By understanding these must know commands you will become an even better web developer.

I assume that you have already cloned your repository and are ready to just make your changes and push. So let’s get started.

[git status]

Check if there are already some changes tracked in the repository by git? git status will list any files that are changed.
Gif where Git status is typed in and the output is shown once without changing any file and another time with changed file

[git add .]

This is the first command that you’ll run after making some changes to the project files.

The command analyzes all the repository files and adds all modified and new (untracked) files in the current directory and all subdirectories to the staging area (a.k.a. the index), thus preparing them to be included in the next git commit which I’ll explain in the next lines. Any files matching the patterns in the .gitignore file will be ignored by git add .
gif showing how to run git add . in command line

[git commit -am “your commit message”]

git commit -am adds the changed files into a commit with a commit message as stated inside the inverted commas(in the hading). Using the option -am allows you to add and create a message for the commit in one command.

The -a flag is used in git to add all the files to your commit and then you’ll have to run another command where you write your commit message.

The m flag is used for connecting a commit message to your commit for example git commit -m "your message".

Be very careful when using this command because it will add all the changed files to your commit which you may not want in many cases. You can add individual files to the stging area by using git add. For example git add file1.js image.png index.php to add only "file1.js", "image.png" and "index.php" to the staging area and then you can create a commit with git commit -m "your commit message".

Hence git commit -am "your commit message" is the second command that you must know.
gif showing how to make your first commit with the commit message from the command line

[git push origin master]

You are ready to push your first commit to the remote repository. The push here is for pushing your changes which requires a branch to push to call it origin and then specify the branch name master (the default branch that always exists on any repository.

So git push origin master will take the local commit that you made in the above sections and upload it to the remote server on github for other people to collaborate.

What's next?
Now that you know how to make your first commit and push it to the remote repository here are some other commands that you should know to start working on a team project.

[git pull]

Suppose you are now another dev working on the same repository so you'll have to use this command to pull in the changes that you just pushed to the repository before making any commits. If you don't pull then GitHub will yell at you that you need to pull first.

[git checkout -b "new-branch"]

You'll need this command too often while collaborating on a project that has more than one devs working on it. It creates a new branch for you with the name of the branch stated in the inverted commas (another gotcha here is the hyphen separated name for the branch which is necessary).

You can see in gifs above that there is (master) written after the name of the folder where you are running the command. That (master) is the default branch that gets created in every repository. If you see (master) in your command line then the git checkout -b “new-branch” will create a new branch based from the master branch. In other words, the branch you check out to will be based on the branch name you see in the command line so be careful about that.

Once you have checked out to a branch you’ll be able to work in a detached environment having all the files from master. This way if you mess something you just go back to master branch and you’ll have the initial files back. Many professional devs like to work like that.

Final notes

Here is a gist of what we have learnt so far:

Git task Notes Git commands
Status List the files you’ve changed and those you still need to add or commit: git status
Add files Add one or more files to staging (index): git add <filename>
git add .
Commit Commit changes to head (but not yet to the remote repository): git commit -m "Commit message"
Commit any files you’ve added with git add, and also commit any files you’ve changed since then: git commit -a
Push Send changes to the master branch of your remote repository: git push origin master
Update from the remote repository Fetch and merge changes on the remote server to your working directory: git pull
Branches Create a new branch and switch to it: git checkout -b <branchname>

To become a better software developer you need to learn these workflows because they not only boost your productivity but also adds confidence to your way of working that if you break something it can be reverted.

TinyURL for this post: https://tinyurl.com/y5hoofuh

Sorry, The Comment Form Is Temporarily Closed At This Time

And finally some tips

  • Don’t EVER commit private keys / api keys/certificates.
  • Integrate linters and code checkers and beautifiers such as jsPrettier (but first ask your team first if they use any)
  • Use descriptive commit messages and branch names.
  • Create a branch for every new feature, and delete the branch once the feature is merged into main.
  • Tag your commit messages with the ticket number it corresponds with (if you are working in an agile environment)

You may also like

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More