Git - Daily Workflow and Frequently Used Commands

If you use Git as your version control system for your project, you must need to have an basic overview of the most frequently used git commands and git workflow for working with git in an enterprise team project. This post is precisely going to talk about it.

Begin a Project/Task - 

In most cases, you will be working on an existing remote repository in an enterprise project. you will be asked to clone the remote repository into your local and start working on a new branch. 

Before you can do a git clone, you have to - 
a. Set up an SSH/HTTP connection between your computer and remote repository (GitHub or Azure Devops)
b. Create a directory on your local computer where you want to clone the remote repo. 

Here is the command you can use to clone an existing repository - 

$ git clone <REMOTE_REPO_URL>

Note - this is a one-time activity which you need to do unless you mess up the repository and want to fix it by cloning again. 

Working in a Local Repository - 

Create a new branch  - 
$ git branch <New_Branch_Name>
Start working on the newly Created Branch - 
$ git checkout <New_Branch_Name>
note - this is also the command to switch to any existing branch in your repository. 

Command to create a branch and checkout the branch at the same time - 
$ git checkout -b <New_Branch_Name>

Now you can start making changes in the existing files in the Project or create new files. You can keep saving your work in the work-space but that save is not tracked by git. 

Check all the files that are changed but untracked by git - 
$ git status

Add the untracked files to git so that git can keep track of all your changes - 
$ git add <file_Name>

You can also add a file by specific file extensions. e.g. you can add all files with extension .java - 
$ git add .java 

You can also add all untracked files using -  
$ git add .  

So far, you are working in your local repository. Adding the files (using git add) into git tracking is not enough for pushing the changes from local repository to remote repository. To be able to do that, you have to commit your changes using below command. Committing your changes puts the changes in a staging area. 

$ git commit -m "<your_commit_message_explaining_the_changes>

note - it is a good idea to commit your changes often at every logical end of your changes. Also always add a good message to your commit command that explain the changes your are trying to commit. This commit messages will help to identify the commits from commit history and you can easily go back to a previous history if need be. 

Contributing to a Project in Remote Respository- 

Now, that you committed your changes, you can push your changes from local repository to remote repository using the below push command - 

$ git push origin <Your_branch_name>

note - git push will push the changes from your local branch to remote branch. if the local branch name already exists in remote, then it will update the changes from local branch to remote branch. If the local branch name doesn't exist in remote, then it will create the remote branch with the same name as your local branch name. 

As a good practice, when you push your changes to remote, you are only pushing to your remote branch not updating the remote master. To update (merge) your branch with the remote master, we need to raise a pull request which will go through the code review and approved and only then the remote branch will get merged with the remote master. 

Digesting Changes by Others on the same Project - 

When you work on an enterprise project in a team, there will be multiple people who will do code changes in the same repository as well as in the same file/program/class. We need to be able to perform continuous integration by having processes which ensures that team members push their changes from local to remote very often (at least once in a day). 

Whenever any changes done in the repository by someone else, we need to sync up our local repository with the changes done in remote so that our local is always up to date. Keeping the local repository up to date, it eliminates the risk of a lot of merge conflicts  (which otherwise takes a lot of time to resolve) later when we try to merge with remote.  

We can take advantage of  "git fetch", "git merge", "git pull" to keep the local repository up to date with the remote repository. 

git fetch commands only download all the changes from remote repository that has been added after your last clone/fetch. Note - git fetch only download the information, but it doesn't modify anything in the repository or branch you are working on. 
$ git fetch origin

git merge command merge the changes of the branch that you specify in the command with the branch you are currently checked out - 
$ git merge <remote_branch_name>


git pull command does the git fetch and git merge in a single step - 
$ git pull <remote_branch_name>

Resolving Merge Conflict - 

When you raise a Pull request to merge your branch with remote master, you may run into merge conflicts which basically means that there are changes present in the remote master that is either "not present" or "overlapping" in the branch that you are trying to merge and git don't know what to do. To be able to resolve the merge conflict, you need to first see that where in the file/code the merge conflicts are present and then accept either the remote master changes or your changes or both. 

To see the merge conflicts in eclipse or similar IDE, we can follow the below steps - 
1. Checkout the branch which you were trying to merge with remote master. 
2. do a git fetch
3. do a git merge Origin/master - this will merge the remote master with the checked out branch. This merge will end up with Merge Conflict status similar to the pull request that resulted into the merge conflict. 
4. Now, you can go into your work-space in the IDE and see the merge conflicts. The conflicts appear under the banner of <<<<<< HEAD etc. 
5. Review all the conflicts, correct the code and save it. 
6. git add the files that you changed to resolve the conflicts. 
7. git commit 
8. git push your branch again to remote. 
9. Pull request should have updated with the recent changes and the merge conflicts should have been resolved by now to be able to merge the branch with remote master. 

Other Resources - 

Below are some other useful resources to learn more about git - 

git Scm official documentation - 
git branching - 
git troubleshooting from various scenarios - 
https://ohshitgit.com/
10 Git Commanda
https://towardsdatascience.com/10-git-commands-you-should-know-df54bea1595c










Comments

Post a Comment

Popular posts from this blog

How To Dynamically Allocate Files from a Cobol Batch Program

Normally, in COBOL file based process we allocate file in the JCL using DD names. However, There can be situations when we might need to allocate files dynamically. For example, there is a requirement to allocate different file for different member ID. The total number of files needs to be allocated is not a constant and also the file names need to have the member ID in the file naming. So the files can not be allocated in the JCL, it has to be allocated at the run time when the Cobol program is processing data.  This type of requirement is the best use case for using 'dynamic file allocation technique'. IBM supplied routine BPXWDYN can be used to dynamically allocate files in batch programs. The below sample code snippet dynamically creates a new dataset and allocates it to DDname OUTFILE and then it opens the file in OUTPUT mode and writes a record to it. IDENTIFICATION DIVISION.  PROGRAM-ID. MCANUP6.  ENVIRONMENT DIVISION.  INPUT-OUTPUT SECTION...
Read more