Gain insights into Git version control, delving into commits, branches, and remote collaboration. Learn about resolving conflicts and handling erroneous changes to manage software projects efficiently.

MBE-  Beginning Git Version Control by Thomas Makzan.png

DockerGit.tar.gz

email

name

Grouping 

Git is one of the most widely used version control tools in the software industry. Whether working on frontend or backend, native or server-side applications, every software developer should be comfortable with Git version control.

In this course, you’ll learn how Git is used in software projects and the basics of version control. Moreover, you’ll learn commits, pushing code, branches, and Git Stash. Finally, you’ll learn to use Git for remote collaboration, including reconciling conflicts and correcting erroneous changes with fetch, pull, reversion, and cherry-picking. At each step, you’ll solve quizzes to test your knowledge.

By the end of this course, you’ll have a working knowledge of Git and its use in version control. You’ll be able to proficiently and efficiently manage your future software projects.

Getting Started with Git Version Control

Files that contain secret tokens, personal preferences, or editor settings


Files that are binary, such as executables, images, and videos


Files that contain personal preferences and application configurations


We should track all files in the Git version control system.


Which files do we usually want to ignore in the version control system?

Which files do we usually want to ignore in the version control system?

```shell
$ git log --oneline --graph
```


In the `git log` command, how can we show a readable branch path in the command line to get a big picture of the history?


In the <code>git log</code> command, how can we show a readable branch path in the command line to get a big picture of the history?

The long form shows a detailed `diff` between the changes, which makes it easier to see the changes that will be committed.

The short form doesn’t show if the files are changed, staged, or committed.

The short form doesn’t show if there are any files that are deleted but not committed.

The long form shows a summary on the current status, including instruction suggestions for further operations.


Why should we use the long form of `git status`?


Why should we use the long form of <code>git status</code>?

Separating `git add` and `git commit` allows us to commit all file changes into the control system.

The `git status` command is a fast and one line operation to quickly commit current changes.

Separating `git add` and `git commit` allows the developers to carefully review the changes that are to be committed.


The `git commit -am\
 command allows committing changes without messages.

Why don’t we always use `git commit -am`?

Why don’t we always use <code>git commit -am</code>?

What makes a good commit message?

How do we stage the untracked changes?

How do we commit the staged changes?

Quiz

Quiz

Test your knowledge of the basic Git commands. 

Getting Started

Basic Command

Behind the Scenes

Essential Techniques

Flow Control

Remote and Collaboration

Handle Conflicts

Undo Changes

Rebase and Cherry Pick

Conclusion

Quiz