Skip to content
This repository has been archived by the owner on Apr 23, 2022. It is now read-only.

Latest commit

 

History

History
334 lines (195 loc) · 6.63 KB

3-collaborating-with-git.md

File metadata and controls

334 lines (195 loc) · 6.63 KB

Collaborating with Git

📌 Learning objectives:

  • Learn to collaborate with Git
  • Discover GitLab/GitHub
  • Start working in team

Branching

Branches are what naturally happens when you want to work on multiple features at the same time. This is also useful to collaborate in teams.

You wouldn't want to end up with a master branch that has Feature A half done and Feature B half done.

Creating a branch

git branch lists the local branches of your project:

$ git branch
* master

git checkout feature switches to the branch named feature if it exists. To create a branch and switch to it, you can also use:

$ git checkout -b feature
Switched to a new branch 'feature'

🚀 Hands-on

  1. Create a branch named feature
  2. Switch to it (if not done in a single command)
  3. Create and commit the following files: pluton.txt, jupyter.txt and earth.txt
  4. Switch to the master branch and see what happens

Merging a branch

Merging is Git's way of putting a forked history back together again. The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.

$ git merge feature

Always generate a merge commit:

$ git merge --no-ff feature

Deleting a branch

$ git branch -d feature

Force delete a branch with -D:

$ git branch -D branch-not-merged

🚀 Hands-on

  1. Switch to master and merge feature into it
  2. View the log with the --graph option
  3. Create a branch named feature-no-ff
  4. Add a new file mercury.txt and commit it
  5. Switch to master and merge this branch with the --no-ff option
  6. View the log with the --graph option

Git alone

The missing piece

Git remotes

Managing remotes

Remote repositories are versions of your project that are hosted on the Internet or network somewhere.


$ git remote -v
origin	[email protected]:tailordev-academy/git-101.git (fetch)
origin	[email protected]:tailordev-academy/git-101.git (push)
$ git remote add <name> <repo>
$ git remote rm <name>
$ git remote set-url <name> <new repo>

Git clone

git clone <repo> downloads a full copy of a repository into a new directory. Different protocols are supported: file, HTTPS, SSH, etc.

It automatically setups a default origin remote for repo that you can use for push and pull.

Git pull

git pull <remote> <branch> copies changes from a remote repository to a local repository.

Pull = Fetch + Merge

git pull is a shortcut for git fetch + git merge.

git fetch retrieves the commits from a remote repository, but do not apply them on your working directory. git merge applies them.

Git push

git push <remote> <branch> copies changes from a local repository to a remote repository.

Introducing GitLab

GitLab is an Open Source (MIT licensed) web-based Git repository manager with wiki and issue tracking features.

Integrated issue tracking

Enriched markdown support

Confidential issues

Issue boards

Merge Requests

Diff (side by side)

Resolve conflicts

Activity stream

Protected branches

CI/CD

🚀 Hands-on

  1. Log in to https://gitlab.com/
  2. Create a group
  3. Create a project inside this group
  4. Add a README.md file via GitLab
  5. Clone this repository locally

🚀 Hands-on

  1. Create a feature branch
  2. Add a CONTRIBUTING.md file
  3. Push this branch to GitLab
  4. Open a merge request
  5. Review your changes and merge
  6. Synchronize your local repository

Workflows

Git can support your project not just with version control, but also with collaboration and release management.

There are many workflows but let's focus on a simple one.

The simple Git branching model

  • master must always be deployable
  • all changes made through feature branches (merge request + merge)
  • rebase to avoid/resolve conflicts; merge in to master

DO ...

  • keep master in working order
  • rebase your feature branches
    • pull in (rebase on top of) changes
  • tag releases
  • push feature branches for discussion
  • learn to rebase

DON'T ...

  • merge in broken code
  • commit onto master directly
    • no hotfix onto master, use a feature branch
  • rebase master
  • merge with conflicts, handle conflicts upon rebasing

Git rebase

git rebase "replays" the commits of your branch on top of a branch, usually master.

You may have to "force-push" your branch (-f) since commits are applied again (identifiers change).

Pull = Fetch + Merge

git pull is a shortcut for git fetch + git merge.

git fetch retrieves the commits from a remote repository, but do not apply them on your working directory. git merge applies them.

You can use --rebase to rebase a branch on pull:

$ git pull --rebase origin master

🚀 Hands-on

  1. Modify the README.md file on GitLab
  2. Modify the README.md file locally
  3. Push your change without synchronizing your local repository and see what happens
  4. Rebase your local branch and push it

Congratulations, you have resolved your first conflict 🎉

🚀 Hands-on

  1. Give access to your GitLab project to a teammate
  2. Tell her to propose a change to the README.md file
  3. Review her code, you can add comments
  4. Once everything looks good, accept the merge request

Invert the roles and do these steps again.

🚀 Hands-on

  1. Each team creates a simple issue, for instance to add a few lorem ipsum paragraphs to the README.md file
  2. Each team forks a project from another team and proposes a fix for the issue of that project
  3. You can edit your own README.md file in the meantime
  4. Review the merge request, comment it if needed
  5. Accept the merge request when it looks good