Hackathon Docs

🚀 GitHub Team Collaboration

Step-by-step guide to set up and share a Salesforce project with your team using Siid IDE and GitHub.

0

One-time Git setup — do this first

Everyone

Every team member must do this once on their machine before anything else. This tells Git who you are so your commits are correctly attributed.

1
Open Command Prompt (search cmd in the Start menu) and verify Git is installed:
git --version
# Should print something like: git version 2.44.0.windows.1
2
Set your name and email globally. Use the same email as your GitHub account:
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"
3
Verify your config was saved correctly:
git config --global --list
# Should show user.name and user.email
Note: The --global flag applies this config to all repos on your machine. You only need to do this once. If you ever need different settings for a specific repo, run the same commands without --global inside that repo folder.
Setup done — now let's create the repo
1

Create a GitHub repository & add collaborators

Repo owner
1
Go to github.com, sign in and click New repository. Give it a name, set visibility, and click Create repository.
2
In your new repo, go to Settings → Collaborators, click Add people and invite each team member by their GitHub username or email.
3
Copy the HTTPS clone URL of your repository (click the green Code button). It looks like this:
🔗 https://github.com/<your-org>/<repo-name>.git
🖼️
Screenshot: GitHub repo → Code button → copy HTTPS URL
step1-github-clone-url.png
Repo owner continues in Siid IDE
2

Initialize repository & push from Siid IDE

Repo owner
1
Open Siid IDE and create a new empty Salesforce project — use File → New Project (or the Siid new project wizard) and choose your Salesforce org. This sets up the base project structure and metadata folders.
2
Once the project is open, click the Source Control icon (branch icon) in the left sidebar.
3
Click Initialize Repository. Siid will create a local git repo for your project.
4
Click the ··· (more actions) menu → Remote → Add Remote. Paste the GitHub URL you copied in Step 1, name it origin.
5
Stage all files (click + next to each or Stage All Changes). Type a commit message like Initial Salesforce project and click Commit.
6
Click Publish Branch (or Push) to push to GitHub. Your project is now live on the remote repo!
🖼️
Screenshot: Siid IDE → Source Control → Initialize Repository
step2-siid-source-control.png
🖼️
Screenshot: Siid IDE → Add Remote dialog (paste GitHub URL)
step2-siid-add-remote.png
Tip: Make sure you are on the main branch before pushing. Check the branch name in the bottom-left status bar of Siid.
Other team members now join
3

Clone the repository to your machine

Team members
1
Accept the GitHub collaborator invite (check your email or GitHub notifications).
2
Open File Explorer, navigate to the folder where you want to store the project (e.g. C:\Users\Aman\Documents\salesforce_project).
3
Click the address bar at the top of File Explorer to highlight the path, type cmd and press Enter. A Command Prompt opens in that folder.
🖼️
Screenshot: File Explorer address bar → type "cmd" → press Enter
step3-explorer-open-cmd.png
4
In the Command Prompt, run the git clone command with the repo URL shared by the repo owner:
Terminal command
# Replace the URL below with the one shared by your repo owner
git clone https://github.com/<your-org>/<repo-name>.git

# Example:
git clone https://github.com/Conscendotechnologies/Siid.git
🖼️
Screenshot: Command Prompt running git clone command
step3-cmd-git-clone.png
5
Once cloned, a new folder appears. Open Siid IDE, click File → Open Folder, and select the cloned folder. You now have the full project!
🖼️
Screenshot: Siid IDE → File → Open Folder (select cloned project)
step3-siid-open-folder.png
Once open in Siid — no terminal needed
4

Using Source Control UI in Siid (just like VS Code)

Team members

Siid is built on VS Code — all git operations can be done from the UI. No terminal commands needed after cloning.

Always pull from main before creating a branch
CLEAN REPO
No uncommitted changes? Click ··· → Pull in the Source Control panel to get the latest main, then create your branch.
HAVE CHANGES
Already made edits but haven't committed? Stash them first, pull, then unstash — steps below.
Stash → Pull → Unstash
1. In Source Control, click + next to your changed files (or Stage All Changes) to stage them first.
2. Click ···Stash → Stash Staged. Only your staged changes are stashed and the working tree goes clean.
3. Click ···Pull to get the latest changes from main.
4. Click ···Stash → Pop Stash. Your changes come back on top of the latest code.
1
Pull latest changes — Click the Source Control icon in the sidebar, then click the ··· menu → Pull to get the latest code from the team before you start working.
2
Create your own branch — Click the branch name in the bottom-left status barCreate new branch. Name it something like yourname/feature to avoid conflicts on main.
3
Stage your changes — In the Source Control panel, changed files appear under Changes. Click + next to a file (or Stage All Changes) to stage them.
4
Commit — Type a message in the box at the top (e.g. Added Apex trigger for accounts) and click the ✔ Commit button.
5
Push to GitHub — Click Publish Branch or the ↑ sync icon in the status bar to push your branch up to the shared repo.
🖼️
Screenshot: Siid IDE Source Control panel — stage, commit & push UI
step4-siid-commit-push-ui.png
Tip: The sync button in the bottom status bar (↑↓) lets you pull and push in one click once your branch is already published.
Work is done on your branch — time to merge
5

Raise a Pull Request on GitHub

Team members
1
Go to your repository on github.com. GitHub usually shows a banner — "yourname/feature had recent pushes" — click Compare & pull request.
2
Make sure the base branch is set to main and the compare branch is your feature branch.
3
Give your PR a clear title (e.g. Add Apex trigger for Account object) and a short description of what changed and why.
4
Assign a Reviewer — ideally the repo owner or a teammate — using the Reviewers panel on the right side.
5
Click Create pull request. Your team will be notified and can review the changes, leave comments, and approve.
🖼️
Screenshot: GitHub → Compare & pull request → fill title, description, reviewer
step5-github-create-pr.png
Tip: Before raising a PR, make sure your branch is up to date with main. Pull → stash if needed (see Step 4) to avoid merge conflicts.
Reviewer reviews — then owner merges
6

Review & merge the Pull Request

Repo owner
1
Open the PR on GitHub. Click the Files changed tab to review what was added, modified, or deleted.
2
Leave inline comments by clicking the + icon next to any line. Use Start a review to batch your comments before submitting.
3
Once satisfied, click Review changes → Approve and submit the review.
4
Back on the Conversation tab, click Merge pull request → Confirm merge. Choose Squash and merge to keep the commit history clean, or Merge commit to preserve all commits.
5
After merging, click Delete branch to keep the repo tidy. The feature is now part of main.
🖼️
Screenshot: GitHub PR → Files changed → Approve → Merge pull request
step6-github-merge-pr.png
After merging: All team members should pull main in Siid to get the merged changes before starting their next feature branch.
Best practices for the team

Team workflow — best practices

🌿
Never commit directly to main
Always create a feature branch from main for every task. main should only receive changes through reviewed and approved pull requests.
⬇️
Always pull main before starting new work
Before creating a new branch, always pull the latest main. This reduces merge conflicts and keeps your branch close to the team's current state.
🔖
Use clear branch names
Name branches with your name and what you're working on — e.g. aman/account-trigger or priya/lwc-dashboard. Avoid generic names like test or fix.
💬
Write meaningful commit messages
Be specific — "Add validation rule for Contact email" is far more useful than "changes" or "fix". Your team (and future you) will thank you.
🔁
Commit small and often
Don't pile up a week of work into one giant commit. Small, focused commits are easier to review, easier to revert if something breaks, and keep the PR manageable.
👁️
Review PRs promptly
Don't leave a teammate's PR sitting for hours during a hackathon. Aim to review and approve within 15–30 minutes so the team keeps moving.
🧹
Delete branches after merging
Once a PR is merged, delete the feature branch. This keeps the repo clean and makes it easy to see which branches are still in progress.
📋

Quick reference – common git commands

# Check current status of your repo git status # Pull latest changes from remote git pull origin main # Create and switch to a new branch git checkout -b yourname/feature-name # Stage all changes and commit git add . git commit -m "your commit message" # Push your branch to GitHub git push origin yourname/feature-name