Skip to content

Instantly share code, notes, and snippets.

@misostack
Last active September 19, 2023 09:55
Show Gist options
  • Save misostack/7f88e207446df6ec84b036f91093e400 to your computer and use it in GitHub Desktop.
Save misostack/7f88e207446df6ec84b036f91093e400 to your computer and use it in GitHub Desktop.
GIT commands

Git tips

First config

ssh-keygen -t rsa -C "misostack.com@gmail.com"
git config --global user.name "misostack"
git config --global user.email "misostack.com@gmail.com"

Delete Multiple Local Branches

git branch | grep ‘your_string_here’

Delete it remotely too.

git branch | grep ‘your_string_here’ | xargs git push origin — delete

Example

git branch -D `git branch | grep -vE 'master|develop|release/*'`

Delete branch

local branch

git branch -d local-branch-name

remote branch

git push origin -d remote-branch-name

Disabled Push

git remote set-url --push origin DISABLE # important, you can not push directly on origin repo

Tags

# create new tag
git tag tagName
git push --tags
# delete local tag
git tag -d 12345
# delete remote tag '12345' (eg, GitHub version too)
git push origin :refs/tags/12345
# alternative approach
git push --delete origin tagName

git tag -d tagName

How to fix some strange errors related to git

cannot lock ref 'refs/remotes/origin

Root cause : image

Answered

git fetch --prune
@misostack
Copy link
Author

# GIT guide

<br>

## I - Main branches

<br>

*testing**: This branch should be used to deploy your work to the server for QC to test. Its origin is "master". It is not stable and will be an exact copy of your branch when tested by QC.
*master**: This branch contains all the finished and tested features.
*production-x-x-x**: This branch cherry pick the features that the client wants for this release.

<br>

<br>

## II - Working branch

<br>

You should always work on your own branch.

<br>

### Naming conventions

<br>

* If it is a new feature: `feature/redmine-id`
* If it is a bug fix: `bug/redmine-id`
* If it is an improvement: `improvement/redmine-id`

<br>

### Before asking for a review

<br>

You should rebase on master and fix all the conflicts. Rebasing will put all the new commits from master that you don’t have on your branch, behind your commits. So the two branches will have the same history.

<br>

To rebase, use the interactive command:

git rebase -i origin / master --autosquash

The rebase command will check your commits in the same order you posted them and stop if there is a conflict. Once the conflict is resolved, you can use:

git rebase --continu

to continue the examination. You will do this until you see a success message.
You may have to force push your code:

git push -f

so be sure of your conflict resolution.

<br>

<br>

## III - Commits

<br>

A commit should be a clear division of labor, with a clear title. This helps reviewers understand your code even though they are all overwritten at the end.

<br>

### You should use

<br>

To verify that what you are going to commit is what you think. That you don't commit logs and dead code:

git add -p

<br>

To see the history of the commits:

git log

<br>

To modify the last commit:

git commit --amend

<br>

To modify an existing commit:

git commit --fixup <commit ID>

<br>

<br>

## IV - Testing

<br>

When the QC asks the environment to test use:

git push -f origin <your-branch>:testing

to deploy it. When the pipeline is done, notify the QC.

<br>

<br>

## V - Merge Request

<br>

### Prerequisite

<br>

* When you start working on a feature you should create a MR with a WIP status
* You should add as tag the priority of the feature
* You should add as tag the target version
* You should add as title: `redmine id - redmine subject`
* You should have a little functional or technical description for feature, hot fix, …

<br>

### Before asking any review

<br>

You need to make sure that:
* The code works as expected in the analysis.
* The code follows the rules of good programming.
* You have not created any bugs in the rest of the project.

<br>

### Review

<br>

You should at least ask your TL to review your MR and a developer if you are not alone working on the project.

Please try to find by yourself the best way to do your job, the most optimized way or at least to learn from the reviews.

<br>

### After review

<br>

Simply remove the WIP status so that maintainers can understand that the MR is ready to be merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment