Starting a git repository?

First setup the remote repository:

ssh git@brain2.scotnpatti.com
cd /home/git/repos               # you shouldn't use the base user directory for good reasons -- See SshGen page
mkdir my_project.git
cd my_project.git
git init --bare
git update-server-info # If planning to serve via HTTP
exit

On your local machine:

cd [your project directory]
git init
git add * # or "." if you want to add all the files in the hierarchy
git commit -m "My initial commit message"
git remote add origin http://gitlab.scotnpatti.com/username/my_project
git push -u origin master

Others can now clone track the remote repository:

git clone git@example.com:repos/my_project.git
cd my_project

Adapted from: http://thelucid.com/2008/12/02/git-setting-up-a-remote-repository-and-doing-an-initial-push/

Standard workflow for private project (you only)

edit/stage/commit

git status # View the state of the repo
git add <some-file> # stage a file
git commit -m "message" # commits changes 

You can also add and commit in one statement

git commit -a -m "message"

Publish

git push origin master

GitHub Workflow

You found a project you want to contribute to.

1. Fork the project (on git hub - now you should have a copy in your repository that is separate from the original)
2. Clone it to your local file system. (i.e. git clone [url])
3. Create a branch (i.e. git checkout -b [branchname])
4. Edit files as needed
5. Add/commit changes (i.e. Commit -a -m "Message")
6. push to your forked git repository on github: git push origin [branchname]
7. Check github for a link to a pull request. (Pull request link should be on code page see end of video).

See the video here

Dealing with Errors

If you are working with multiple people You may get an error when you commit or when you are merging your branch. In the first case it might look like this:

Updates were rejected because the tip of your current branch is behind its remote counterpart. Merge the remote changes (e.g. 'git pull') before pushing again.

So you may need to pull by doing the following:

git fetch origin master 
git merge origin master
git pull origin master

If you have changes, go edit the file to remove the conflicts (Visual Studio Code works great for this, better than Visual Studio 2017).

You may then get a CONFLICT (content): Merge conflict in <some-file> which you will need to resolve by type git status. Looking at the git status is a good idea before you do anything.

Branches

So you started working on a program and realized that you should probably have started a branch. So,

git checkout -b [branchname]

... will create and checkout the new branch using the exiting code while leaving the old branch as is.

To switch to an existing branch leave off the -b. To switch to the previous branch do:

git checkout -

Viewing history

git log

Merging a Branch

Suppose you checkout a new branch

git checkout -b scot-bugfix

Before you get to far on it, your boss comes in and gives you a hotfix that must be completed post haste. So, you create another branch off of main

git checkout -b scot-hotfix main

You immediately create the hotfix and commit it

git commit -m "Finished hotfix"

Then you switch back to main

git checkout main

and complete a git pull

git pull

This ensures that you have the latest. Let's assume for the moment that there were no updates on main since you branched. In this case you will be merging using a fast forward merge.

git merge scot-hotfix

This will complete with no errors, warnings etc. because no one changed anything. You are now free to delete the hotfix branch and continue working on your scot-bugfix branch.

git branch -d scot-hotfix
git checkout scot-bugfix

Once you are done with your bugfix, you can commit it, switch to the main branch and check to see if there have been any changes since you last looked.

git commit -m "bug fixed"
git checkout main
git status

Now, we have made and pushed changes since the scot-bugfix branch was created. So we know that this merge will not be a fast forward merge. That does not mean that git status will return a state indicating that we are behind commits from origin/main. If we are, we must do a pull, then we can do our merge.

git pull
git merge scot-bugfix

This may tell us that there are conflicts. If there are, go ahead and edit them in vscode using the resolve conflicts option (or in your editor of choice resolve the conflicts in the file indicated). Once the conflicts are resolved, commit and push.

git commit -m "resolved conflicts in merge..."
git push

Strategies

Condition 1: There have been no commits to the main branch since you checked out your code and you can merge using a fast-forward merge. This is the easiest!

Condition 2: There have been commits to the main branch since you checked out your code and commit history has diverged and you need to use one of the following methods:

1. 3-way merge - run the merge and deal with conflicts as above.

2. rebase - Beginners shouldn't rebase, but if you need to know more about it, see merging vs rebassing

Notes about Gitlab

1. Its much easier if you create your branch in gitlab, do a fetch from your repo and then you can checkout the new branch.

2. It is absolutely imperative that you wait for gitlab to finish before you do anything else for a merge - go to the merge requests page and check its status if it says complete in 1 minute, wait a minute and then refresh. When it says that it is done, then you can start interacting with the system again via git.

   1. If you did manage to interrupt gitlab, go to the files and finish the merge by hand. You will see <<<<<<<< ============ and >>>>>>>>>> stuff in there. Edit it and commit it.

3. Always read the README.md and any .gitlab-yml type files. Some CI/CD stuff is setup by default and it may fail if you don't have any runners.