Starting a git repository?
First setup the remote repository:
ssh email@example.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 firstname.lastname@example.org: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)
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"
git push origin master
You found a project you want to contribute to.
- Fork the project (on git hub - now you should have a copy in your repository that is separate from the original)
- Clone it to your local file system. (i.e. git clone [url])
- Create a branch (i.e. git checkout -b [branchname])
- Edit files as needed
- Add/commit changes (i.e. Commit -a -m "Message")
- push to your forked git repository on github: git push origin [branchname]
- 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.
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 -
Merging a Branch
Suppose you checkout a new branch
git checkout -b scot-bugfix
If you did this locally and not on gitlab, you will need to push it to getlab with the --set-upstream origin [name_of_branch] in our case it would look like:
git push --set-upstream origin scot-bugfix
Now, when you go look at gitlab, there will be a new branch called scot-bugfix.
Before you get to far on the bugfix, 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
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. Once done, you can push it up to main (assuming you aren't working with gitlab or github and can't).
git merge scot-hotfix git push
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. 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
*If you happen to be working in gitlab or github, you will have to go to the website and create a merge/pull request. See below for that.
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:
- 3-way merge - run the merge and deal with conflicts as above.
rebase - Beginners shouldn't rebase, but if you need to know more about it, see merging vs rebassing
Notes about Gitlab
- Its much easier if you create your branch in gitlab, do a fetch from your repo and then you can checkout the new branch. But if you didn't do that, you can push your new branch with --set-upstream ans shown above.
It is absolutely imperative that you wait for gitlab to finish before you do anything else after you push the merge button - go to the merge requests page and check its status if it says complete in 1 minute (or x second), wait a minute and then refresh. When it says that it is done, then you can start interacting with the system again via git. But not before!!!
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.
- 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.