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.
Check if there are already some changes tracked in the repository by git?
git status will list any files that are changed.
[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 .
[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.
-aflag 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.
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".
git commit -am "your commit message" is the second command that you must know.
[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.
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.
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.
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.
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:||
|Add files||Add one or more files to staging (index):||
|Commit||Commit changes to head (but not yet to the remote repository):||
|Commit any files you've added with
|Push||Send changes to the master branch of your remote repository:||
|Update from the remote repository||Fetch and merge changes on the remote server to your working directory:||
|Branches||Create a new branch and switch to it:||
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.
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)
Top comments (6)
Helpful article for beginners, but. And it is a big but:
Anyone who uses
-amto commit all the things is, of course, in a state of sin.
No, seriously. There is no amount of "I am in a hurry" or "lets take shortcuts" or "I know what I'm doing" justifies omitting the review your changes and adding them one by one instead if necessary. The amount of bugs I catch in the work of otherwise talented young engineers just because they used
-amas a "fire and forget" method to commit things is staggering. And it just leads to bad practices in general.
Honestly, I wish more people would use
git add --patchinstead, and split up their commits to smaller ones, instead of just listing all the changes in a three line commit message, and forgetting half of it (because they won't notice what
-amjust did for them).
git add --patchis excellent.
I usually just review the staged diffs in VSCode, but I'm sure it'll come in handy.
Really helpful feedback, thanks, I really appreciate that.
I will carefully revise about the points you mentioned and update the article real soon!
These were my only issues as well!
Final tips were the best ;)