-
Notifications
You must be signed in to change notification settings - Fork 52
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* test vue * new error added * doc indiv new page added * major update on doc page * husky removed * some minor issue fix * code clean up + code optimize for color * new doc added * new post added + folder rename + minor changes * background color darker * ui + doc page issue fix * try 1 for api issue * folder conflict issue fix
- Loading branch information
Showing
5 changed files
with
232 additions
and
6 deletions.
There are no files selected for viewing
121 changes: 121 additions & 0 deletions
121
public/assets/posts/git_hooks_automating_your_workflow.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,121 @@ | ||
Git hooks are powerful scripts that can automate various aspects of your development workflow. They allow you to execute custom scripts before or after important Git events, such as committing, pushing, or merging. This post will introduce you to Git hooks and show you how to leverage them effectively. | ||
|
||
## What Are Git Hooks? | ||
|
||
Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. They reside in the `.git/hooks` directory of every Git repository and can be written in any scripting language. | ||
|
||
## Types of Git Hooks | ||
|
||
Git hooks can be categorized into client-side and server-side hooks: | ||
|
||
### Client-side Hooks | ||
|
||
1. **pre-commit**: Runs before a commit is created | ||
2. **prepare-commit-msg**: Runs before the commit message editor is fired up | ||
3. **commit-msg**: Runs after the commit message is saved | ||
4. **post-commit**: Runs after the commit is created | ||
5. **pre-push**: Runs before a push is executed | ||
|
||
### Server-side Hooks | ||
|
||
1. **pre-receive**: Runs when the server receives a push | ||
2. **update**: Similar to pre-receive, but runs once for each branch | ||
3. **post-receive**: Runs after a push has been accepted | ||
|
||
## Setting Up a Git Hook | ||
|
||
1. Navigate to your repository's `.git/hooks` directory. | ||
2. Create a new file with the name of the hook you want to implement (e.g., `pre-commit`). | ||
3. Remove the `.sample` extension if it exists. | ||
4. Make the file executable: | ||
|
||
```bash | ||
chmod +x .git/hooks/pre-commit | ||
``` | ||
|
||
5. Edit the file with your desired script. | ||
|
||
## Example: A Simple pre-commit Hook | ||
|
||
Here's a simple pre-commit hook that checks for debugging statements: | ||
```bash | ||
#!/bin/sh | ||
if git diff --cached | grep -E '(console.log|debugger)' > /dev/null; then | ||
echo "Error: Debugging statements detected. Please remove them before committing." | ||
exit 1 | ||
fi | ||
``` | ||
This script checks for `console.log` or `debugger` statements in your staged changes and prevents the commit if any are found. | ||
## Best Practices for Using Git Hooks | ||
1. **Keep hooks simple**: Complex hooks can slow down Git operations. | ||
2. **Use hooks consistently**: Ensure all team members use the same hooks. | ||
3. **Version control your hooks**: Store hooks in your repository and symlink them. | ||
4. **Make hooks configurable**: Allow developers to bypass hooks when necessary. | ||
5. **Document your hooks**: Ensure team members understand what each hook does. | ||
## Sharing Hooks with Your Team | ||
To share hooks with your team: | ||
1. Create a `hooks` directory in your repository. | ||
2. Add your hook scripts to this directory. | ||
3. Create a setup script that symlinks these hooks to `.git/hooks`. | ||
4. Add instructions for running the setup script to your README. | ||
## Advanced Git Hook Usage | ||
### Linting | ||
Use a pre-commit hook to run linters: | ||
```bash | ||
#!/bin/sh | ||
if ! npm run lint; then | ||
echo "Linting failed. Please fix errors before committing." | ||
exit 1 | ||
fi | ||
``` | ||
### Automatic Formatting | ||
Use a pre-commit hook to automatically format code: | ||
```bash | ||
#!/bin/sh | ||
if ! npm run format; then | ||
echo "Formatting failed. Please run formatting manually and try again." | ||
exit 1 | ||
fi | ||
``` | ||
### Preventing Commits to Specific Branches | ||
Use a pre-commit hook to prevent direct commits to protected branches: | ||
```bash | ||
#!/bin/sh | ||
branch="$(git rev-parse --abbrev-ref HEAD)" | ||
if [ "$branch" = "main" ]; then | ||
echo "You can't commit directly to main branch" | ||
exit 1 | ||
fi | ||
``` | ||
## Conclusion | ||
Git hooks are a powerful tool for automating and enforcing development workflows. By implementing appropriate hooks, you can improve code quality, enforce coding standards, and streamline your development process. | ||
Remember, while hooks are powerful, they should be used judiciously. Overly restrictive hooks can hinder productivity, so strike a balance between automation and flexibility. | ||
Happy coding, and may your Git hooks serve you well! | ||
> Written by **Sakib Ahmed** | [GitHub](https://github.com/devvsakib) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
[ | ||
{ | ||
"title": "pull_request_tutorial_for_beginners" | ||
}, | ||
{ | ||
"title": "mastering_git_branching_strategies" | ||
}, | ||
{ | ||
"title": "git_hooks_automating_your_workflow" | ||
} | ||
] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,97 @@ | ||
Git branching is a powerful feature that allows developers to work on different parts of a project simultaneously. However, without a clear strategy, it can lead to confusion and conflicts. In this post, we'll explore some popular Git branching strategies to help you collaborate more effectively. | ||
|
||
## Why Branching Strategies Matter | ||
|
||
Before diving into specific strategies, let's understand why they're important: | ||
|
||
1. **Organization**: They keep your repository organized and easy to navigate. | ||
2. **Collaboration**: They facilitate smooth teamwork by clearly defining workflows. | ||
3. **Stability**: They help maintain a stable main branch while allowing experimentation. | ||
4. **Release Management**: They simplify the process of preparing and deploying releases. | ||
|
||
## Popular Branching Strategies | ||
|
||
### 1. GitFlow | ||
|
||
GitFlow is one of the most well-known branching models. It uses two main branches: | ||
|
||
- `main`: Always reflects the production-ready state. | ||
- `develop`: Serves as an integration branch for features. | ||
|
||
Additional supporting branches include: | ||
|
||
- Feature branches | ||
- Release branches | ||
- Hotfix branches | ||
|
||
#### Pros: | ||
- Clear separation of concerns | ||
- Suitable for projects with scheduled releases | ||
|
||
#### Cons: | ||
- Can be complex for smaller projects | ||
- May lead to long-lived feature branches | ||
|
||
### 2. GitHub Flow | ||
|
||
GitHub Flow is a simpler alternative to GitFlow. It uses a single main branch and feature branches: | ||
|
||
1. Create a branch from `main` | ||
2. Add commits | ||
3. Open a pull request | ||
4. Discuss and review | ||
5. Deploy for testing | ||
6. Merge to `main` | ||
|
||
#### Pros: | ||
- Simple and easy to understand | ||
- Encourages continuous delivery | ||
|
||
#### Cons: | ||
- Less suitable for projects with multiple versions in production | ||
|
||
### 3. Trunk-Based Development | ||
|
||
This strategy involves keeping branches short-lived and merging frequently to a single "trunk" branch (usually `main`): | ||
|
||
- Developers create short-lived feature branches | ||
- Branches are merged to `main` at least once a day | ||
- `main` is always in a releasable state | ||
|
||
#### Pros: | ||
- Supports continuous integration effectively | ||
- Reduces merge conflicts | ||
|
||
#### Cons: | ||
- Requires a robust testing and CI/CD pipeline | ||
- May be challenging for less experienced teams | ||
|
||
## Choosing the Right Strategy | ||
|
||
The best branching strategy depends on various factors: | ||
|
||
- Team size and experience | ||
- Project complexity | ||
- Release frequency | ||
- Deployment process | ||
|
||
Consider these factors when selecting a strategy, and don't be afraid to adapt it to your team's needs. | ||
|
||
## Implementing Your Chosen Strategy | ||
|
||
Once you've chosen a strategy: | ||
|
||
1. Document it clearly | ||
2. Ensure all team members understand the workflow | ||
3. Use tools like branch protection rules to enforce the strategy | ||
4. Regularly review and refine your approach | ||
|
||
## Conclusion | ||
|
||
A well-implemented Git branching strategy can significantly improve your team's productivity and code quality. Whether you choose GitFlow, GitHub Flow, Trunk-Based Development, or a custom approach, the key is consistency and clear communication within your team. | ||
|
||
Remember, the best strategy is one that your team can follow effectively. Start with a basic approach and evolve it as your project and team grow. | ||
|
||
Happy branching! | ||
|
||
> Written by **Sakib Ahmed** | [GitHub](https://github.com/devvsakib) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.