If we check git log: commit fbf7329cc6be6e1e44527e5ed5749adfe14b9ebf Note: since we switched branch, all our work in feature branch remains in feature branch. Let's pretend at the same time we are working on feature, someone else worked on another feature and pushed it to master.
#REBASE BRANCH WITH MASTER UPDATE#
Our feature work will be to update main.txt echo "feature1" > main.txt We create a new branch and work on our feature there. Then one day our boss asks us to work on a feature separately. Up to this point, everything has been pretty linear. Git commit -am "master2" // git add and commit at the same time Less main.txt // should say "master1" and "master2" Pretend another work is done on master branch the same file! Let's add another content. Ĭheck our git log, we should see only one thing, our "master1" commit. This will be our first commit, let's commit it with the same commit name so we can distinguish it.
mkdir git-playground & cd $_Ĭreate a txt file, pretend that will be the file everyone will be working on. Create a directory and create an empty git repository. Let's code along with me (this shouldn't require you to actually create a new project in github). Hopefully at the end of this article, you'll understand what each of them does and why they differ. I want to go over two popular commands: git rebase and git merge, in the most gentle way possible. One common use of git is applying feature branch into master branch.
There were times when I thought I might accidentally remove the file I have been working on because I didn't know what I was doing. One of my biggest weakness in programming is using git.
0 kommentar(er)
