Git Advanced Lab
- clean up a repo
- difficult merge
- fork
- send a merge request
- manage a merge request
Create an account on GitHub
Initially, I used Gitlab from Télécom for this lab. A non-reproducible bug on students accounts forced me to switch to GitHub. I hope this does not inconvenience you.
SSH access to GitHub is similar to that of GitLab.
Clean up
Intention: check you have learned about cleaning up a repository
Instructions:
- clone git@github.com:jcdufourd/slr201-to-clean.git
- clean up this repo so that:
- useless files are deleted,
- files that should not be tracked still exist but are not tracked anymore,
- a clone of your new repo should have the same content as the test repository.
Source Repository: git@github.com:jcdufourd/slr201-to-clean.git
Test Repository: git@github.com:jcdufourd/slr201-cleaned-up.git
Fork
Forking is creating a copy of a repository so that the copied repository keeps a link to the original, to be able to send suggested modifications.
If you fork a readonly repository, you have all the rights on your fork (writing, moving, deleting).
Go to this repo (R0) and fork it to R1.
Find another student to work with.
Fork her/his R1 to your R2, which s/he forks your R1 to her/his R2.
As an alternative to working with another student, you can create an organisation then fork to that organisation. Choose the free plan for the organisation.
Difficult Merge
Intention: check that you can diagnose a problem and solve it with multiple steps
Instructions:
- clone R2
- checkout master and evaluate the content of the working copy
- checkout master2 and evaluate the content of the working copy
- determine the actions to do before a merge is meaningful
- implement the pre-merge actions in master2 and commit
- merge master2 into master
- commit
- fast-forward both branches to the same point
- push
Checklist:
- just one version of each file at the end
- only files that should be tracked are tracked in git
- the final folder structure is meaningful
- before the merge, files with the same name are in the same folder
- during conflict resolution, you pick a simple answer
Sending a Merge Request
You have just pushed to your fork R2. If you go to your fork’s page of the github site, you will see a new button “create merge request”.
Use this button to send a request. Explore all the options. Send a merge request to R1
The key elements of a merge request are:
- a starting point which is common in both repos, i.e. a commit that existed before the fork action.
- the URL of the distant repo you want to send the request to, R1
- an end point, which by default is the current version checked out where you create the request.
To have another point of view on pull requests (or merge requests), let us create one such request from the command line.
In your fork folder, be sure to have the latest state checked out.
The starting point is the branch named “start”.
The command is:
git request-pull -p start git@gitlab.enst.fr:slr201-git-adv/difficult-merge.git
If you need to specify an end point, it comes after the URL.
Here is the output, constituted by a summary of the command, output of the pull, then a list of diffs:
The following changes since commit 62b1d1ff3c3829c1a158cda490a8166ba4512454:
change 1 (2019-07-23 15:03:19 +0200)
are available in the Git repository at:
git@gitlab.enst.fr:slr201-git-adv/difficult-merge.git
for you to fetch changes up to c5b39fc14ecc9c38dc71a22058594b0191d8deda:
merge (2019-07-23 18:11:10 +0200)
----------------------------------------------------------------
Jean-Claude Dufourd (4):
init
change 2
mv
merge
.classpath | 6 ++++++
.project | 17 +++++++++++++++++
src/Main.java | 2 +-
src/Point.java | 3 ---
src/Point2.java | 3 +++
5 files changed, 27 insertions(+), 4 deletions(-)
create mode 100644 .classpath
create mode 100644 .project
create mode 100644 src/Point2.java
diff --git a/.classpath b/.classpath
new file mode 100644
index 0000000..3f3893a
--- /dev/null
+++ b/.classpath
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<classpath>
+ <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
+ <classpathentry kind="src" path=""/>
+ <classpathentry kind="output" path=""/>
+</classpath>
diff --git a/.project b/.project
new file mode 100644
index 0000000..8f4d1d4
--- /dev/null
+++ b/.project
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<projectDescription>
+ <name>difficult-merge 2</name>
+ <comment></comment>
+ <projects>
+ </projects>
+ <buildSpec>
+ <buildCommand>
+ <name>org.eclipse.jdt.core.javabuilder</name>
+ <arguments>
+ </arguments>
+ </buildCommand>
+ </buildSpec>
+ <natures>
+ <nature>org.eclipse.jdt.core.javanature</nature>
+ </natures>
+</projectDescription>
diff --git a/src/Main.java b/src/Main.java
index a0428da..f515cbb 100644
--- a/src/Main.java
+++ b/src/Main.java
@@ -1,6 +1,6 @@
public class Main {
public static void main(String[] args) {
- System.out.println("Hello World!");
+ System.out.println("Bonjour!");
}
}
diff --git a/src/Point.java b/src/Point.java
index c5afdf5..6528237 100644
--- a/src/Point.java
+++ b/src/Point.java
@@ -1,5 +1,3 @@
-import java.util.ArrayList;
-
public class Point {
public static void main(String args[]) {
Point p = new Point(26F, 6F);
@@ -32,7 +30,6 @@ public class Point {
Point p = new Point();
p.y = x;
{
- float rho = 3;
p.x = y;
}
return p;
diff --git a/src/Point2.java b/src/Point2.java
new file mode 100644
index 0000000..4b73381
--- /dev/null
+++ b/src/Point2.java
@@ -0,0 +1,3 @@
+public class Point2 extends Point {
+ public static Point2 p = new Point2();
+}
Managing a Merge Request
When a merge request is received by your R1 repo (from your partner), then go to your R1 and look at the request.
You see the description, the commits, the changes, just as when you built the request. You may open the request in the web IDE, where you can see each file with old and new state.
You have a choice of:
- Pressing “Merge” and thus accepting the changes
- Pressing “Close Merge Request” and thus refusing the changes
If you have time, press “Close Merge Request” to see what happens, then go back to the previous exercise, recreate the Merge Request from R2, and this time, press “Merge” in R1. You will thus have explored all the situations as a receiver of merge requests (or pull requests).