AWS is the Linux of Cloud
I’ve been a Linux user for about 25 years. I first used it at
This is more of a note to my future self.
I was working on an wiki, hosted on MkDocs, that you contribute via making changes and pushing to GitLab. The process to submit a change is:
git clone ...
git checkout -b improv/new-demo
git add docs/
git commit -m "improv: Add new demo"
git push -u origin improv/add-demo-X
Thats fairly straight-forward. However, I was making two separate changes at the same time, each on different branches, and kinda messed up switching between the different branches. I also had to pull a fresh copy from the origin before making the second branch, to ensure I was working on the latest. This is how I set myself straight.
There is a git server, perhaps using Github, GitLab, AWS CodeCommit, etc, hosting a project want to contribute to. This is the called the remote
repository. If you were the owner, you could simply make the change directly. E.g in GitHub, you could click the 'Edit this file button', but probably you would:
git clone git@github.com:jojo786/TelegramTasweerBot.git
. In this case, you cloned the default branch (main or master) branch. git commit -am "My Change"
. Usually you would make a new branch, which is a pointer to your changes. git push
. The git push
command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repo. You did'nt create another branch first, so you have pushed straight to master. The full command is actually git push origin main
, which origin
is the name of the remote repo, and main
is the branch.However, if you wanted to make a change to another repo, owned by someone else, you cant just push back to it. Rather, you fork the repo, then go through a process called a Pull Request or Merge Request (usually shortened to PR), in which you submit your changes, and they can merge it in. They are the same thing: a means of pulling changes from another branch or fork into your branch and merging the changes with your existing code. So the process would be:
git branch crazy-experiment
or git switch -c crazy-experiment
git commit -am "message..."
git push -u origin crazy-experiment
. This creates crazy-experiment
branch on the remotecrazy-experiment
branch is deleted both locally and on the remote, and just the main branch is left. But there are now three different copies of the data:
But at any time, the upstream maybe be including other changes, that my fork and local clone is not aware of.
So back to my situation. I have cloned the remote, made a new branch, pushed my changes, and submitted a PR. I then needed to submit another separate/independent change, so I needed to create a new branch. However, my clone of the repo locally, which is from my fork, might have been stale, as changes could have happened to the upstream since I cloned it. I could have simply deleted my local folder, forked and cloned again, to get the freshest copy. But I wanted to see what it takes to get my local repo, fork and upstream in sync. There are different ways to sync a fork, but I preferred this one:
upstream
: git remote add upstream https://github.com/aws-samples/serverless-patterns
git checkout main
git fetch upstream
git merge upstream/main main
git push origin main
Hope you enjoyed it|!