Git Workflow

Quick Links!

Branch Naming Convention

Branch names consist three elements: Issue Type <type>, Feature Name <name> and Issue Number #.
Generally, feature name will depend on a user story. Therefore, it will be a long name. If feature name is too long, please use a shorter yet descriptive one. When feature name is more than one word, use camelCase.
Use slashes / to separate elements.
For example
- Issue Type: Feature
- Issue Name: As a User I can sign-up, login and logout.
- Issue No: 12
- Branch name can be feat/user-Auth/#12.
When several people are working on the same feature, it might be convenient to have personal feature branches and a team-wide feature branch. Use the following naming convention:

git checkout -b feat/user-Auth/#12/master     -- team wide branch
git checkout -b style/navbar/#12/pikachu        -- Pikachu's personal branch
git checkout -b feeat/user-Auth/#12/spiderman    -- Spiderman's personal branch

Be consistent with using this format.

Common Commands

Creating/switching to/deleting branches

git branch <branch-name> -- create a new branch <branch-name>. This does not automatically switch you (check out) this new branch, just creates it.
git checkout <branch-name> -- switch to another, existing branch
git checkout -b <branch-name> -- create a new branch and immediately check out that branch.
git branch -d <branch-name> -- delete a branch. You can't delete a branch you're currently on, so you need to checkout another branch first.
- If git determines that you may lose some changes that haven't been committed by deleting a branch, it will give you a warning. If this command successfully runs, you can rest assured you haven't lost any changes.
git fetch --prune -- remove any local upstream-tracked branches that have been removed from the remote repository. If you submit a pull request and delete the feature branch after merging it into your main code, you could run this command to clean up your local repository.

Staging/committing/pushing

git add <filename> -- stage a specific file for committing
git add -A -- stage everything that has been modified since the last commit for committing.
git commit -- create a new commit (save point) of everything that has been staged. This will open a terminal editor like "vi" for you to write in a commit message.
git commit -m "<commit message>" -- create a new commit and provide a commit message all in one. This will not open a terminal editor, since you provided the commit message inline with the commit command.
git push -- push all new commits since the last push to the remote repository. This assumes you've already pushed this branch before. If you haven't...
git push -u <remote-name> <branch-name> -- pushes a branch called <branch-name> for the first time to the remote called <remote-name>, and sets up remote tracking for that branch (with the -u flag). Typically this command will look something like git push -u origin navbar.

Merging/fixing conflicts

git merge <branch-name> -- merge changes from <branch-name> into your current branch. If there are no conflicts, this will open an editor like "vi" and auto-populate a commit message for you, which you can just save as-is. (If it is "vi", hold "SHIFT" and press "Z" twice to save and quit.)
git merge --no-ff <branch-name> -- same as above, but will also maintain a nicer branch history. It's usually recommended to include the --no-ff flag when merging branches.
git mergetool -- open the default git tool for fixing conflicts. If after a merge there are a bunch of conflicts (shows up in the terminal with "CONFLICT"), you'll need to fix those conflicts before the merge will complete.

Cloning, working with remotes

git clone <ssh or https url> download a project from a remote repository and put everything in a new folder with the same name as a the repository's name. Also sets up a remote called origin set to the same location as <ssh or https url> for future pushing/pulling from this remote.
git clone <ssh or https url> <new-folder-name> -- same as above, but choose a different name for the local folder if you don't want it to have the same name as the repository.
git remote -v -- check the URL of all your remotes.
git remote add <remote name> <ssh or https url> -- create a new "remote" address for pushing/pulling branches. The super common convention for your first/main remote is to use the name origin, so the command above will typically look like git remote add origin <ssh or https url>. You may, however, add as many remotes as you'd like, in case you want to push your code to more than one remote repository.
git remote remove <remote-name> -- remove a remote. You'll no longer be able to push/pull from that remote unless you add it back.

The Workflow

For these commands, we'll assume a simple structure where the dev branch is the one you branch off of to do dev work. master branch is only for deployment in this practice, and only dev branch can merge into master branch!

In a real dev environment, your team will likely have many layers between the code you develop on and the master branch, such as some deployment branches, QA branches, etc.

Start working on a new feature branch

git checkout dev
git pull -- makes sure that you're starting from the latest code
git checkout -b <new-branch-name> -- create and checkout a new branch

Merge a local branch to the local dev branch.

WARNING!!! Only to be used when working alone on a project

Assuming you're already on your feature branch and have finished developing the new feature and would like to merge it into the main master branch code:

(Add and commit your code from the feature branch)
git checkout dev
git pull -- Just in case it was updated from somewhere else, like directly from GitHub.
git merge --no-ff <feature-branch>

Prepare to open a pull request on Github

git checkout dev -- (or other starting-point branch)
git pull -- make sure you have the latest code, in case the dev branch has progressed since you branched off of it when you started working on this new branch
git checkout <feature-branch> -- Move back to the branch you've been working on 1. If there was new code pulled down to the dev branch after running git pull, you'll now run git merge --no-ff dev to update your current branch with the changes that have recently been made on dev.
```
2. If there were conflicts when merging in the previous step, you'll fix those now with git `mergetool`, finishing everything off with `git commit` (no `-m` this time) and saving the pre-populated merge commit message.
```
TEST YOUR PROJECT - Don't push up a branch that includes code that broke your project! Before you push, run the project to make sure it seems to be working as expected. If you have automated tests written, run all of them now.
git push -u origin <feature-branch> -- push your branch to GitHub
Go to your GitHub repo and create a new pull request with the branch you just pushed.

Let your team look at the changes you made, add comments, suggest new changes or fixes, etc. Make sure to remove any console.logs or commented-out code. Think of the dev branch as a final draft of a college paper.

Clean up after successfully completing a pull request

GitHub offers to delete the remote branch you just merged to dev. This is usually a good idea to avoid extraneous, unused branches from cluttering up the repository.

If you forgot to delete the remote branch from GitHub or chose not to, but now would like to delete it, you can delete a remote branch on GitHub from the terminal by running git push --delete <remote-name> <branch-name>. This would likely be something like git push --delete origin navbar.

git checkout dev -- move to the dev branch, where you just finished merging your code via the pull request on GitHub.
git pull -- pull down those latest changes
git branch -d <feature-branch> -- since your branch has been successfully merged, you don't need the local copy of it anymore and it should be removed.
git fetch --prune -- remove the local tracking branches that you deleted from the remote repo.

Reference

This article is copied from Git Commands and Workflows Cheat Sheet article written by Bob Ziroll. Some text has altered for this specific project. Thank you, Bob Ziroll, for this kind and great cheat-sheet!

Here is the link of original post: https://coursework.vschool.io/git-commands-and-workflows-cheat-sheet/

Provide feedback

Saved searches

Use saved searches to filter your results more quickly