Today, we’re delving into a fundamental yet potent aspect of Git, and other similar version control systems: distribution! As you might already know, your commits reside locally, and repositories are essentially clones of each other. This implies that the core task in distributing your projects involves synchronizing changes via git push and git pull.
For newcomers to Git, this might seem like extra overhead that complicates control. However, consider this: if your central server experiences downtime, you’re usually stuck and unable to work or collaborate with others. Since the actual work of creating revisions is performed on your local machine, you can continue coding even if the network is down, without needing permission or worrying about network issues. Not to mention, it’s often much faster for routine operations. Explore more advantages (and disadvantages) of Distributed Version Control Systems (DVCS) on Wikipedia.
Oliver Steele has crafted a helpful illustration depicting how pushing and pulling work:
[Diagram: A depiction of pushing and pulling changes]
The initial part of the diagram is straightforward: committing your changes to the staging area. Once done, your version control is essentially set, but the next step is synchronizing it with the remote repository. This could be hosted on platforms like GitHub, your company’s main Git server, a production machine, or even a colleague’s repository. Once changes are delivered, others can pull them down and work with them. Git offers several options for most actions, but let’s focus on pulling for now.
Let’s walk through a real-world example. I’ve just added a Twitter link at the bottom of this blog. I want to push these changes to the project’s GitHub repository to update the server. The command syntax usually follows git push <remote> <branch>. A remote represents the address of a cloned repository, containing the same data and history, awaiting updates. Typically, most projects interact with an origin remote and the master branch by default.