Git

Components

• Branch
  • Everything in git lives on a branch.
  • Main branch is where the "main" or production version usually recides.
• Remote Repository: Source of truth. All changes are synced with this.
• Local Repo: Most changes will be done on local.

Local and remote repos only interact when you run one of these: 

• git clone
• git fetch 
• git pull
• git push

Workflow

Lightweight workflow:

1. Create a branch off of main
   • Usual practice is to create a new branch when working on a feature or fix. The branch copies from main but changes stay only in your branch at first.
   • List local branches: git branch
   • New branch: git branch myfeaturebranch
   • Checkout to a branch: git checkout myfeaturebranch
2. Stage and Make commits
   • Changes can be committed to feature branch as you go, it doesn't merge with main yet.
   • git add .
   • git commit -m "new feature"
3. Push changes to remote repo: git push -u origin myfeaturebranch
4. Open a pull request
   • This is where you can start discussing your changes.
   • Creating PR on github
     1. Go to your GitHub account on the web
     2. Click the Pull Request tab
     3. Click New Pull Request 
     4. In the Base dropdown, choose main 
     5. In the Compare dropdown, choose myfeaturebranch.
     6. Click Create pull request 
     7. Enter a Subject line and Comment
     8. Click Create pull request
   • Pull request reviews have special power in GitHub when used in conjunction with protected branches, you can prevent a pull request from being merged if it has not had at least one review.
   • If you have CI/CD integrated, you will see status of the tests right in the PR.
5. Collaborate
   • Make more commits
   • Discuss and review code with team members
   • In PR, you can post general comments in 'Conversation' tab, comment on specific line by hovering over it in the 'Files changed' tab.
   • While making comment on a particular line, you can choose to 'Start a review' - you can group many line comments together then.
6. Deploy for final testing
   • Deploy your feature branch itself for testing
   • "Deploy-before-merge" flow – more cautious approach
   • If any issue arises, you can simply deploy the main branch again since your changes are not merged yet.
7. Merge your branch into the main branch
   • Click 'Merge Pull Request', add a merge comment, and click Confirm merge.
   • Your team should establish rules about who should merge a pull request. Some options include:
     • The person who created the pull request should merge, as they’ll need to resolve issues resulting from the merge.
     • Assign a single person within the project team. This ensures consistency but can become a bottleneck.
     • Anyone other than the person who created the pull request can merge. This ensures at least one review has taken place.
8. Keeping it clean and in sync
   • delete the branch on GitHub. To do this click Delete branch at the bottom of the pull request screen
   • However, merging and deleting on GitHub will not automatically update your local copy of the repository. Let’s go back to our command line application and get everything in sync. First, we need to get the changes we made on GitHub into our local copy of the repository:
     • Switch back to your default branch: git checkout main
     • Retrieve all of the changes from GitHub: git pull
     • git pull = git fetch + git merge

Local Configuration

git config

Three levels of configurations:

1. git config --system: System-wide configurations
2. git config -- global: User-level configurations
3. git config --local (default): Repo-level configs

List all configurations: git config --list (from all three levels)

You can't commit without these:

• git config --global user.name "First Last"
• git config --global user.email "you@email.com"

Configure autocrlf

autocrlf = auto carriage return line feed

Different systems handle line endings differently. If you open a file from different OS, without this option enabled, git will think you have modified it.

• Windows: git config --global core.autocrlf true 
• Mac/Linux: git config --global core.autocrlf input

Internals

.git folder in your repo is the entire git database.

Git tracks local files by organizing the changes in three areas:

1. Working tree: The files and folders where you actually work.
   • You can check status of working tree, that is, current branch, whether changes are staged, or if there are any changes at all, using git status.
2. Staging area/index: When you add a 'discrete unit of work' using git add . -> git stores the changes to be committed in a binary file - .git/index. The changes are said to be "staged".
3. History: Once you run git commit the staged changes are added to the history i.e. a snapshot is recorded in your project's timeline under the directory .git/objects.

GLP (Git log pretty) alias glp='git log –pretty=format:"%C(yellow)%h%Creset - %C(green)%an%Creset, %ar : %s"' 95% Of Software Engineers Aren't Using This Simple Git Trick - YouTube