We start with one branch: main

Recall: HEAD points to 'where we currently are'

main points to the latest commit on branch

We create a new branch that we name "feature" with git branch feature

This creates a new indicator pointing to where we are.
But HEAD still points to the main branch.

We use git checkout feature to get to the new "feature" branch

The HEAD indicator goes to the feature branch.

2. As dev1 create a short history of commits (minimum two) and push them

3. As dev2 pull the information

2. List branches (try to find the appropriate git branch option to do that)

3. Switch to the new branch (use git checkout <branch-name>)

New commits affect only the current branch

New commits affect only the current branch

In a big project, e.g. if you're the one working on the feature, changes to main might not be yours (other people push their features/fixes, etc. in the meantime).

Let's switch to the feature branch with git checkout feature

And add some commits while in there

One more

At any point you can return to the main with git checkout main

2. Switch back to the main branch and check what's going on in your working directory (e.g. in File explorer in Windows or Finder in MacOS).

3. Add a file (do not commit it) and try changing branches.

What happens? (put it somewhere as part of a new commit and push it)

4. As Dev2 execute git pull and check git branch -l

5. Execute git checkout feature1 and check git branch -l again

2. Create a new commit on the feature1 branch

3. Run git status on the main branch, push the changes

4. Run git status on the feature1 branch, push the changes

While in main do git merge feature

Recall: merge creates a new commit.

You can still work on your feature branch

It doesn't include the merge (unless you also do git merge main while on the branch feature).

Now that we know the basics, let's look again

Can you trace what's been going on in this project?

(Source: Git Better)

2. Merge the feature1 branch to the main branch using git merge <branch-name>. Push.

Conflict resolution is the same as we once did.

Let's first move to the branch we want to move (git checkout feature)

Then git rebase main

Important: rebase destroys original commits and creates new ones! Probably not a good thing if the original ones were shared with others or in a remote repository!

Possible troublesome situations:

• feature1 branch proved a dead end, but feature2 is promising
• feature2 is actually unrelated to feature1
• main branch introduced something relevant to feature2

The solution is to rebase feature2 to main

git checkout feature2
git rebase --onto main feature1 feature2
git rebase --onto <new-base> <old-base> <moved-branch>

Let's go back to the large graph

Can you see how rebase could come in handy for the lower feature branch?

(Source: Git Better)

Answering questions from last week

You can point it to an older commit instead: git checkout 87ec91d

This puts you in a "detached HEAD state".

Answering questions from last week

Here you can:

1. panic and go back simply by redirecting it back to the branch, e.g. git checkout master
2. check what was done in this commit
3. create an alternate history:

(and turn it into a new branch if you want to keep it)