Scribd
Upload
2 views

Git Commands Short NMotes

The document outlines essential Git commands for Automation Engineers, covering setup, cloning repositories, checking status, staging, committing changes, and pushing code. It emphasizes the importance of committing frequently, writing clear commit messages, and maintaining an updated workflow by merging the main branch into feature branches. The document also describes the typical steps to follow before pushing code and creating pull requests to ensure a clean Git history and avoid conflicts.

Uploaded by

ravicse548
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
2 views

Git Commands Short NMotes

The document outlines essential Git commands for Automation Engineers, covering setup, cloning repositories, checking status, staging, committing changes, and pushing code. It emphasizes the importance of committing frequently, writing clear commit messages, and maintaining an updated workflow by merging the main branch into feature branches. The document also describes the typical steps to follow before pushing code and creating pull requests to ensure a clean Git history and avoid conflicts.

Uploaded by

ravicse548
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

As an Automation Engineer, you will primarily be using the following Git

commands in your day-to-day tasks. These commands are essential for


managing repositories, branches, commits, and synchronization with
remote repositories:

1. Set Up Git (Only once)


Set your username and email (if not set already):
bash
Copy code
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

2. Cloning a Repository
Clone an existing repository to your local machine:
bash
Copy code
git clone <repository_url>

3. Checking the Status


Check the status of your repository (staged, unstaged, untracked changes):
bash
Copy code
git status

Create a new branch:


git branch <branch_name>

Switch to an existing branch:


git checkout <branch_name>

Create and switch to a new branch in one command:


git checkout -b <branch_name>

4. Adding Files to Staging Area


1.
2.
3. /Stage Your Changes:
○ Add the changes you’ve made in your working directory to the staging area.

bash
Copy code
git add <file_name> # To add a specific file
git add . # To add all modified files

4.
5. Commit Your Changes:
○ After staging, commit your changes with a clear and concise commit message.
This creates a snapshot of your changes in the local repository.

bash

git commit -m "Your commit message describing the change"

6.
○ If you've made multiple changes and want to commit them all at once, you can
commit them after staging all files with git add ..
7. Check the Status:
○ It’s good practice to check the status of your repository before committing to see
which files have been staged or modified.

bash
Copy code
git status

8.
9. Optional: Check Commit History:
○ Before committing, if you want to review the last few commits, you can use:

bash
Copy code
git log --oneline

10. This gives a quick overview of recent commits and helps ensure you’re working in the
correct context.

Example Workflow:
Here’s the typical sequence of commands before checking out the main branch:

Add and Commit Your Changes:


bash
Copy code
git add .
git commit -m "Fixed bug in user authentication flow"

1.

Verify the Commit:


bash
Copy code
git status # To confirm all changes are committed
git log --oneline # To see your latest commits

2.

After this, you can proceed with checking out the main branch, pulling the latest changes, and
then merging as needed, as discussed in the previous steps.

Why These Steps Matter:


● Committing Early and Often: It’s always a good idea to commit your changes
frequently. This way, you don’t lose your work, and each commit is a logical snapshot of
your progress.
● Commit Messages: Always write clear and descriptive commit messages so that others
(and you) can understand what the commit includes.

Steps to Follow Before Pushing Code:


1. Checkout to the Main Branch:
○ First, make sure you are on the main branch (or the branch you want to merge
your changes into).

bash
Copy code
git checkout main

2.
3. Pull the Latest Changes from the Main Branch:
○ Fetch the latest changes from the remote repository to ensure your local main
branch is up-to-date with the remote.

bash
Copy code
git pull origin main
4.
5. Checkout to Your Feature Branch:
○ Switch to the branch where you have been working and made your changes.

bash
Copy code
git checkout <your_feature_branch>

6.
7. Merge Main into Your Feature Branch (Optional but Recommended):
○ This step is important if there have been new commits to the main branch while
you were working on your feature branch. Merging the main branch into your
feature branch will ensure your branch is up-to-date with the latest changes in
the main branch and will help prevent conflicts.

bash
Copy code
git merge main

8.
○ If there are merge conflicts, you'll need to resolve them before proceeding.
9. Push Your Changes to Your Feature Branch:
○ Now, push your local commits to the remote repository in your feature branch.

bash
Copy code
git push origin <your_feature_branch>

10.
11. Create a Pull Request (PR) or Merge Request (MR):
○ After pushing the changes, you typically create a Pull Request (in GitHub) or
Merge Request (in GitLab) to merge your feature branch into the main branch.

Why This Workflow?


● Staying Updated: By pulling the latest changes from the main branch, you make sure
you're working with the most up-to-date code, reducing the chances of conflicts later
when merging.
● Avoiding Conflicts: Merging the main branch into your feature branch early gives you
the opportunity to fix any conflicts in your branch before pushing your changes and
creating a pull request.
● Clean History: This workflow helps keep the Git history clean and ensures that your
changes are properly reviewed before being integrated into the main branch.

This process is very common in teams following Gitflow or a similar branching strategy.

You might also like