-
Notifications
You must be signed in to change notification settings - Fork 0
Git Command and Flow
This is a pretty good rundown of the basic Git workflow for managing the repository on your side. I'd recommend creating a branch and experimenting with pushing and pulling, or even in a separate repository before making commits here.
https://blog.algolia.com/master-git-rebase/
The official Git documentation:
https://git-scm.com/book/en/v2/
A guide from Github
https://guides.github.com/introduction/flow/
To clone this repository simply do
git clone [email protected]:CS300-A-Team/Frupal.git
This will create a new directory called Frupal and pull the code into it.
If you get an SSH error, it may be that you do not have SSH keys setup with Github yet. If this is the case you can also use Https:
git clone https://github.com/CS300-A-Team/Frupal.git
From here it may be good to setup a branch to work on that you can push to and publish for others to see your work while not committing to the master branch. The idea is that the master branch should be deployable at any time, in other words, don't break master.
Before committing for the first time your email address should be set to your schools email address.
git config user.email "[email protected]"
git config user.email
The second line confirms that you have set your email. This will be used when you sign your commits.
Similarly your name should also be set as your real name.
git config user.name "My Name"
git config user.name
To set these globally add the --global flag to the above commands.
git config --global user.email "[email protected]"
git config --global user.name "My Name"
Global settings are the default if your repository settings are not set. You may not wish this default to be your schools email if you are also committing to other open source projects.
How the work flow goes
- Clone this repository
- Create a branch
- Push branch to this repository
- Do work on your branch
- Push changes to branch to the repository
- Submit a merge request
- Wait for code to be reviewed, then merged
The master branch is locked down, this should only have completed work merged into it.
Branches should be named something that is descriptive, such as, character_model,
or game_controller_endofgame. These names let us know what feature is being worked on.
People can choose to test code by checking out a different branch, or creating a new branch
in which they pull in multiple branches of work to see how things work together.
Once a feature is complete, then push the completed work to the remote repository and create a new pull request. This will trigger a code review where at least one other person must review the code and give their okay before merging the changes into master.
A good commit should fix or implement only one thing. This allows for easy root causing of bugs, and possibly reverting the bad commit. This also allows others to see your progress as you go along, and when multiple people are working together on a feature they won't get surprised by a commit that changes everything. This will also save yourself headaches when you go to sync with other changes as others may have changed files you are working on too, and avoid having to resolve a lot of merge conflicts.
Another benefit is it makes it clear what each code change was intended to do. Rather than a commit that says
fixed everything, you get messages of fixed divide by zero, fixed character dying when going up two squares in a row, and it is clear that these are not related issues, and the code changes in the file are only related to
the issue at hand. This also helps with code review so the reviewer can understand what your fix is and what it
is fixing.
For committing code, please use a well formatted git commit message.
git add myfile
git commit -s
This will bring up your default text editor. The first line is the title, this should be short and explain what the code is fixing or implementing. The next line is blank, that creates a new paragraph. The third line begins the summary, this is where you can explain the details on how you implemented the feature.
Added New Awesome Feature
Implemented this feature using this cool architecture. I had to
disable the ability to do this other awesome thing for now as it
breaks something else, but that awesome thing isn't needed.
Signed-off by Author <[email protected]>
After committing one or more changes, push them to your remote repository on GitHub:
git push
Branching is at the heart of the workflow. Often you may hear these called feature branches, which is an apt name, but longer to type on the command line. Branching allows you to do work on a feature without changing the current master branch. Others can see your work, contribute to the feature, and review code before merging to master. This helps to keep the master branch clean and deployable at any time.
You can also create branches to work on if you want to work on two separate features.
git branch mynewfeature
git checkout mynewfeature
Any changes you make will be on this branch. To switch back to the master branch:
git checkout master
Your changes will still be on mynewfeature, and you can pull the master branch to keep it synced with
everyone else.
To keep your branch synced up with your master you'll have to rebase your branch after every sync with the master:
git checkout master
git pull
git checkout mynewfeature
git rebase master
To push the new branch to the remote repository for the first time:
git push -u origin
After doing this the first time the tracking is set up so subsequent pushes can follow the normal flow.