Originally posted on The Frog Pond of Technology: A peer of mine recently asked about how I manage local code (projects, solutions, Git repos, etc.) that may or may not be synced to a cloud repository (GitHub, Azure DevOps, etc.) Since I previously blogged about How I Blog – Updated 2018 and I’m a fan…How I Develop Locally With GitHub and Azure DevOps Repos — El Bruno
This week GitHub announced the beta for their new GitHub CLI tool, which provides an easier and more seamless way for you to interact with GitHub from your terminal.
The GitHub CLI can be installed on Windows, macOS and Linux. Get started by downloading the installer from the GitHub CLI repository.
New GitHub CLI announced and available as betaTweet
What can GitHub CLI do?
Once you have it downloaded, open up your terminal and use the
The GitHub CLI beta currently allows you to do the following commands:
- Pull requests: Using the
prcommand to checkout, create, list, status and view
- Issues: Using the
issuecommand to create, list, status and view
- Help: Using
helpcommand to see how to use the tool
When you first use it you will need to authenticate the GitHub CLI. As you can see here I will be prompted to open GitHub in my browser:
After authenticating the GitHub CLI you will be able to continue with your last command:
I needed to change directories to where my repository was and then I was able to list out my pull requests using the following command:
gh pr list
For more details about what can be done, check out the GitHub CLI manual for lots of examples on using each of the commands.
This is an early look at what can be done with the GitHub CLI, and because it’s still in early development the team would love for you to give the tool a try and then provide them feedback.
Download from https://cli.github.com/
Documentation at https://cli.github.com/manual/
I came across a great software development post on Hackernoon called We Can’t Do That In One Sprint. This is basically where Product comes to the development team with an idea of a new feature or product and they want to know how long it will take to develop and get to production as quickly as possible.
Too often have I experienced what is outlined in this article. I agree that it’s best to do small chunks of work and get it out to production and then iterate on the feature. What I find is that this fails when Product doesn’t give Development enough time to iterate and cuts the timeline short and moves on. Maybe this is what the business wants/needs but sometimes it leads to features being half baked, released to production, rarely iterated on and then future features are built on this feature.
As the author says, “There is NO silver bullet. Get SOMETHING out there in one sprint.”
Came across a great article today about the quiet crisis that is unfolding in software development. Being a software developer myself I almost 99% agree with this article and see it day in and day out. Hopefully things in our industry change.
Anyway enjoy the read!