This is an elementary guide to Git for beginners. Git is a version-control system for tracking changes in files associated with projects of different types. It is primarily used for source-code management in software development, but it can be used to keep track of changes in any set of files.
Without a version control system, you probably used to frequently save copies of your work-in-progress in zip files. But when you feel that your work is a mess and you need to get back to a previous version of some files, how to deal with mixed changes in files? It’s a real pain to do that. Git and other version control systems like SVN are a great solution.
Is the common container of files for a specific project. Inside a repository, you can find files and folders tracked in versions. Generally, it includes a main section with the official version of the project files, called master.
A branch is a parallel copy of the master repository. Sometimes a project needs different people working on different features of the project, but they cannot work directly in the master branch. To prevent a mix of unstable code with official stable code and to allow independent work for each feature, a separate branch could be created for every feature. The master branch is a special branch to keep the stable/approved version.
A working copy is a local copy of a repository or branch you are currently working on. You can easily switch between different branches from the same repository to work with different features. By default, the working copy is related to the master branch. You can get a local copy of a repository using the git
clone command and change between branches using the git
checkout command. Your local operations like
commit are finally returned to the remote repository when you
push your changes.
After you clone or get a copy of a repository, you can do a pull from the repository to make sure your copy is updated with the latest changes. It’s a good practice to make a pull before working in a local copy when you are working in a multi-user repository or when you are working on the same project on different devices to keep it synchronized and to avoid conflicts.
To commit a set of changes you need to stage your changes before. Staging is an intermediate storage area where you add (stage) files and changes ready for commit. When you commit your changes, all your staged files are part of your commit.
After a number of changes made over files in the repository branch, you need to commit them to make it permanent. Before this commit, every change is temporary and could be lost. A commit contains of a number of files changed, and some attributes related to the commit, including a commit message. This message must be a basic and quick summary of the changes made (Example: “Added validation for user password”).
You are finishing a local transaction when you stage and commit your changes. The commit does not affect the main repository until you make a push request to send your local commits to the main remote repository. Each push request will send every local commit to the mainstream repository master or branch.
When you push your changes or pull external changes, you can get some conflicts with the main repository. For example, another user modified the same files with other changes. You need to resolve it before you can push it again. This could be one of the most difficult parts of the version management, but it could be avoided if you are constantly pulling the remote updated changes in your local working.
To fork is to take an external repository from another user to create a copy (origin) available to modify for personal use. Also, forking a project is a common way to contribute externally to the main project (upstream). Each time you make a significant change that could help the main project, you can make a pull request to the forked upstream project to suggest. If approved, your changes will be available in the original upstream repository.