Ralph Mason, Jul 21

Decoding CSS Positioning: A Master Class with Paul O'Brien

Paul answers anything and everything about CSS positioning — from floats and relative, absolute and fixed positioning to table display and even flexbox.
Angela Molina, Jul 21

Translating CSS for Paged Media with Rachel Andrew

Last week we spoke with Rachel Andrew, a CSS Working Group Invited Expert about CSS for paged media. Here's a recap of your questions for her.
Shaumik Daityari, Jul 20

Python on the Web: Why Frameworks Like Django Are Hot

Shaumik Daityari looks at what makes Python suited to web development, and why it's the go-to language for an increasing number of web developers.
Angela Molina, Jul 14

Head Slapping WordPress Security with Expert Chris Burgess

WordPress security is often an area in WordPress left neglected or done incorrectly. Read our recap with Chris Burgess in our WordPress security webinar.
James Hibbard, Jul 11

Should We Be Scared of an Intelligent Internet of Things?

What happens when AI meets the IoT? Will it spell disaster? Will the machines soon be taking over? Don your tin-foil hat and join James Hibbard to find out.
Ben Dickson, Jul 08

4 Major Technical Challenges Facing IoT Developers

Ben Dickson discusses four major challenges presented by IoT, from privacy and security to connectivity and compatibility/longevity.
Elio Qoshi, Jul 07

Ilya Gelfenbeyn, CEO of Api.ai, on AI and the IoT

Elio Qoshi interviews Ilya Gelfenbeyn, CEO of Api.ai, and discusses their conversational UX platform, artificial intelligence, and the Internet of Things.
Patrick Catanzariti, Jul 05

Setting up a Home VPN Server Using Your Raspberry Pi

Patrick Catanzariti covers how to set up a VPN for your network using a Raspberry Pi and an OpenVPN installer called PiVPN.
Design & UX
Alex Walker, Jul 05

SitePoint/Flippa Hack Day: Hacking our First IoT Project

We'd all played with computers for years but SitePoint's Hack Day gave us a chance to make electronics with our first IoT project.
Elio Qoshi, Jul 04

Why the Internet of Things Still Has a Long Way to Go

Elio Qoshi looks at why he is hesitant to adopt the IoT or recommend it to consumers — security, quality and transparency concerns.
Design & UX
Charles Costa, Jul 04

The 4 Unique Design Challenges of IoT

Designing for IoT – the Internet of Things – offers great opportunities, but also a new range of challenges. Charles Costa walks you though the big 4. 
Craig Buckler, Jul 01

Browser Trends July 2016: Is a Chrome Monoculture Harmless?

The chasm between Chrome and the other browsers is widening. Craig discusses this new monoculture may be less dangerous than the IE6 days but remains cause for concern.
Thomas Punt, Jun 29

Elixir's Ecto Querying DSL: Beyond the Basics

Thomas explores Ecto features, including query composition, joins and associations, SQL fragment injection, explicit casting, and dynamic field access.
Adam Bard, Jun 28

Heroku Alternative: Deploy Apps with Dokku on DigitalOcean

Adam Bard shows how to get small, low-traffic projects up and running with Dokku on DigitalOcean, creating a Heroku-like experience without the cost.
Thomas Punt, Jun 24

Understanding Elixir's Ecto Querying DSL: The Basics

Thomas looks at the basics of querying with Elixir's Ecto library, going through joins, associations, aggregation functions, and so on.
Angela Molina, Jun 20

Spreading the Word on WordPress Security

Did you know that WordPress powers a third of the web, and a popular target for attackers? This week we chat to Chris Burgess on WordPress Security.
Thomas Punt, Jun 15

An Introduction to Elixir's Ecto Library

Thomas introduces Ecto, Elixir's predominant library for working with databases, building a simple database-driven app using Ecto's four main components.
Bruno Skvorc, Jun 15

The PHP Application Environment

This is an excerpt from SitePoint's recent book on PHP Application Environments and get getting started the right way. Enjoy this preview!
Craig Buckler, Jun 14

Blisk: Your Next Web Development Browser?

Most of us use our default browser for development. Is it practical? Are there better options? Craig looks at Blisk — a new development-only browser.
James Hibbard, Jun 13

A Round up of Online Code Playgrounds

James Hibbard looks at some of the more popular online code playgrounds and examines which are good for hosting demos involving a server-side components.
Hugo Giraudel, Jun 10

The Importance of Code Reviews

Hugo discusses the importance of code reviews, and how to get them happening within your development team.
Lukas White, Jun 09

How to Modernize a Booking System with Acuity Scheduling

Lukas White shows you how to bring a driving instructor's booking system into the 21st century using the Acuity Scheduling API.
Shaumik Daityari, Jun 08

Jump Start Git: Branching in Git


The following is a short extract from our book, Jump Start Git, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.

In Chapter 1, I talked about my one-time fear of trying out new things in a project. What if I tried something ambitious and it broke everything that was working earlier? This problem is solved by the use of branches in Git.

What Are Branches?

Creating a new branch in a project essentially means creating a new copy of that project. You can experiment with this copy without affecting the original. So if the experiment fails, you can just abandon it and return to the original—the master branch.

But if the experiment is successful, Git makes it easy to incorporate the experimental elements into the master. And if, at a later stage, you change your mind, you can easily revert back to the state of the project before this merger.

So a branch in Git is an independent path of development. You can create new commits in a branch while not affecting other branches. This ease of working with branches is one of the best features of Git. (Although other version control options like CVS had this branching option, the experience of merging branches on CVS was a very tedious one. If you've had experience with branches in other version control systems, be assured that working with branches in Git is quite different.)

In Git, you find yourself in the master branch by default. The name “master” doesn't imply that it's superior in any way. It's just the convention to call it that.

Note: Branch Conventions

Although you're free to use a different branch as your base branch in Git, people usually expect to find the latest, up-to-date code on a particular project in the master branch.

You might argue that, with the ability to go back to any commit, there's no need for branches. However, imagine a situation where you need to show your work to your superior, while also working on a new, cool feature which is not a part of your completed work. As branching is used to separate different ideas, it makes the code in your repository easy to understand. Further, branching enables you to keep only the important commits in the master branch or the main branch.

Yet another use of branches is that they give you the ability to work on multiple things at the same time, without them interfering with each other. Let's say you submit feature 1 for review, but your supervisor needs some time before reviewing it. Meanwhile, you need to work on feature 2. In this scenario, branches come into play. If you work on your new idea on a separate branch, you can always switch back to your earlier branch to return the repository to its previous state, which does not contain any code related to your idea.

Let's now start working with branches in Git. To see the list of branches and the current branch you're working on, run the following command:

[code language="bash"]git branch [/code]

If you have cloned your repository or set a remote, you can see the remote branches too. Just postfix -a to the command above:

[code language="bash"]git branch -a [/code] [caption id="attachment_131959" align="alignnone" width="264"]Command showing the branches in the local copy as well as the origin branch Command showing the branches in the local copy as well as the origin branch[/caption]

As shown above, the branches that colored red signify that they are on a remote. In our case, we can see the various branches that are present in the origin remote.

Create a Branch

There are various ways of creating a branch in Git. To create a new branch and stay in your current branch, run the following:

[code language="bash"]git branch test_branch [/code]

Here, test_branch is the name of the created branch. However, on running git branch, it seems that the active branch is still the master branch. To change the active branch, we can run the checkout command (shown below):

[code language="bash"]git checkout test_branch [/code] [caption id="attachment_131988" align="alignnone" width="300"]Creating a new branch and making it active Creating a new branch and making it active[/caption]

You can also combine the two commands above and thereby create and checkout to a new branch in a single command by postfixing -b to the checkout command:

[code language="bash"]git checkout -b new_test_branch [/code] Create and checkout to a new branch in a single command

The branches we've just created are based on the latest commit of the current active branch—which in our case is master. If you want to create a branch (say old_commit_branch) based on a certain commit—such as cafb55d—you can run the following command:

[code language="bash"]git checkout -b old_commit_branch cafb55d [/code] [caption id="attachment_131995" align="alignnone" width="575"]Creating a branch based on an old commit Creating a branch based on an old commit[/caption]

To rename the current branch to renamed_branch, run the following command:

[code language="bash"]git branch -m renamed_branch [/code]

Delete a Branch

To delete a branch, run the following command:

[code language="bash"]git branch -D new_test_branch [/code] [caption id="attachment_131996" align="alignnone" width="300"]Deleting a branch in Git Deleting a branch in Git[/caption]

Note: Don't Delete Branches Unless You Have To

As there's not really any downside to keeping branches, as a precaution I'd suggest not deleting them unless the number of branches in the repository becomes too large to be manageable.

The -D option used above deletes a branch even if it hasn't been synchronized with a remote branch. This means that if you have commits in your current branch that have not been pushed yet, -D will still delete your branch without providing any warning. To ensure you don't lose data, you can postfix -d as an alternative to -D. -d only deletes a branch if it has been synchronized with a remote branch. Since our branches haven't been synced yet, let's see what happens if we postfix -d, shown below:

Deleting a branch in Git using the -d option

As you can see, Git gives you a warning and aborts the operation, as the data hasn't been merged with a branch yet.

Branches and HEAD

Now that we've had a chance to experiment with the basics of branching, let's spend a little time discussing how branches work in Git, and also introduce an important concept: HEAD.

As mentioned above, a branch is just a link between different commits, or a pathway through the commits. An important thing to note is that, while working with branches, the HEAD of a branch points to the latest commit in the branch. I'll refer to HEAD a lot in upcoming chapters. In Git, the HEAD points to the latest commit in a branch. In other words, it refers to the tip of a branch.

A branch is essentially a pointer to a commit, which has a parent commit, a grandparent commit, and so on. This chain of commits forms the pathway I mentioned above. How, then, do you link a branch and HEAD? Well, HEAD and the tip of the current branch point to the same commit. Let's look at a diagram to illustrate this idea:

[caption id="attachment_132000" align="alignnone" width="609"]Branches and HEAD Branches and HEAD[/caption]

As shown above, branch_A initially is the active branch and HEAD points to commit C. Commit A is the base commit and doesn't have any parent commit, so the commits in branch_A in reverse chronological order (which also forms the pathway I've talked about) are C → B → A. The commits in branch_B are E → D → B → A. The HEAD points to the latest commit of the active branch_A, which is commit C. When we add a commit, it's added to the active branch. After the commit, branch_A points to F, and the branch follows F → C → B → A, whereas branch_B remains the same. HEAD now points to commit F. Similarly, the changes when we add yet another commit are demonstrated in the figure.

Advanced Branching: Merging Branches

As mentioned earlier, one of Git's biggest advantages is that merging branches is especially easy. Let's now look at how it's done.

We'll create two new branches—new_feature and another_feature—and add a few dummy commits. Checking the history in each branch shows us that the branch another_feature is ahead by one commit, as shown below:

[caption id="attachment_132001" align="alignnone" width="546"]Checking the history in each branch Checking the history in each branch[/caption]

This situation can be visualized as shown below. Each circle represents a commit, and the branch name points to its HEAD (the tip of the branch).

[caption id="attachment_132005" align="alignnone" width="1024"]Visualizing our branches before the merge Visualizing our branches before the merge[/caption]

To merge new_feature with master, run the following (after first making sure the master branch is active):

[code language="bash"]git checkout master git merge new_feature [/code]

The result can be visualized as shown below:

[caption id="attachment_132007" align="alignnone" width="1024"]The status of the repository after merging new_feature into master The status of the repository after merging new_feature into master[/caption]

To merge another_feature with new_feature, just run the following (making sure that the branch new_feature is active):

[code language="bash"]git checkout new_feature git merge another_feature [/code]

The result can be visualized as shown below:

[caption id="attachment_132009" align="alignnone" width="1024"]The status of the repository after merging another_feature into new_feature The status of the repository after merging another_feature into new_feature[/caption]

Important: Watch Out for Loops

The diagram above shows that this merge has created a loop in your project history across the two commits, where the workflows diverged and converged, respectively. While working individually or in small teams, such loops might not be an issue. However, in a larger team—where there might have been a lot of commits since the time you diverged from the main branch—such large loops make it difficult to navigate the history and understand the changes. We'll explore a way of merging branches without creating loops using the rebase command in Chapter 6.

[caption id="attachment_132011" align="alignnone" width="551"]The status of branch new_feature after the merge The status of branch new_feature after the merge[/caption]

This merge happened without any “conflicts”. The simple reason for that is that no new commits had been added to branch new_feature as compared to the branch another_feature. Conflicts in Git happen when the same file has been modified in non-common commits in both branches. Git raises a conflict to make sure you don’t lose any data.

We’ll discuss conflicts in detail in the next chapter. I mentioned earlier that branches can be visualized by just a simple pathway through commits. When we merge branches and there are no conflicts, such as above, only the branch pathway is changed and the HEAD of the branch is updated. This is called the fast forward type of merge.

The alternate way of merging branches is the no fast forward merge, by postfixing --no-ff to the merge command. In this way, a new commit is created on the base branch with the changes from the other branch. You are also asked to specify a commit message:

[code language="bash"]git merge --no-ff new_feature [/code]

In the example above, the former (merging new_feature with master) was a fast forward merge, whereas the latter was a no fast forward merge with a merge commit.

While the fast forward style of merges is default, it’s generally a good idea to go for the no fast forward method for merges into the master branch. In the long run, a new commit that identifies a new feature merge might be beneficial, as it logically separates the part of the code that is responsible for the new feature into a commit.


What Have You Learned?

In this chapter, we discussed what branches are and how to manage them in Git. We looked at creating, modifying, deleting and merging branches.

What’s Next?

I’ve already spoken about how Git is beneficial to developers working in teams. The next chapter will look at this in more detail, as well as specific Git actions and commands that are frequently used while working in a distributed team.

Camilo Reyes, Jun 08

3 Ways to Work More Effectively in a Web Development Team

Camilo Reyes shares some important tips on working effectively in a team, growing as a programmer, and stepping up as a leader.
We Teamed Up With SiteGround To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99).