We’re introducing calendar-based versioning for our REST API, so we can keep evolving our API, whilst still giving integrators a smooth migration path and plenty of time to update their integrations.
Now that you can
delete files directly on GitHub
we’ve reached a very exciting milestone—the entire GitHub Flow™ is now possible
using nothing but a web browser.
A little while ago our very own @schacon wrote
an article outlining the
workflow we use here at GitHub to collaborate using Git. It’s a deceptively
simple workflow, but it works brilliantly for us across a huge range of
projects, and has adapted extremely well as our team has grown from
being only a handful of people to our current size of 183 GitHubbers.
Since we use this workflow every day ourselves, we wanted to bring as many
parts of the workflow to our web-based interface as possible. Here’s a quick
outline of how the GitHub Flow works using just a browser:
- Create a branch right from the repository.
and delete files,
rename them, or move them around.
- Send a pull request from your branch with your changes to kick off a discussion.
- Continue making changes on your branch as needed, updating the pull request automatically.
- Once the branch is ready to go, the pull request can be merged using the big green button.
- Branches can then be tidied up using the delete buttons in the pull request, or on the branches page.
Even before some of these steps were possible in the browser, this simple
workflow made it possible for us to
iterate extremely quickly,
deploy dozens of times each day,
and address critical issues with minimal delay.
Probably the most compelling aspect of GitHub Flow however is that
there is no complicated branching model to have to wrap your head around.
Now that this workflow is available entirely via the web interface though,
a whole new set of benefits start to emerge. Let’s dive into a few of them.
Perhaps the most interesting consequence of having these tools available in the
browser is that people don’t have to interact with Git or the command-line at
all—let alone understand them—in order to contribute to projects in meaningful ways.
This makes for a much easier learning curve for anyone new to Git and GitHub, whether
they’re non-technical team members, or experienced developers learning something new.
These web-based workflows have been especially helpful for our training team
too. For some classes they’ve been able to have people begin learning the
basic concepts of Git and GitHub using just the browser, saving students the
complexity of installing Git and learning their way around the terminal commands until
after they’ve got their heads around the fundamental ideas. When a browser is all
you need, hallway demos and super-short classes can also more effectively convey the
GitHub Flow to people in less time, and without the distractions of preparing
computers with all the necessary software.
Even if you are a command-line wizard, there are always times when you just need
to make a quick tweak to a project. Even if it’s just a single
doing this in the terminal requires a crazy number of steps. So now, instead of:
- Switching contexts from your browser into your terminal.
- Pulling down the code to work on.
- Making the change.
- Staging the change.
- Committing the change.
- _Pushing_ the change.
…you can simply make the change right there without leaving your browser, saving you
time and maintaining your zen-like frame of mind. What’s more, if you have any kind
of continuous integration server set up to integrate with our Status API,
you’ll even see that your typo fix built successfully and is ready to go!
When editing Markdown
files in repositories, being able to quickly preview how your
change will look before you commit is very powerful. Combining that with things like
the ability to easily create relative links between Markdown documents,
and the availability of fullscreen zen mode
for enhanced focus when composing content which isn’t code, the end result is a set
of tools which make creating and maintaining documentation a real pleasure indeed.
For projects that make use of GitHub Pages for their websites, tasks like
writing new blog posts, or adding pages to an existing site are incredibly simple now
that these workflows are possible in the browser. Whether you use Jekyll
or just regular static HTML for your GitHub Pages site, these new workflows mean that
you’re able to make changes using GitHub in your browser, have your site rebuilt and deployed
automatically, and see your changes reflected live on
<username>.github.io or your
before you know it.
To learn more about building websites using GitHub Pages, you should
check out these articles.
In using them ourselves, we’ve found that these web-based workflows have come in
handy on an increasingly regular basis, and we’re noticing real benefits from the reduced
barrier to contributing. We hope you find these workflows useful too, and we can’t wait
to see the interesting ways we know you’ll put them to good use.