DEV Community: Manojlo Ilic

Git basics

Manojlo Ilic — Sun, 10 Nov 2024 21:42:44 +0000

What is git?

Undoubtedly Git is the most used version control system today. It was developed by Linus Torvalds in 2005 for the development of the Linux kernel.

Version control system actually means that it simplifies for us developers to track, see changes to our files, and go back in time if something goes wrong.

An important thing to know is that Git is not some intimidating tool made exclusively for developers. Essentially, you can use it in simple activities such as writing a blog to track and observe your changes. To further expand our understanding of Git, let's use the example of a team of writers. So now imagine a situation where multiple writers want to collaborate on a specific project.

They would need a way to track changes to determine who wrote each part and integrate their individual stories into the main one. All of this can essentially simplify the progress of the entire project. After some work by our imagined writers, we could observe their workflow.

You can observe the green bullet, which represents the default branch (usually named master or main) that Git creates when you first set up a repository. Writers then create branches from the master and incorporate their changes, which are eventually merged back into the master. I will provide additional explanations on how this is done, along with the commands used.

States of Git

One of the primary functions of Git commands is to manipulate data. There are three areas where our data can reside when working with Git.

Modified
Staged
Committed

"Modified" indicates that you have made changes to a file but have not committed them yet.

"Staged" means you have marked a modified file in its current version to be included in your next commit.

"Committed" means that the changes are securely stored locally on your machine.

All these states occur in the local repository. When we push our committed changes, they are transferred to the remote repository. The local directory, as the name suggests, is on our local machine, while the remote repository is situated in the cloud (GitHub, Bitbucket, etc.).

Basic Git commands

To initialize a repository, we use git init. This command creates a folder. If you don't see it immediately in your folder path, it might be hidden in Windows. You can reveal it by selecting the option to show hidden files, and then you will be able to see the .git folder.

After initialization, to move from "modified" to "staged," we use the git add command. To transition from "staged" to "committed," we use the git commit command.

When we reach the "committed" stage, we can proceed to push committed changes to the remote repository using the git push command.

If we want to retrieve data from a remote repository, we will use the git pull command.

So let’s go through all commands at once when pushing new changes:


1. git init
2. git add . // add your changes
3. git commit -m “commit message” // commit changes with message
4. git push origin <branch name> // push to remote repo

Create remote repository

Currently, one of the popular web-based version control platforms is GitHub. Let's dive into it by creating your first repository and committing your changes on GitHub.

Once you log into your GitHub account, you can find a button to create a new repository.

After clicking the "New" button, you will see the following options

Here, you can start by choosing a descriptive name for your repository. In the description field, you can provide, for example, information about the technologies used in the repository. If it's a public repository, including relevant keywords in the description can make it easier for others to discover.

The next option allows you to choose whether your repository will be Public or Private. If it's private, only you and your team or organization can access the source code. If it's public, anyone can view, clone, or fork the repository.

Following that, there's an option to initialize the readme file. You can choose to add it or ignore it at this stage; it doesn't make a significant difference.

Finally, there's an option to select a license. This informs others about what they can do with your code. Common licenses include the MIT License, which permits the use, copying, modification, merging, publishing, distribution, sublicensing, and selling of copies of your software. You can choose to skip this part if you prefer.

Now, after selecting all the desired options, we can proceed to create the repository, and we will see the following.

This is the next page. Now, we can use your Git commands to push to the remote repository. GitHub also provides a suggestion on how to push the first commit.

You can use any terminal to run Git commands. It can be Git Bash, CMD if you are on Windows, or you can run commands in the Visual Studio Code terminal. Choose the terminal that you are comfortable with for running your Git commands.

First, navigate to your repository path in Windows. You can do this by holding Shift and right-clicking the file or folder. Then, select "Copy as Path." Alternatively, you can press ALT + D in your current folder and copy the selected text.

Then run:


git init

git add .

git commit -m “initial commit”


git remote add origin “your repo” //Copy SSH

And last thing is to push


 git push “origin master”

That's it you now have your code on a remote repository.

Git rebase

Git rebase is a command in Git that allows you to rewrite the commit history of a branch by incorporating changes from another branch.

In other words rebase means moving your branch's starting point to a different commit. It's like pretending you began your work from that new point.

git rebase <base>

most of time will be :

git rebase master

After this command you can see visually

Example of git rebase usage

Main question is why do people use Git rebase?
And the answer is simply to maintain a linear project history.

Which is good starting point to mention dangers of rebase

Dangers of rebase

Imagine a project with two branches: "feature" and "master." The "feature" branch was created from main and depends on a package that was in the meantime taken out from the "master" branch. When you attempt to sync the "feature" branch with the latest "master," the initial modification you made will create a problem, causing errors in the project's build.

Handling conflicts in the midst of rebasing a long sequence of commits can be perplexing and challenging. It introduces complexity, making it harder to ensure everything is resolved correctly, and it becomes another potential source of errors in the process.

From blog by Fredrik V. Mørken

There is good observation of this problem which is:

“I’ve come to the conclusion that it’s about vanity. Rebasing is a purely aesthetic operation. The apparently clean history appeals to us as developers, but it can’t be justified, from a technical nor functional standpoint.”

Git merge

Git merge is combining changes from one branch into another. Typically, you'd merge code from a feature branch into the main branch (or master). It's a way to blend the separate work histories, making sure the latest updates from a feature are included in the main project.

Example of merging after some changes:

// Start a new feature
git checkout -b new-feature
//Edit some files
git add <file>
git commit -m "Start a feature"
// Edit additional files
git add <file>
git commit -m "Finish a feature"
// Merge in the new-feature branch
git checkout main
git merge new-feature

In team collaboration, we often use platforms (like GitHub) for code management. The typical workflow involves committing your changes locally, pushing your new branch to the remote repository, and then opening a pull request or merge request. Afterward, team members review your commits, ensuring everything is in order. If everything checks out, they merge your changes into the main branch. This process ensures a collaborative and organized approach to integrating new features or fixes into the project.

Merge conflicts

The inevitable aspect of Git merges is encountering conflicts.

Let's explain Git conflicts through an example:

Consider a scenario where there exists a file named test.js in the main branch of a project. Now, envision two developers who have been independently working on different branches within the same project. Each developer has made changes to the test.js file on their branches. Developer A successfully merges their changes into the main branch. Then, Developer B attempts to merge their modifications into the main branch as well. Consequently, Git detects conflicting changes and creates a merge conflict in the test.js file. Now Developer B must resolve conflicts to merge their branch successfully. Typically, this involves using some IDE that provides visual tools to identify and resolve conflicts effectively.

Git can also automatically merge changes when the commits occur on separate lines or branches.

In Conclusion

We've covered the basic usage of Git, but it's important to note that Git offers a wealth of additional features and functionalities that go well beyond what was explained here so far.

Expo APK build with Windows

Manojlo Ilic — Wed, 27 Mar 2024 18:06:45 +0000

I was inspired to write this short blog by not having clear docs on running local builds for expo on Windows OS. So in order to save somebody time and suffering, here are up to date instructions.

Expo

Expo is a great framework and platform to get started up to track with React native app development. One of the advantages of expo is the simplified building of the app, also you don't need to spend time configuring it by yourself and if you use the expo cloud you don't need to have MAC to build iOS apps.

The disadvantage of building an app using the expo server is that it is limited for free usage, so builds may take longer and you have a limited amount of builds per month.

Logically you will go with the option for local build but then the problem you might have is when you want to build the app, and you have Windows OS.

If you read the expo docs you will find a simple command to start building the app locally.

Which goes by eas build --platform android --local and when you run it from your source code path

You get an error: Error: Unsupported platform, macOS or Linux is required to build apps for Android.

Now after some research, you may end up like me seeing many problems with expo and building apps locally with Windows.

Immediate thought is let's just leave the expo and start with react native cli, but nothing is lost yet.

There is a nice solution for building expo from Windows which is Windows Subsystem for Linux (WSL). So no need to install Linux on a virtual machine to be able to create builds.

WSL installation

1. Method by terminal

Open start on Windows and search for Command Prompt
Run command:
wsl --install
Restart your PC
Run the command to see the list of all WSL distros with command:
wsl --list --online

For this case, you can go with Ubuntu:

Run command : wsl --install -d Ubuntu

You will be prompted to create Unix user, so add your name and password
After that, you are ready to use it

2. Method Install WSL from Microsoft Store

First is needed to Enable Virtual Machine Platform on you machine. To do that type in search on your windows machine “Turn Windows features on off”

After clicking on Turn Windows features on off you will see

And then select Virtual Machine Platform
Click OK
Then you will be prompted to restart the PC, to finish adding changes.
Open Microsoft Store(from search bar or from pressing start)
Search Windows Subsystem for Linux
Install it

Also check Official Windows docs to install wsl

Install Necessary tools

Now open your installed WSL Ubuntu terminal

You can do it by running cmd and then selecting installed Ubuntu

Run it from Windows search by simply searching for Ubuntu

Or you can:

Run it from VS code terminal where you will be already in the path of your project

Once we have prepared the WSL Ubuntu terminal and got to the path of our project we can start installing all the neccessary tools

Install OpenJDK you can set the version that you want, in my case I used version 17:

sudo apt install openjdk-17-jdk-headless gradle

set path to JAVA_HOME

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

Install Android command-line tools:



cd ~
curl https://dl.google.com/android/repository/commandlinetools-linux-8512546_latest.zip -o /tmp/cmd-tools.zip
mkdir -p android/cmdline-tools
unzip -q -d android/cmdline-tools /tmp/cmd-tools.zip
mv android/cmdline-tools/cmdline-tools android/cmdline-tools/latest
rm /tmp/cmd-tools.zip

Set correct path for variables:



export ANDROID_HOME=$HOME/android
export ANDROID_SDK_ROOT=${ANDROID_HOME}
export PATH=${ANDROID_HOME}/cmdline-tools/latest/bin:${ANDROID_HOME}/platform-tools:${ANDROID_HOME}/tools:${ANDROID_HOME}/tools/bin:${PATH}

Accepting SDK licenses:

yes | sdkmanager --licenses

Installing SDK components (set correct android versions):

Find a version of SDK in your project in android/build.gradle then see targetSdkVersion and buildToolsVersion
Then Install that specific version in my case :

sdkmanager --update sdkmanager "platforms;android-33" "build-tools;33.0.0"

Run local build for expo

From expo docs you can see commands for local build:

eas build --platform android --local eas build --platform ios --local

Now run them from the WSL Ubuntu terminal and get your build!

Note one error that was happening to me multiple times when opening a new WSL terminal is that ANDROID_HOME could not be found, then JAVA_HOME was not found or SDK path was not found. Even though I have run commands and set the correct path already. So what needed to be done to resolve this error was to just run commands again and then it all worked.

Happy coding!