Keeping a clean git history can save a lot of time when trying to track down commits related to a bug or issue that is disrupting dev efforts. GitHub provides three options when merging in commits, these three options being: – Create a Merge Commit – Squash and Merge – Rebase and Merge Merging with a merge commit, squash merging, and “Rebase & Merge” should be pretty familiar as these are commands that are already commonly used when working on dev branches to keep commits on PRs tidy. We can apply this way of thinking when we want to keep the master branch Git history clean and helpful to future you and other developers who may be combing through the history to figure out why the code structure is the way it is.
The Short Answer (TL;DR)
If GAAP Compliance is required or you need 4 decimal places:
Which supports a max value of:
Otherwise, if 2 decimal places is enough:
Which supports a max value of:
The compromise of a staff user account credentials is a critical step in the kill chain of many data breaches. This compromise may be accomplished in many ways, including a staff user falling victim to a:
- credential stuffing attack when email and passwords in outside breaches are used to authenticate with work systems (because people reuse the same passwords frequently)
- targeted spear-phishing campaign to intercept valid credentials via a spoofed login form
- business e-mail compromise via a convincingly forged e-mail supposedly from a supervisor or the CEO
There are a few levels of staff credentials to address, those with access to:
- legitimate business e-mail
- the administrative portal/customer service via a web interface
- development resources and testing environments
- production resources like cloud providers and the domain name configuration
Traditional information security practice calls for the separation of duties between developers and those with production access. However, often only the most sophisticated, established organizations have the dedicated resources to do that. For everyone else, the developers usually have access to all these resources.
Abuser stories have been around for a while, and while not a revolutionary idea, it is somewhat of an untapped one, an underappreciated one, one that I personally hadn’t been exposed to in my nearly 30 years working as a business analyst. That’s a huge problem, if you ask me.
If you’ve been following our Git related posts, you probably notice we use
git add --p with many of the examples used. This a great way for developers to split up code changes on one file to their own commit message. Not only will this make your pull requests cleaner, but will allow the code reviewer to get valuable context when diving into code changes on said file.
Git add patch gives us many options:
Stage this hunk [y,n,q,a,d,e,?]?, the
split option allows us to split lines that are close in proximity to each other. There are times where
split won’t conveniently break up lines into hunks, lets explore how we can manually edit those tricky splits.
Fuzzy finders find files that almost no developer would intentionally find via a fuzzy finder from paths
dist/. These tend to get in the way of the true power of fuzzy file
searching and ignoring these individually can be a pain. There are also files like
.rubocop.yml that are opened often enough to be included in the result set.
Luckily when working in a git repository, developers typically only care about the files they commit. When using fzf.vim, this technique returns files based on the git tree leaving out irrelevant files, including the hidden files that were shown before.
Managing many Clients with several projects where multiple team members are working them, across an Agency that has a different product offerings can be a challenge. Finding tools and processes to sort it out and ensure everything gets done, is on time, and on budget can be really hard, especially for a small Agency whose trying to keep costs down. The productivity tool market is flooded with options, and finding a good one is tough – but when you do, you want to share. Here’s a quick story on what we’re currently trying to tame the todo list. I hope you find it useful!
At Rietta, we understand the importance of continuing our education outside of the classroom. We use a reading channel in our company Slack to keep a pulse on industry and keep each other informed on the latest vulnerabilities. It’s been working great. Here’s how we do it.
An anonymous attacker has been compromising Git repositories and demanding ransom. This attacker stole the contents and used a
force push to wipe the remote repository causing many to lose access to their critical source code assets. Use critical security tools available within the Git ecosystem to protect your company from this threat with:
- Deploy Keys
- Mandatory Two Factor Authentication
- Protected Branches and Pull Requests
- Backups of your Git Repositories
Here at Rietta, we like to do in-depth code reviews that are sometimes accompanied with feedback that may require changes to be made to the pull request. When making additional commits with changes based on the feedback, we can get into a messy workflow that can lead to complex branch wrangling.
In this article, I will go over a few Git commands to help ease our post code-review revisions:
git commit --fixup commit-SHA
git rebase -i --autosquash source-branch