personal

In the previous module, we shared information directly between two developers’ repositories: my-git-repo and marys-repo . This works for very small teams developing simple programs, but larger projects call for a more structured environment. This module introduces one such environment: the centralized workflow . We’ll use a third Git repository to act as a central communication hub between us and Mary. Instead of pulling changes into my-git-repo from marys-repo and vice versa, we’ll push to and fetch from a dedicated storage repository. After this module, our workflow will look like the following. The centralized workflow Typically, you would store the central repository on a server to allow internet-based collaboration. Unfortunately, server configuration can vary among hosting providers, making it hard to write universal step-by-step instructions. So, we’ll continue exploring remote repositories using our local filesystem, just like in the previous module. If you have ...

Simply put, a remote repository is one that is not your own. It can be another Git repository that’s on your company’s network, the internet, or even your local filesystem, but the point is that it’s a repository distinct from your my-git-repo project. We’ve already seen how branches can streamline a workflow within a single repository, but they also happen to be Git’s mechanism for sharing commits between repositories. Remote branches act just like the local branches that we’ve been using, only they represent a branch in someone else’s repository. Accessing a feature branch from a remote repository This means that we can adapt our merging and rebasing skills to make Git a fantastic collaboration tool. Over the next few modules, we’ll be exploring various multi-user workflows by pretending to be different developers working on our example website. For several parts of this module, we’re going to pretend to be Mary, the graphic designer for our website. Mary’s actions are...

The previous module on rebasing taught us how to move commits around and perform some basic edits while doing so, but now we’re going to really get our hands dirty. We’ll learn how to split up commits, revive lost snapshots, and completely rewrite a repository’s history to our exact specifications. Hopefully, this module will get you much more comfortable with the core Git components, as we’ll be inspecting and editing the internal makeup of our project. Download the repository for this module If you’ve been following along from the previous module, you already have everything you need. Otherwise, download the zipped Git repository from the above link, uncompress it, and you’re good to go. Create the Red Page First, let’s create a new branch and add a few more HTML pages. git checkout -b new-pages git branch Notice that we created a new branch and checked it out in a single step by passing the -b flag to the git checkout command. Next, create the file red.ht...

Let’s start this module by taking an in-depth look at our history. The six commits asterisked below are part of the same train of thought. We even developed them in their own feature branch. However, they show up interspersed with commits from other branches, along with a superfluous merge commit ( b9ae1bc ). In other words, our repository’s history is kind of messy: ec1b8cb Merge branch 'crazy' *42fa173 Add news item for rainbow 3db88e1 Add 1st news item *7147cc5 Link index.html to rainbow.html *6aa4b3b Add CSS stylesheet to rainbow.html b9ae1bc Merge branch 'master' into crazy ae4e756 Link HTML pages to stylesheet 98cd46d Add CSS stylesheet *33e25c9 Rename crazy.html to rainbow.html *677e0e0 Add a rainbow to crazy.html 506bb9b Revert "Add a crazzzy experiment" *514fbe7 Add a crazzzy experiment 1c310d2 Add navigation links 54650a3 Create blue and orange pages b650e4b Create index page Fortunately, Git includes a tool to help us clean up ou...