If you’re reading this, you’re probably already familiar with Git and code hosting platforms like GitHub. If not, have a look at this great introduction to Version Control! I’m well aware that learning Git isn’t as appealing as learning JavaScript...
In this tutorial, we will setup git-secret to store secrets directly in the repository. Everything will be handled through Docker and added as make targets for a convenient workflow.
The POP and PUSH (P&PT) testing framework's goal is to provide a platform for combining Six Sigma testing techniques with IBM App Connect microservices. In the same way that a recording reel of film records a snapshot of test case data, the P&PT will record a snapshot of test case data. It is digital proof captured throughout the lifecycle of an App Connect Enterprise application, from development to production (application lifecycle), using Git and Jenkins' workflow.
Introduction
In reaction to the business scenario, the project's test case count increases. As the test case repository grows like the General Sherman Tree grows: the goal is to reduce the amount of time spent on manual testing (operations).
Any developer working in a modern engineering organization is likely working in git. Git, written by Linus Torvalds in 2005, has been since its creation, basically the ubiquitous tool for source control management. Git gained widespread adoption across engineering organizations as the successor to existing source control management such as Apache Subversion (SVN) and Concurrent Versions System (CVS), and this was mostly a byproduct of the timing.
Git predates cloud and improved network connectivity, and therefore the best solution to managing source control at scale was to decentralize and leverage local dev environments to power engineering organizations. Fast forward 17 years, this is no longer the case. Cloud is de facto, networking and internet connectivity is blazing fast, and this changes everything.
Data junkies rejoice, this is the episode for you.
On this week’s episode of Dev Interrupted, Einat Orr, co-founder and CEO of Treeverse, sits down with us to talk about the state of data… where it’s been, where it’s going and why having bad data might be worse than having no data at all.
The 2021 DORA report is out, and it continues its focus on the characteristics of top-performing DevOps teams. It's becoming an essential read for anyone interested in how companies are using DevOps. The findings show that GitOps principles are integral to top-performing teams. Here are the highlights from the report.
SRE and DevOps Are Complementary
SRE (site reliability engineering) started to gain traction around the same time as DevOps, and it has its origins in companies like Google and Facebook.
But no matter which side you’re on, chances are you contribute to repositories parts of different organizations: personal projects, professionals, or various open-source ones. In this case, it is for sure not possible to use a mono-repository approach.
I’m always on the wrong branch. I’m either on master or main working on something that should be on a fix or feature branch. Or I’m on the last branch I was working on and should have cut a new branch. Oh well. It’s never that big of a deal. Basically means switching unstaged changes to a new branch. This is what I normally do:
Switching unstaged changes to a new branch with the Git CLI it looks like this
Here’s how I generally switch unstaged changes to a new branch in Git:
git status
git stash --include-untracked
git checkout master
git pull
git branch content/sharis
git checkout content/sharis
git stash pop
Yeah I commit jpgs right to git.
Switching unstaged changes to a new branch in Git Tower it looks like this
I think you could theoretically do each of those steps to switch unstaged changed to a new branch, one-by-one, in Git Tower, too, but the shortcut is that you can make the branch and double-click over to it.
Sorry, I’m just doing Git Tower but there are lots of other Git GUIs that probably have clever ways of doing this as well.
But there is a new fancy way!
This way of switching unstaged changes to a new branch is new to me anyway, and it was new to Wes when he tweeted this:
TIL about `git switch`, which allows you to move your unstaged changes to a new branch.
Seems fairly new. I used to `git stash`, new branch, and then `git stash apply` pic.twitter.com/6Rd0fCJOcV
Since the big bang in the data technology landscape happened a decade and a half ago, giving rise to technologies like Hadoop, which cater to the four ‘V’s. — volume, variety, velocity, and veracity there has been an uptick in the use of databases with specialized capabilities to cater to different types of data and usage patterns. You can now see companies using graph databases, time-series databases, document databases, and others for different customer and internal workloads.
Apache Cassandra™ is a wide-column, NoSQL database that is ideal when used for append-only, write-intensive workloads that capture data from IoT sensors, GPS devices, transaction logs, any time-series applications, and more. A lot of these applications need to be coupled with visualization engines for creating reports and dashboards. As most of the visualization libraries are written in JavaScript, using Node.js to interact with the database and the visualization engine is a good idea.
Disclaimer: Ok, Git "accounts" don't exist: we only have Git configurations. The title is an unorthodox shortcut to talk about accounts hosted by GitHub, GitLab, Bitbucket, and such. Not using these? Don't worry, you can still make great use of this cheat sheet to level up your .gitconfig game (look at step number 7).
Introduction
Let’s imagine a scenario: You’ve just joined a new company. It’s your first day and you need to set up your new machine. The first thing you do is to rush to get your own GitHub SSH key and install it so you can still work on your hobby project.
Cloning is a popular theme in science fiction movies and literature. Just to mention Star Wars and Attack of the Clones. But it’s not science fiction at all – in the real world probably everyone has heard of Dolly the sheep, the first cloned mammal. Since then, mankind has managed to clone, among others horse, pig, or dog. Wait, we are interested in the IT world, right? The world of over 87.2% programmers using the Git version control system, 60M GitHub users, 10M Bitbucket teams, and over 30M GitLab enthusiasts – so let’s focus on a very in-depth look at the git clone command topic. Do we have your attention?
What Is a Git Clone?
To work with Git, we need to have a copy of the repo on our device. In an event of failure and the lack of backups, we can restore the entire repository on the basis of such a copy. So what is a clone? This is a complete copy of the repository with an entire history of changes. But a clone is also the name of a specific function in Git that allows us to do this.
Interactive Rebase is the Swiss Army knife of Git commands: lots of use cases and lots of possibilities! It’s really a great addition to any developer’s tool chain, because it lets you revise your local commit history—before you share your work with the rest of the team.
Let’s see what you can do with an interactive rebase and then look at some practical examples.
Part 7: Cherry-Picking Commits in Git (Coming soon!)
Part 8: Using the Reflog to Restore Lost Commits
Rewriting your commit history
In short, interactive rebase allows you to manipulate your commit history. It’s meant for optimizing and cleaning up. You can…
change commit messages
combine multiple commits
split and edit existing commits
reorder commits
delete commits
Keep in mind that an interactive rebase rewrites your commit history: all of the involved commits get a new hash ID. Also, a quick reminder: commit IDs are there to identify commits—they are SHA-1 checksums. So, by changing that hash, you technically create completely new commits. This means that you shouldn’t use an interactive rebase on stuff that you’ve already pushed to a shared remote repository. Your colleagues might have based their work on these commits—and when you use interactive rebase to rewrite commit history, you are changing these base commits.
All of this means that an interactive rebase is meant to help you clean up and optimize your own local commit history before you merge (and possibly push) it back into a shared team branch.
Interactive rebase workflow
Before we take interactive rebase for a test drive, let’s look at the general workflow. This is always the same, no matter what exactly we’re doing—deleting a commit, changing a commit message, combining commits… the steps are identical.
The first step is to determine the range of commits you want to manipulate. How far back in time do you want to go? Once you have the answer, you can start your interactive rebase session. Here, you have the chance to edit your commit history. For example, you can manipulate the selected commits by reordering, deleting, combining them, and so on.
In your first step, you are always going to look at the current state of the commit history. You can use the git log command to examine a project’s history and show the commit log.
Here’s the little example repository we’re going to use throughout this article:
Note that I’m using the Tower Git desktop GUI in some of my screenshots for easier visualization.
After you’ve examined the list, it’s time to start the work. Let’s do this step-by-step. In the examples of this article, we will do the following things:
First, we change an old commit’s message.
Secondly, we combine two old commits.
After that, we split one commit.
Finally, we delete a commit.
Change a commit message
In many cases, you’ll want to change the most recent commit. Keep in mind that there’s a shortcut for this scenario which doesn’t involve interactive rebase:
$ git commit --amend
This command can modify both the content and the message of the most recent commit, and it opens your default text editor. Here you can make your changes, save them, and quit the editor. This will not only update the commit message, but will effectively change the commit itself and write a new one.
Again, please be careful and don’t amend your last commit if you’ve already pushed it to the remote repository!
For any other commit (anything older than the most recent one), you have to perform an interactive rebase. To run git rebase interactively, add the -i option.
The first step is to determine the base commit: the parent commit of the one you want to change. You can achieve this by using the commit’s hash ID or by doing a little bit of counting. To change the last three commit messages (or at least one of them), you can define the parent commit like this:
$ git rebase -i HEAD~3
An editor window opens and you can see all three commits you selected (and by “selected” I mean a range of commits: from HEAD all the way down to HEAD~3). Please notice the reverse order: unlike git log, this editor shows the oldest commit (HEAD~3) at the top and the newest at the bottom.
In this window you don’t actually change the commit message. You only tell Git what kind of manipulation you want to perform. Git offers a series of keywords for this—in our case, we change the word pick to reword which allows us to change the commit messages. After saving and closing the editor, Git will show the actual commit message and you can change it. Save and exit again, that’s it!
Combining two commits
In this next example, we’ll combine the two commits—“7b2317cf Change the page structure” and “6bcf266 Optimize markup”—so that they become one single commit. Again, as a first step you need to determine the base commit. And again, we have to go back to at least the parent commit:
$ git rebase -i HEAD~3
The editor window opens again, but instead of reword, we’ll enter squash. To be exact, we replace pick with squash in line 2 to combine it with line 1. This is an important bit to keep in mind: the squash keyword combines the line you mark up with the line above it!
After saving the changes and closing the window, a new editor window pops up. Why’s that? By combining two commits we are creating… well… a new commit! And this new commit wants a commit message. Enter the message, save and close the window… and you’ve successfully combined the two commits. Powerful stuff!
Finally a little “pro tip” for those of you working with the “Tower” Git desktop GUI: to perform a squash, you can simply drag and drop commits onto each other, right in the commits view. And if you want to change a commit message, simply right click the commit in question and select “Edit commit message” from the contextual menu.
Deleting a commit
We’re bringing in the big guns for our final example: we are going to delete a revision from our commit history! To do this, we’re using the drop keyword to mark up the commit we want to get rid of:
drop 0023cdd Add simple robots.txt
pick 2b504be Change headlines for about and imprint
pick 6bcf266 Optimizes markup structure in index page
This is probably a good moment to answer a question you might have had for some time now: what can you do if you’re in the middle of a rebase operation and think, “Oh, no, this wasn’t such a good idea after all”? No problem—you can always abort! Just enter the following command to turn back to the state your repository was in before you initiated the rebase:
$ git rebase --abort
Changing the past
These were just a few examples of what an interactive rebase can do. There are plenty of other possibilities to control and revise your local commit history.
If you want to dive deeper into advanced Git tools, feel free to check out my (free!) “Advanced Git Kit”: it’s a collection of short videos about topics like branching strategies, Interactive Rebase, Reflog, Submodules and much more.
Happy rebasing and hacking—and see you soon for the next part in our series on “Advanced Git”!
Do you know when you install Git Bash on windows what exactly you are installing? Most of the time, developers think they are only installing Git. But that's not true.
Let me repeat it: actually, you are installing Git Bash.
Becoming a Git power user is on the bucket list of every developer. Here are five Git tips that will help you level up your workflow and bring you one step closer to Git mastery.
Tip #1: Modify the Previous Commit Without Changing the Commit Message
You’ve just committed your changes on your local copy with a detailed and thought-through message, but the moment you hit RETURN, you realize you forgot to add that one change that really belongs there. If only there was a way to update the previous commit instead of creating a new one…
Do you think GitHub is your source control? Can you install Git and GitHub on your machine?
If you are looking for answers to these questions, you are in the right place. In this article, you will learn the core concepts about Git and GitHub, how they are different, and their similarities.
One of the principles from the 12 Factor App, states that we have to separate our application configuration from the code. The configuration varies based on the environment and it's better to organize them based on the environment your application is running.
So in this article, we will be looking at how we can externalize configurations with Spring Cloud Config.
In this third installment of our “Advanced Git” series, we’ll look at pull requests — a great feature which helps both small and larger teams of developers. Pull requests not only improve the review and the feedback process, but they also help tracking and discussing code changes. Last, but not least, pull requests are the ideal way to contribute to other repositories you don’t have write access to.
Part 3: Better Collaboration With Pull Requests You are here!
Part 4: Merge Conflicts Coming soon!
Part 5: Rebase vs. Merge
Part 6: Interactive Rebase
Part 7: Cherry-Picking Commits in Git
Part 8: Using the Reflog to Restore Lost Commits
What are pull requests?
First of all, it’s important to understand that pull requests are not a core Git feature. Instead, they are provided by the Git hosting platform you’re using: GitHub, GitLab, Bitbucket, AzureDevops and others all have such a functionality built into their platforms.
Why should I create a pull request?
Before we get into the details of how to create the perfect pull request, let’s talk about why you would want to use this feature at all.
Imagine you’ve just finished a new feature for your software. Maybe you’ve been working in a feature branch, so your next step would be merging it into the mainline branch (master or main). This is totally fine in some cases, for example, if you’re the only developer on the project or if you’re experienced enough and know for certain your team members will be happy about it.
By the way: If you want to know more about branches and typical branching workflows, have a look at our second article in our “Advanced Git” series: “Branching Strategies in Git.”
However, what if your changes are a bit more complex and you’d like someone else to look at your work? This is what pull requests were made for. With pull requests you can invite other people to review your work and give you feedback.
Once a pull request is open, you can discuss your code with other developers. Most Git hosting platforms allow other users to add comments and suggest changes during that process. After your reviewers have approved your work, it might be merged into another branch.
Having a reviewing workflow is not the only reason for pull requests, though. They come in handy if you want to contribute to other repositories you don’t have write access to. Think of all the open source projects out there: if you have an idea for a new feature, or if you want to submit a patch, pull requests are a great way to present your ideas without having to join the project and become a main contributor.
This brings us to a topic that’s tightly connected to pull requests: forks.
Working with forks
A fork is your personal copy of an existing Git repository. Going back to our Open Source example: your first step is to create a fork of the original repository. After that, you can change code in your own, personal copy.
After you’re done, you open a pull request to ask the owners of the original repository to include your changes. The owner or one of the other main contributors can review your code and then decide to include it (or not).
Important Note: Pull requests are always based on branches and not on individual commits! When you create a pull request, you base it on a certain branch and request that it gets included.
Making a reviewer’s life easier: How to create a great pull request
As mentioned earlier, pull requests are not a core Git feature. Instead, every Git platform has its own design and its own idea about how a pull request should work. They look different on GitLab, GitHub, Bitbucket, etc. Every platform has a slightly different workflow for tracking, discussing, and reviewing changes.
Desktop GUIs like the Tower Git client, for example, can make this easier: they provide a consistent user interface, no matter what code hosting service you’re using.
Having said that, the general workflow is always the same and includes the following steps:
If you don’t have write access to the repository in question, the first step is to create a fork, i.e. your personal version of the repository.
Create a new local branch in your forked repository. (Reminder: pull requests are based on branches, not on commits!)
Make some changes in your local branch and commit them.
Push the changes to your own remote repository.
Create a pull request with your changes and start the discussion with others.
Let’s look at the pull request itself and how to create one which makes another developer’s life easier. First of all, it should be short so it can be reviewed quickly. It’s harder to understand code when looking at 3,000 lines instead of 30 lines.
Also, make sure to add a good and self-explanatory title and a meaningful description. Try to describe what you changed, why you opened the pull request, and how your changes affect the project. Most platforms allow you to add a screenshot which can help to demonstrate the changes.
Approve, merge, or decline?
Once your changes have been approved, you (or someone with write access) can merge the forked branch into the main branch. But what if the reviewer doesn’t want to merge the pull request in its current state? Well, you can always add new commits, and after pushing that branch, the existing pull request is updated.
Alternatively, the owner or someone else with write access can decline the pull request when they don’t want to merge the changes.
Safety net for developers
As you can see, pull requests are a great way to communicate and collaborate with your fellow developers. By asking others to review your work, you make sure that only high-quality code enters your codebase.
If you want to dive deeper into advanced Git tools, feel free to check out my (free!) “Advanced Git Kit”: it’s a collection of short videos about topics like branching strategies, Interactive Rebase, Reflog, Submodules and much more.
Almost all version control systems (VCS) have some kind of support for branching. In a nutshell, branching means that you leave the main development line by creating a new, separate container for your work and continue to work there. This way you can experiment and try out new things without messing up the production code base. Git users know that Git’s branching model is special and incredibly powerful; it’s one of the coolest features of this VCS. It’s fast and lightweight, and switching back and forth between the branches is just as fast as creating or deleting them. You could say that Git encourages workflows that use a lot of branching and merging.
Git totally leaves it up to you how many branches you create and how often you merge them. Now, if you’re coding on your own, you can choose when to create a new branch and how many branches you want to keep. This changes when you’re working in a team, though. Git provides the tool, but you and your team are responsible for using it in the optimal way!
In this article, I’m going to talk about branching strategies and different types of Git branches. I’m also going to introduce you to two common branching workflows: Git Flow and GitHub Flow.
Part 3: Better Collaboration With Pull Requests Coming soon!
Part 4: Merge Conflicts
Part 5: Rebase vs. Merge
Part 6: Interactive Rebase
Part 7: Cherry-Picking Commits in Git
Part 8: Using the Reflog to Restore Lost Commits
Teamwork: Write down a convention
Before we explore different ways of structuring releases and integrating changes, let’s talk about conventions. If you work in a team, you need to agree on a common workflow and a branching strategy for your projects. It’s a good idea to put this down in writing to make it accessible to all team members.
Admittedly, not everyone likes writing documentation or guidelines, but putting best practise on record not only avoids mistakes and collisions, it also helps when onboarding new team members. A document explaining your branching strategies will help them to understand how you work and how your team handles software releases.
Here are a couple of examples from our own documentation:
master represents the current public release branch
next represents the next public release branch (this way we can commit hotfixes on master without pulling in unwanted changes)
feature branches are grouped under feature/
WIP branches are grouped under wip/ (these can be used to create “backups” of your personal WIP)
A different team might have a different opinion on these things (for example on “wip” or “feature” groups), which will certainly be reflected in their own documentation.
Integrating changes and structuring releases
When you think about how to work with branches in your Git repositories, you should probably start with thinking about how to integrate changes and how to structure releases. All those topics are tightly connected. To help you better understand your options, let’s look at two different strategies. The examples are meant to illustrate the extreme ends of the spectrum, which is why they should give you some ideas of how you can design your own branching workflow:
Mainline Development
State, Release, and Feature Branches
The first option could be described as “always be integrating” which basically comes down to: always integrate your own work with the work of the team. In the second strategy you gather your work and release a collection of it, i.e. multiple different types of branches enter the stage. Both approaches have their pros and cons, and both strategies can work for some teams, but not for others. Most development teams work somewhere in between those extremes.
Let’s start with the mainline development and explain how this strategy works.
Mainline Development
I said it earlier, but the motto of this approach is “always be integrating.” You have one single branch, and everyone contributes by committing to the mainline:
Remember that we’re simplifying for this example. I doubt that any team in the real world works with such a simple branching structure. However, it does help to understand the advantages and disadvantages of this model.
Firstly, you only have one branch which makes it easy to keep track of the changes in your project. Secondly, commits must be relatively small: you can’t risk big, bloated commits in an environment where things are constantly integrated into production code. As a result, your team’s testing and QA standards must be top notch! If you don’t have a high-quality testing environment, the mainline development approach won’t work for you.
State, Release and Feature branches
Let’s look at the opposite now and how to work with multiple different types of branches. They all have a different job: new features and experimental code are kept in their own branches, releases can be planned and managed in their own branches, and even various states in your development flow can be represented by branches:
Remember that this all depends on your team’s needs and your project’s requirements. While this approach may look complicated at first, it’s all a matter of practise and getting used to it.
Now, let’s explore two main types of branches in more detail: long-running branches and short-lived branches.
Long-running branches
Every Git repository contains at least one long-running branch which is typically called master or main. Of course, your team may have decided to have other long-running branches in a project, for example something like develop, production or staging. All of those branches have one thing in common: they exist during the entire lifetime of a project.
A mainline branch like master or main is one example for a long-running branch. Additionally, there are so-called integration branches, like develop or staging. These branches usually represent states in a project’s release or deployment process. If your code moves through different states in its development life cycle — e.g. from developing to staging to production — it makes sense to mirror this structure in your branches, too.
One last thing about long-running branches: most teams have a rule like “don’t commit directly to a long-running branch.” Instead, commits are usually integrated through a merge or rebase. There are two main reasons for such a convention:
Quality: No untested or unreviewed code should be added to a production environment.
Release bundling and scheduling: You might want to release new code in batches and even schedule the releases in advance.
Next up: short-lived branches, which are usually created for certain purposes and then deleted after the code has been integrated.
Short-lived branches
In contrast to long-running branches, short-lived branches are created for temporary purposes. Once they’ve fulfilled their duty and the code has been integrated into the mainline (or another long-lived branch), they are deleted. There are many different reasons for creating a short-lived branch, e.g. starting to work on a new and experimental feature, fixing a bug, refactoring your code, etc.
Typically, a short-lived branch is based on a long-running branch. Let’s say you start working on a new feature of your software. You might base the new feature on your long-running main branch. After several commits and some tests you decide the work is finished. The new feature can be integrated into the main branch, and after it has been merged or rebased, the feature branch can be deleted.
Two popular branching strategies
In the last section of this article, let’s look at two popular branching strategies: Git Flow and GitHub Flow. While you and your team may decide on something completely different, you can take them as inspiration for your own branching strategy.
Git Flow
One well-known branching strategy is called Git Flow. The main branch always reflects the current production state. There is a second long-running branch, typically called develop. All feature branches start from here and will be merged into develop. Also, it’s the starting point for new releases: developers open a new release branch, work on that, test it, and commit their bug fixes on such a release branch. Once everything works and you’re confident that it’s ready for production, you merge it back into main. As the last step, you add a tag for the release commit on main and delete the release branch.
Git Flow works pretty well for packaged software like (desktop) applications or libraries, but it seems like a bit of an overkill for website projects. Here, the difference between the main branch and the release branch is often not big enough to benefit from the distinction.
If you’re using a Git desktop GUI like Tower, you’ll find the possible actions in the interface and won’t have to memorize any new commands:
GitHub Flow
If you and your team follow the continuous delivery approach with short production cycles and frequent releases, I would suggest looking at GitHub Flow.
It’s extremely lean and simple: there is one long-running branch, the default main branch. Anything you’re actively working on has its own separate branch. It doesn’t matter if that’s a feature, a bug fix, or a refactoring.
What’s the “best” Git branching strategy?
If you ask 10 different teams how they’re using Git branches, you’ll probably get 10 different answers. There is no such thing as the “best” branching strategy and no perfect workflow that everyone should adopt. In order to find the best model for you and your team, you should sit down together, analyze your project, talk about your release strategy, and then decide on a branching workflow that supports you in the best possible way.
If you want to dive deeper into advanced Git tools, feel free to check out my (free!) “Advanced Git Kit”: it’s a collection of short videos about topics like branching strategies, Interactive Rebase, Reflog, Submodules and much more.